<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v4.4.254</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.4.254</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.4.254'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2021-01-30T12:25:57+00:00</updated>
<entry>
<title>xen-blkback: set ring-&gt;xenblkd to NULL after kthread_stop()</title>
<updated>2021-01-30T12:25:57+00:00</updated>
<author>
<name>Pawel Wieczorkiewicz</name>
<email>wipawel@amazon.de</email>
</author>
<published>2020-12-14T09:25:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=241862be0e70ed1d5cd44ebe399a8375f8b90fa9'/>
<id>urn:sha1:241862be0e70ed1d5cd44ebe399a8375f8b90fa9</id>
<content type='text'>
commit 1c728719a4da6e654afb9cc047164755072ed7c9 upstream.

When xen_blkif_disconnect() is called, the kernel thread behind the
block interface is stopped by calling kthread_stop(ring-&gt;xenblkd).
The ring-&gt;xenblkd thread pointer being non-NULL determines if the
thread has been already stopped.
Normally, the thread's function xen_blkif_schedule() sets the
ring-&gt;xenblkd to NULL, when the thread's main loop ends.

However, when the thread has not been started yet (i.e.
wake_up_process() has not been called on it), the xen_blkif_schedule()
function would not be called yet.

In such case the kthread_stop() call returns -EINTR and the
ring-&gt;xenblkd remains dangling.
When this happens, any consecutive call to xen_blkif_disconnect (for
example in frontend_changed() callback) leads to a kernel crash in
kthread_stop() (e.g. NULL pointer dereference in exit_creds()).

This is XSA-350.

Cc: &lt;stable@vger.kernel.org&gt; # 4.12
Fixes: a24fa22ce22a ("xen/blkback: don't use xen_blkif_get() in xen-blkback kthread")
Reported-by: Olivier Benjamin &lt;oliben@amazon.com&gt;
Reported-by: Pawel Wieczorkiewicz &lt;wipawel@amazon.de&gt;
Signed-off-by: Pawel Wieczorkiewicz &lt;wipawel@amazon.de&gt;
Reviewed-by: Julien Grall &lt;jgrall@amazon.com&gt;
Reviewed-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
[iwamatsu: change from ring to blkif]
Signed-off-by: Nobuhiro Iwamatsu &lt;nobuhiro1.iwamatsu@toshiba.co.jp&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>sh_eth: Fix power down vs. is_opened flag ordering</title>
<updated>2021-01-30T12:25:56+00:00</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2021-01-18T15:08:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=17663f1a2fcfa47f82bba8363496733f065c3401'/>
<id>urn:sha1:17663f1a2fcfa47f82bba8363496733f065c3401</id>
<content type='text'>
commit f6a2e94b3f9d89cb40771ff746b16b5687650cbb upstream.

sh_eth_close() does a synchronous power down of the device before
marking it closed.  Revert the order, to make sure the device is never
marked opened while suspended.

While at it, use pm_runtime_put() instead of pm_runtime_put_sync(), as
there is no reason to do a synchronous power down.

Fixes: 7fa2955ff70ce453 ("sh_eth: Fix sleeping function called from invalid context")
Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Reviewed-by: Sergei Shtylyov &lt;sergei.shtylyov@gmail.com&gt;
Reviewed-by: Niklas Söderlund &lt;niklas.soderlund+renesas@ragnatech.se&gt;
Link: https://lore.kernel.org/r/20210118150812.796791-1-geert+renesas@glider.be
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xhci: make sure TRB is fully written before giving it to the controller</title>
<updated>2021-01-30T12:25:56+00:00</updated>
<author>
<name>Mathias Nyman</name>
<email>mathias.nyman@linux.intel.com</email>
</author>
<published>2021-01-15T16:19:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5eaa0aa86cc280105d99c391c26aac5f2b549ed9'/>
<id>urn:sha1:5eaa0aa86cc280105d99c391c26aac5f2b549ed9</id>
<content type='text'>
commit 576667bad341516edc4e18eb85acb0a2b4c9c9d9 upstream.

Once the command ring doorbell is rung the xHC controller will parse all
command TRBs on the command ring that have the cycle bit set properly.

If the driver just started writing the next command TRB to the ring when
hardware finished the previous TRB, then HW might fetch an incomplete TRB
as long as its cycle bit set correctly.

A command TRB is 16 bytes (128 bits) long.
Driver writes the command TRB in four 32 bit chunks, with the chunk
containing the cycle bit last. This does however not guarantee that
chunks actually get written in that order.

This was detected in stress testing when canceling URBs with several
connected USB devices.
Two consecutive "Set TR Dequeue pointer" commands got queued right
after each other, and the second one was only partially written when
the controller parsed it, causing the dequeue pointer to be set
to bogus values. This was seen as error messages:

"Mismatch between completed Set TR Deq Ptr command &amp; xHCI internal state"

Solution is to add a write memory barrier before writing the cycle bit.

Cc: &lt;stable@vger.kernel.org&gt;
Tested-by: Ross Zwisler &lt;zwisler@google.com&gt;
Signed-off-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20210115161907.2875631-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: bdc: Make bdc pci driver depend on BROKEN</title>
<updated>2021-01-30T12:25:56+00:00</updated>
<author>
<name>Patrik Jakobsson</name>
<email>patrik.r.jakobsson@gmail.com</email>
</author>
<published>2021-01-18T20:36:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c8b7359f207d548d8f898d7491c35d05b2feba0a'/>
<id>urn:sha1:c8b7359f207d548d8f898d7491c35d05b2feba0a</id>
<content type='text'>
commit ef02684c4e67d8c35ac83083564135bc7b1d3445 upstream.

The bdc pci driver is going to be removed due to it not existing in the
wild. This patch turns off compilation of the driver so that stable
kernels can also pick up the change. This helps the out-of-tree
facetimehd webcam driver as the pci id conflicts with bdc.

Cc: Al Cooper &lt;alcooperx@gmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Acked-by: Felipe Balbi &lt;balbi@kernel.org&gt;
Signed-off-by: Patrik Jakobsson &lt;patrik.r.jakobsson@gmail.com&gt;
Link: https://lore.kernel.org/r/20210118203615.13995-1-patrik.r.jakobsson@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ehci: fix EHCI host controller initialization sequence</title>
<updated>2021-01-30T12:25:56+00:00</updated>
<author>
<name>Eugene Korenevsky</name>
<email>ekorenevsky@astralinux.ru</email>
</author>
<published>2021-01-10T17:36:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c2a8cb52e1fe529b9500459548fe389ff911563f'/>
<id>urn:sha1:c2a8cb52e1fe529b9500459548fe389ff911563f</id>
<content type='text'>
commit 280a9045bb18833db921b316a5527d2b565e9f2e upstream.

According to EHCI spec, EHCI HC clears USBSTS.HCHalted whenever
USBCMD.RS=1.

However, it is a good practice to wait some time after setting USBCMD.RS
(approximately 100ms) until USBSTS.HCHalted become zero.

Without this waiting, VirtualBox's EHCI virtual HC accidentally hangs
(see BugLink).

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211095
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Eugene Korenevsky &lt;ekorenevsky@astralinux.ru&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20210110173609.GA17313@himera.home
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio: ad5504: Fix setting power-down state</title>
<updated>2021-01-30T12:25:55+00:00</updated>
<author>
<name>Lars-Peter Clausen</name>
<email>lars@metafoo.de</email>
</author>
<published>2020-12-09T10:46:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1148a9f140a99037be4aba8dc0fb5a9181151146'/>
<id>urn:sha1:1148a9f140a99037be4aba8dc0fb5a9181151146</id>
<content type='text'>
commit efd597b2839a9895e8a98fcb0b76d2f545802cd4 upstream.

The power-down mask of the ad5504 is actually a power-up mask. Meaning if
a bit is set the corresponding channel is powered up and if it is not set
the channel is powered down.

The driver currently has this the wrong way around, resulting in the
channel being powered up when requested to be powered down and vice versa.

Fixes: 3bbbf150ffde ("staging:iio:dac:ad5504: Use strtobool for boolean values")
Signed-off-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Acked-by: Alexandru Ardelean &lt;alexandru.ardelean@analog.com&gt;
Link: https://lore.kernel.org/r/20201209104649.5794-1-lars@metafoo.de
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>can: dev: can_restart: fix use after free bug</title>
<updated>2021-01-30T12:25:55+00:00</updated>
<author>
<name>Vincent Mailhol</name>
<email>mailhol.vincent@wanadoo.fr</email>
</author>
<published>2021-01-20T11:41:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=260925a0b7d2da5449f8ecfd02c1405e0c8a45b8'/>
<id>urn:sha1:260925a0b7d2da5449f8ecfd02c1405e0c8a45b8</id>
<content type='text'>
[ Upstream commit 03f16c5075b22c8902d2af739969e878b0879c94 ]

After calling netif_rx_ni(skb), dereferencing skb is unsafe.
Especially, the can_frame cf which aliases skb memory is accessed
after the netif_rx_ni() in:
      stats-&gt;rx_bytes += cf-&gt;len;

Reordering the lines solves the issue.

Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface")
Link: https://lore.kernel.org/r/20210120114137.200019-2-mailhol.vincent@wanadoo.fr
Signed-off-by: Vincent Mailhol &lt;mailhol.vincent@wanadoo.fr&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields</title>
<updated>2021-01-30T12:25:55+00:00</updated>
<author>
<name>Ben Skeggs</name>
<email>bskeggs@redhat.com</email>
</author>
<published>2021-01-13T07:12:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6a2aa69a8e0ac25fb4e31e8abd85f7e920ded52a'/>
<id>urn:sha1:6a2aa69a8e0ac25fb4e31e8abd85f7e920ded52a</id>
<content type='text'>
[ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ]

Noticed while debugging GA102.

Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/nouveau/bios: fix issue shadowing expansion ROMs</title>
<updated>2021-01-30T12:25:55+00:00</updated>
<author>
<name>Ben Skeggs</name>
<email>bskeggs@redhat.com</email>
</author>
<published>2021-01-13T07:12:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c16b56eb91cdc4d4889046dade605462192a670d'/>
<id>urn:sha1:c16b56eb91cdc4d4889046dade605462192a670d</id>
<content type='text'>
[ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ]

This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.

Noticed on GA102, which lacks a type 0x70 image compared to TU102,.

[  906.364197] nouveau 0000:09:00.0: bios: 00000000: type 00, 65024 bytes
[  906.381205] nouveau 0000:09:00.0: bios: 0000fe00: type 03, 91648 bytes
[  906.405213] nouveau 0000:09:00.0: bios: 00026400: type e0, 22016 bytes
[  906.410984] nouveau 0000:09:00.0: bios: 0002ba00: type e0, 366080 bytes

vs

[   22.961901] nouveau 0000:09:00.0: bios: 00000000: type 00, 60416 bytes
[   22.984174] nouveau 0000:09:00.0: bios: 0000ec00: type 03, 71168 bytes
[   23.010446] nouveau 0000:09:00.0: bios: 00020200: type e0, 48128 bytes
[   23.028220] nouveau 0000:09:00.0: bios: 0002be00: type e0, 140800 bytes
[   23.080196] nouveau 0000:09:00.0: bios: 0004e400: type 70, 7168 bytes

Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: ufs: Correct the LUN used in eh_device_reset_handler() callback</title>
<updated>2021-01-30T12:25:55+00:00</updated>
<author>
<name>Can Guo</name>
<email>cang@codeaurora.org</email>
</author>
<published>2020-12-28T12:04:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a4cdbf4805bfed8f39e6b25f113588064d9a6ac5'/>
<id>urn:sha1:a4cdbf4805bfed8f39e6b25f113588064d9a6ac5</id>
<content type='text'>
[ Upstream commit 35fc4cd34426c242ab015ef280853b7bff101f48 ]

Users can initiate resets to specific SCSI device/target/host through
IOCTL. When this happens, the SCSI cmd passed to eh_device/target/host
_reset_handler() callbacks is initialized with a request whose tag is -1.
In this case it is not right for eh_device_reset_handler() callback to
count on the LUN get from hba-&gt;lrb[-1]. Fix it by getting LUN from the SCSI
device associated with the SCSI cmd.

Link: https://lore.kernel.org/r/1609157080-26283-1-git-send-email-cang@codeaurora.org
Reviewed-by: Avri Altman &lt;avri.altman@wdc.com&gt;
Reviewed-by: Stanley Chu &lt;stanley.chu@mediatek.com&gt;
Signed-off-by: Can Guo &lt;cang@codeaurora.org&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
