<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v5.4.212</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.212</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.212'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-09-05T08:27:47+00:00</updated>
<entry>
<title>io_uring: disable polling pollfree files</title>
<updated>2022-09-05T08:27:47+00:00</updated>
<author>
<name>Pavel Begunkov</name>
<email>asml.silence@gmail.com</email>
</author>
<published>2022-09-01T15:19:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fc78b2fc21f10c4c9c4d5d659a685710ffa63659'/>
<id>urn:sha1:fc78b2fc21f10c4c9c4d5d659a685710ffa63659</id>
<content type='text'>
Older kernels lack io_uring POLLFREE handling. As only affected files
are signalfd and android binder the safest option would be to disable
polling those files via io_uring and hope there are no users.

Fixes: 221c5eb233823 ("io_uring: add support for IORING_OP_POLL")
Signed-off-by: Pavel Begunkov &lt;asml.silence@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Fix pixel clock programming</title>
<updated>2022-09-05T08:27:47+00:00</updated>
<author>
<name>Ilya Bakoulin</name>
<email>Ilya.Bakoulin@amd.com</email>
</author>
<published>2022-07-26T20:19:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5c5cd52ab09d408839f55ccf6fae4a3a58fd0bb7'/>
<id>urn:sha1:5c5cd52ab09d408839f55ccf6fae4a3a58fd0bb7</id>
<content type='text'>
[ Upstream commit 04fb918bf421b299feaee1006e82921d7d381f18 ]

[Why]
Some pixel clock values could cause HDMI TMDS SSCPs to be misaligned
between different HDMI lanes when using YCbCr420 10-bit pixel format.

BIOS functions for transmitter/encoder control take pixel clock in kHz
increments, whereas the function for setting the pixel clock is in 100Hz
increments. Setting pixel clock to a value that is not on a kHz boundary
will cause the issue.

[How]
Round pixel clock down to nearest kHz in 10/12-bpc cases.

Reviewed-by: Aric Cyr &lt;Aric.Cyr@amd.com&gt;
Acked-by: Brian Chang &lt;Brian.Chang@amd.com&gt;
Signed-off-by: Ilya Bakoulin &lt;Ilya.Bakoulin@amd.com&gt;
Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: clear optc underflow before turn off odm clock</title>
<updated>2022-09-05T08:27:46+00:00</updated>
<author>
<name>Fudong Wang</name>
<email>Fudong.Wang@amd.com</email>
</author>
<published>2022-07-27T04:01:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=814b756d4ec3a8728debb116cf49005feada7750'/>
<id>urn:sha1:814b756d4ec3a8728debb116cf49005feada7750</id>
<content type='text'>
[ Upstream commit b2a93490201300a749ad261b5c5d05cb50179c44 ]

[Why]
After ODM clock off, optc underflow bit will be kept there always and clear not work.
We need to clear that before clock off.

[How]
Clear that if have when clock off.

Reviewed-by: Alvin Lee &lt;alvin.lee2@amd.com&gt;
Acked-by: Tom Chung &lt;chiahsuan.chung@amd.com&gt;
Signed-off-by: Fudong Wang &lt;Fudong.Wang@amd.com&gt;
Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amd/display: Avoid MPC infinite loop</title>
<updated>2022-09-05T08:27:46+00:00</updated>
<author>
<name>Josip Pavic</name>
<email>Josip.Pavic@amd.com</email>
</author>
<published>2022-07-21T19:33:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a06e4eb6516969fd55cb63c232b508eab82be45e'/>
<id>urn:sha1:a06e4eb6516969fd55cb63c232b508eab82be45e</id>
<content type='text'>
[ Upstream commit 8de297dc046c180651c0500f8611663ae1c3828a ]

[why]
In some cases MPC tree bottom pipe ends up point to itself.  This causes
iterating from top to bottom to hang the system in an infinite loop.

[how]
When looping to next MPC bottom pipe, check that the pointer is not same
as current to avoid infinite loop.

Reviewed-by: Josip Pavic &lt;Josip.Pavic@amd.com&gt;
Reviewed-by: Jun Lei &lt;Jun.Lei@amd.com&gt;
Acked-by: Alex Hung &lt;alex.hung@amd.com&gt;
Signed-off-by: Aric Cyr &lt;aric.cyr@amd.com&gt;
Tested-by: Daniel Wheeler &lt;daniel.wheeler@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>fbdev: fb_pm2fb: Avoid potential divide by zero error</title>
<updated>2022-09-05T08:27:45+00:00</updated>
<author>
<name>Letu Ren</name>
<email>fantasquex@gmail.com</email>
</author>
<published>2022-08-18T10:44:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7d9591b32a9092fc6391a316b56e8016c6181c3d'/>
<id>urn:sha1:7d9591b32a9092fc6391a316b56e8016c6181c3d</id>
<content type='text'>
commit 19f953e7435644b81332dd632ba1b2d80b1e37af upstream.

In `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be
copied from user, then go through `fb_set_var()` and
`info-&gt;fbops-&gt;fb_check_var()` which could may be `pm2fb_check_var()`.
Along the path, `var-&gt;pixclock` won't be modified. This function checks
whether reciprocal of `var-&gt;pixclock` is too high. If `var-&gt;pixclock` is
zero, there will be a divide by zero error. So, it is necessary to check
whether denominator is zero to avoid crash. As this bug is found by
Syzkaller, logs are listed below.

divide error in pm2fb_check_var
Call Trace:
 &lt;TASK&gt;
 fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015
 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110
 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189

Reported-by: Zheyu Ma &lt;zheyuma97@gmail.com&gt;
Signed-off-by: Letu Ren &lt;fantasquex@gmail.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>HID: hidraw: fix memory leak in hidraw_release()</title>
<updated>2022-09-05T08:27:45+00:00</updated>
<author>
<name>Karthik Alapati</name>
<email>mail@karthek.com</email>
</author>
<published>2022-07-28T15:43:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=53c7c4d5d40b45c127cb1193bf3e9670f844c3cf'/>
<id>urn:sha1:53c7c4d5d40b45c127cb1193bf3e9670f844c3cf</id>
<content type='text'>
commit a5623a203cffe2d2b84d2f6c989d9017db1856af upstream.

Free the buffered reports before deleting the list entry.

BUG: memory leak
unreferenced object 0xffff88810e72f180 (size 32):
  comm "softirq", pid 0, jiffies 4294945143 (age 16.080s)
  hex dump (first 32 bytes):
    64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00  d..j............
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff814ac6c3&gt;] kmemdup+0x23/0x50 mm/util.c:128
    [&lt;ffffffff8357c1d2&gt;] kmemdup include/linux/fortify-string.h:440 [inline]
    [&lt;ffffffff8357c1d2&gt;] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521
    [&lt;ffffffff8356ddad&gt;] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992
    [&lt;ffffffff8356e41e&gt;] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065
    [&lt;ffffffff835f0d3f&gt;] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284
    [&lt;ffffffff82d3c7f9&gt;] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670
    [&lt;ffffffff82d3cc26&gt;] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747
    [&lt;ffffffff82ef1e14&gt;] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988
    [&lt;ffffffff812f50a8&gt;] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474
    [&lt;ffffffff812f5586&gt;] expire_timers kernel/time/timer.c:1519 [inline]
    [&lt;ffffffff812f5586&gt;] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790
    [&lt;ffffffff812f56e4&gt;] __run_timers kernel/time/timer.c:1768 [inline]
    [&lt;ffffffff812f56e4&gt;] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803
    [&lt;ffffffff848000e6&gt;] __do_softirq+0xe6/0x2ea kernel/softirq.c:571
    [&lt;ffffffff81246db0&gt;] invoke_softirq kernel/softirq.c:445 [inline]
    [&lt;ffffffff81246db0&gt;] __irq_exit_rcu kernel/softirq.c:650 [inline]
    [&lt;ffffffff81246db0&gt;] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662
    [&lt;ffffffff84574f02&gt;] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106
    [&lt;ffffffff84600c8b&gt;] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649
    [&lt;ffffffff8458a070&gt;] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline]
    [&lt;ffffffff8458a070&gt;] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline]
    [&lt;ffffffff8458a070&gt;] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline]
    [&lt;ffffffff8458a070&gt;] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554

Link: https://syzkaller.appspot.com/bug?id=19a04b43c75ed1092021010419b5e560a8172c4f
Reported-by: syzbot+f59100a0428e6ded9443@syzkaller.appspotmail.com
Signed-off-by: Karthik Alapati &lt;mail@karthek.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>media: pvrusb2: fix memory leak in pvr_probe</title>
<updated>2022-09-05T08:27:45+00:00</updated>
<author>
<name>Dongliang Mu</name>
<email>mudongliangabcd@gmail.com</email>
</author>
<published>2022-06-09T07:35:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=466b67c0543b2ae67814d053f6e29b39be6b33bb'/>
<id>urn:sha1:466b67c0543b2ae67814d053f6e29b39be6b33bb</id>
<content type='text'>
commit 945a9a8e448b65bec055d37eba58f711b39f66f0 upstream.

The error handling code in pvr2_hdw_create forgets to unregister the
v4l2 device. When pvr2_hdw_create returns back to pvr2_context_create,
it calls pvr2_context_destroy to destroy context, but mp-&gt;hdw is NULL,
which leads to that pvr2_hdw_destroy directly returns.

Fix this by adding v4l2_device_unregister to decrease the refcount of
usb interface.

Reported-by: syzbot+77b432d57c4791183ed4@syzkaller.appspotmail.com
Signed-off-by: Dongliang Mu &lt;mudongliangabcd@gmail.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>udmabuf: Set the DMA mask for the udmabuf device (v2)</title>
<updated>2022-09-05T08:27:45+00:00</updated>
<author>
<name>Vivek Kasireddy</name>
<email>vivek.kasireddy@intel.com</email>
</author>
<published>2022-05-20T20:52:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=63d8c1933ed280717f934e2bc2edd869bb66f329'/>
<id>urn:sha1:63d8c1933ed280717f934e2bc2edd869bb66f329</id>
<content type='text'>
commit 9e9fa6a9198b767b00f48160800128e83a038f9f upstream.

If the DMA mask is not set explicitly, the following warning occurs
when the userspace tries to access the dma-buf via the CPU as
reported by syzbot here:

WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188
__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188
Modules linked in:
CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted
5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188
Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0
83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 &lt;0f&gt; 0b 45
   31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00
RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408
RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f
R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002
R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000
FS:  0000555556e30300(0000) GS:ffff8880b9d00000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264
 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72
 begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126
 dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164
 dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:874 [inline]
 __se_sys_ioctl fs/ioctl.c:860 [inline]
 __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f62fcf530f9
Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89
f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01
f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9
RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006
RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
 &lt;/TASK&gt;

v2: Dont't forget to deregister if DMA mask setup fails.

Reported-by: syzbot+10e27961f4da37c443b2@syzkaller.appspotmail.com
Cc: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
Signed-off-by: Vivek Kasireddy &lt;vivek.kasireddy@intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/20220520205235.3687336-1-vivek.kasireddy@intel.com
Signed-off-by: Gerd Hoffmann &lt;kraxel@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>HID: steam: Prevent NULL pointer dereference in steam_{recv,send}_report</title>
<updated>2022-09-05T08:27:45+00:00</updated>
<author>
<name>Lee Jones</name>
<email>lee.jones@linaro.org</email>
</author>
<published>2022-07-08T07:40:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fa2b822d86be5b5ad54fe4fa2daca464e71ff90a'/>
<id>urn:sha1:fa2b822d86be5b5ad54fe4fa2daca464e71ff90a</id>
<content type='text'>
commit cd11d1a6114bd4bc6450ae59f6e110ec47362126 upstream.

It is possible for a malicious device to forgo submitting a Feature
Report.  The HID Steam driver presently makes no prevision for this
and de-references the 'struct hid_report' pointer obtained from the
HID devices without first checking its validity.  Let's change that.

Cc: Jiri Kosina &lt;jikos@kernel.org&gt;
Cc: Benjamin Tissoires &lt;benjamin.tissoires@redhat.com&gt;
Cc: linux-input@vger.kernel.org
Fixes: c164d6abf3841 ("HID: add driver for Valve Steam Controller")
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq</title>
<updated>2022-09-05T08:27:44+00:00</updated>
<author>
<name>Saurabh Sengar</name>
<email>ssengar@linux.microsoft.com</email>
</author>
<published>2022-08-04T15:55:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b4c928ace9a123629eeb14ec5d7ee8f73e5ac668'/>
<id>urn:sha1:b4c928ace9a123629eeb14ec5d7ee8f73e5ac668</id>
<content type='text'>
commit d957e7ffb2c72410bcc1a514153a46719255a5da upstream.

storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it
doesn't need to make forward progress under memory pressure.  Marking this
workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a
non-WQ_MEM_RECLAIM workqueue.  In the current state it causes the following
warning:

[   14.506347] ------------[ cut here ]------------
[   14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn
[   14.506360] WARNING: CPU: 0 PID: 8 at &lt;-snip-&gt;kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130
[   14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu
[   14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022
[   14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun
[   14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130
		&lt;-snip-&gt;
[   14.506408] Call Trace:
[   14.506412]  __flush_work+0xf1/0x1c0
[   14.506414]  __cancel_work_timer+0x12f/0x1b0
[   14.506417]  ? kernfs_put+0xf0/0x190
[   14.506418]  cancel_delayed_work_sync+0x13/0x20
[   14.506420]  disk_block_events+0x78/0x80
[   14.506421]  del_gendisk+0x3d/0x2f0
[   14.506423]  sr_remove+0x28/0x70
[   14.506427]  device_release_driver_internal+0xef/0x1c0
[   14.506428]  device_release_driver+0x12/0x20
[   14.506429]  bus_remove_device+0xe1/0x150
[   14.506431]  device_del+0x167/0x380
[   14.506432]  __scsi_remove_device+0x11d/0x150
[   14.506433]  scsi_remove_device+0x26/0x40
[   14.506434]  storvsc_remove_lun+0x40/0x60
[   14.506436]  process_one_work+0x209/0x400
[   14.506437]  worker_thread+0x34/0x400
[   14.506439]  kthread+0x121/0x140
[   14.506440]  ? process_one_work+0x400/0x400
[   14.506441]  ? kthread_park+0x90/0x90
[   14.506443]  ret_from_fork+0x35/0x40
[   14.506445] ---[ end trace 2d9633159fdc6ee7 ]---

Link: https://lore.kernel.org/r/1659628534-17539-1-git-send-email-ssengar@linux.microsoft.com
Fixes: 436ad9413353 ("scsi: storvsc: Allow only one remove lun work item to be issued per lun")
Reviewed-by: Michael Kelley &lt;mikelley@microsoft.com&gt;
Signed-off-by: Saurabh Sengar &lt;ssengar@linux.microsoft.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
