APPLIED: [Patch 0/1] [focal/linux-azure-cvm] hv/bounce buffer: Fix a race that can fail disk detection

[Tim Gardner]

Applied to focal/linux-azure-cvm:azure-cvm. Thanks.

-rtg

On 5/2/22 09:02, Tim Gardner wrote:
> BugLink: https://bugs.launchpad.net/bugs/1971164
> 
> SRU Justification
> 
> [Impact]
> 
> The linux-azure-cvm kernel (e.g. Ubuntu-azure-cvm-5.4.0-1078.81+cvm1) has a race
> condition bug in the Linux vmbus bounce buffer code (drivers/hv/hv_bounce.c), and
> as a result somtimes the kenrel fails to detect some of the SCSI disks, and the
> Linux dmesg log may show one of the 2 messages:
> 
> #1: [ 2.995732] sd 3:0:0:3: [sdd] Sector size 0 reported, assuming 512.
> 
> #2: [ 3.651293] scsi host3: scsi scan: INQUIRY result too short (5), using 36
> 
> Sometimes I see a strange call-trace (the 'order's is 18, if I print it)
> 2022-04-26T20:10:18,398144+00:00 kmalloc_order_trace+0x1e/0x80
> 2022-04-26T20:10:18,398147+00:00 __kmalloc+0x3ae/0x4c0
> 2022-04-26T20:10:18,398150+00:00 __scsi_scan_target+0x283/0x590
> 2022-04-26T20:10:18,398155+00:00 scsi_scan_channel.part.16+0x62/0x80
> 2022-04-26T20:10:18,398158+00:00 scsi_scan_host_selected+0xd5/0x150
> 2022-04-26T20:10:18,398160+00:00 store_scan+0xc8/0xe0
> (This is very strange because 'order 18' means (1 << 18) * 4096 bytes = 1GBytes.)
> 
> After some investigation, we eventually got the root cause and made a fix:
> https://github.com/dcui/linux-azure-cvm/commit/ddde4dc33242794000e1d9667a5f9cfa31c15fdf
> 
> With the fix, we no longer see the above strange symptoms.
> Please include the fix into the next release of the v5.4 linux-azure-cvm kernel. Thanks!
> 
> [Test case]
> 
> Microsoft tested
> 
> [Where things could go wrong]
> 
> Some SCSI drives may continue to go undetected.
> 
> [Other Info]
> 
> SF: #00335631
> 
> 
> 

-- 
-----------
Tim Gardner
Canonical, Inc