Re: regression: blktests block/001 failed with commit "loop: Fix mount(2) failure due to race with LOOP_SET_FD"

[Jens Axboe <axboe@kernel.dk>]

On 8/7/19 11:50 PM, Yi Zhang wrote:
> Hello
> 
>  From kernel 5.3.0-rc3, blktests block/001 triggered a WARNING on aarch64, and I've bisected the bad commit [2]:
> 
> [1]
> [  163.963753] sr 7:0:0:0: Attached scsi CD-ROM sr1
> [  163.963924] sr 7:0:0:0: Attached scsi generic sg3 type 5
> [  163.974924] scsi 9:0:0:0: CD-ROM            Linux    scsi_debug       0188 PQ: 0 ANSI: 7
> [  163.983165] sr 9:0:0:0: Power-on or device reset occurred
> [  164.008597] sr 9:0:0:0: [sr1] scsi-1 drive
> [  164.012896] debugfs: Directory 'sr1' with parent 'block' already present!
> [  164.014426] scsi 6:0:0:0: CD-ROM            Linux    scsi_debug       0188 PQ: 0 ANSI: 7
> [  164.019711] sr 9:0:0:0: Attached scsi CD-ROM sr1
> [  164.019807] scsi 8:0:0:0: CD-ROM            Linux    scsi_debug       0188 PQ: 0 ANSI: 7
> [  164.019981] sr 8:0:0:0: Power-on or device reset occurred
> [  164.027941] sr 6:0:0:0: Power-on or device reset occurred
> [  164.035951] sr 9:0:0:0: Attached scsi generic sg3 type 5
> [  164.040027] sr 8:0:0:0: [sr2] scsi-1 drive
> [  164.040992] sr 8:0:0:0: Attached scsi CD-ROM sr2
> [  164.056098] sr 8:0:0:0: Attached scsi generic sg4 type 5
> [  164.061274] sr 6:0:0:0: [sr3] scsi-1 drive
> [  164.064852] scsi 7:0:0:0: CD-ROM            Linux    scsi_debug       0188 PQ: 0 ANSI: 7
> [  164.066576] sr 6:0:0:0: Attached scsi CD-ROM sr3
> [  164.073700] sr 6:0:0:0: Attached scsi generic sg3 type 5
> [  164.073744] sr 7:0:0:0: Power-on or device reset occurred
> [  164.075275] WARNING: CPU: 21 PID: 3490 at fs/block_dev.c:1899 __blkdev_put+0x238/0x260
> [  164.075276] Modules linked in: scsi_debug sunrpc vfat fat crct10dif_ce ghash_ce sha2_ce sha256_arm64 ipmi_ssif sg sha1_ce ipmi_devintf sbsa_gwdt ipmi_msghandler xgene_hwmon ip_tables xfs libcrc32c sr_mod cdrom ast drm_vram_helper ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm igb i2c_designware_platform gpio_dwapb ahci_platform i2c_algo_bit i2c_designware_core libahci_platform i2c_xgene_slimpro gpio_generic uas rndis_host usb_storage cdc_ether usbnet mii dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_debug]
> [  164.075305] CPU: 21 PID: 3490 Comm: systemd-udevd Not tainted 5.3.0-rc3 #11
> [  164.075306] Hardware name: AppliedMicro(R) OSPREY EV-883832-X3-0001/OSPREY, BIOS 4.9.6 01/04/2019
> [  164.075308] pstate: 60000005 (nZCv daif -PAN -UAO)
> [  164.075310] pc : __blkdev_put+0x238/0x260
> [  164.075312] lr : __blkdev_put+0x50/0x260
> [  164.075313] sp : ffff00001a1cfc80
> [  164.075314] x29: ffff00001a1cfc80 x28: ffff809eebb7e5c0
> [  164.075315] x27: 0000000000000000 x26: 00000000080a005d
> [  164.075317] x25: ffff809f2332d000 x24: ffff809f070557d8
> [  164.075318] x23: ffff809ee44c1ce0 x22: 00000000080a005d
> [  164.075320] x21: ffff0000112d3708 x20: 0000000000000000
> [  164.075321] x19: ffff809f070557c0 x18: 0000000000000000
> [  164.075322] x17: 0000000000000000 x16: 0000000000000000
> [  164.075324] x15: 0000000000000000 x14: 0000000000000000
> [  164.075325] x13: 0000000000000000 x12: 0000000000000000
> [  164.075326] x11: 0000000000000000 x10: 0000000040000028
> [  164.075328] x9 : 000000000000fec0 x8 : 0000000000210d00
> [  164.075329] x7 : ffff809ee3aa8e98 x6 : ffff0000112d3708
> [  164.075331] x5 : 0000000000000060 x4 : ffff7fe027b8eaa0
> [  164.075332] x3 : ffff809f25abae18 x2 : ffff809eebb7e5c0
> [  164.075333] x1 : 0000000000000000 x0 : 0000000000000002
> [  164.075335] Call trace:
> [  164.075337]  __blkdev_put+0x238/0x260
> [  164.075339]  blkdev_put+0xe4/0x118
> [  164.075341]  blkdev_close+0x2c/0x40
> [  164.075343]  __fput+0xa0/0x200
> [  164.075345]  ____fput+0x20/0x30
> [  164.075347]  task_work_run+0xc0/0xf0
> [  164.075349]  do_notify_resume+0x308/0x350
> [  164.075351]  work_pending+0x8/0x10
> [  164.075352] ---[ end trace a99909be528034c4 ]---
> 
> [2]
> commit 89e524c04fa966330e2e80ab2bc50b9944c5847a
> Author: Jan Kara <jack@suse.cz>
> Date:   Tue Jul 30 13:10:14 2019 +0200
> 
>      loop: Fix mount(2) failure due to race with LOOP_SET_FD
>      
>      Commit 33ec3e53e7b1 ("loop: Don't change loop device under exclusive
>      opener") made LOOP_SET_FD ioctl acquire exclusive block device reference
>      while it updates loop device binding. However this can make perfectly
>      valid mount(2) fail with EBUSY due to racing LOOP_SET_FD holding
>      temporarily the exclusive bdev reference in cases like this:
>      
>      for i in {a..z}{a..z}; do
>              dd if=/dev/zero of=$i.image bs=1k count=0 seek=1024
>              mkfs.ext2 $i.image
>              mkdir mnt$i
>      done
>      
>      echo "Run"
>      for i in {a..z}{a..z}; do
>              mount -o loop -t ext2 $i.image mnt$i &
>      done
>      
>      Fix the problem by not getting full exclusive bdev reference in
>      LOOP_SET_FD but instead just mark the bdev as being claimed while we
>      update the binding information. This just blocks new exclusive openers
>      instead of failing them with EBUSY thus fixing the problem.
>      
>      Fixes: 33ec3e53e7b1 ("loop: Don't change loop device under exclusive opener")
>      Cc: stable@vger.kernel.org
>      Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>      Signed-off-by: Jan Kara <jack@suse.cz>
>      Signed-off-by: Jens Axboe <axboe@kernel.dk>
> 
> Feel free to request any kind of further information or assistance.

Can you try with this:

http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus&id=e91455bad5cff40a8c232f2204a5104127e3fec2

-- 
Jens Axboe