Hi Jan, hi Greg, On Wed, Mar 20, 2019 at 01:58:06PM +0100, Jan Kara wrote: > Hello, > > commit 310ca162d77 "block/loop: Use global lock for ioctl() operation." has > been pushed to multiple stable trees. This patch is a part of larger series > that overhauls the locking inside loopback device upstream and for 4.4, > 4.9, and 4.14 stable trees only this patch from the series is applied. Our > testing now has shown [1] that the patch alone makes present deadlocks > inside loopback driver more likely (the openqa test in our infrastructure > didn't hit the deadlock before whereas with the new kernel it hits it > reliably every time). So I would suggest we revert 310ca162d77 from 4.4, > 4.9, and 4.14 kernels. A user in Debian reported [1], providing the following testcase which showed up after the recent update to 4.9.168-1 in Debian stretch (based on upstream v4.9.168) as follows: dd if=/dev/zero of=/tmp/ff1.raw bs=1G seek=8 count=0 sync sleep 1 parted /tmp/ff1.raw mklabel msdos parted -s /tmp/ff1.raw mkpart primary linux-swap 1 100 parted -s -- /tmp/ff1.raw mkpart primary ext2 101 -1 parted -s -- /tmp/ff1.raw set 2 boot on sleep 5 losetup -Pf /tmp/ff1.raw --show I have verified that the same happens with v4.9.171 where the mentioned commit was not reverted, and bisecting of the testcase showed it was introduced with 3ae3d167f5ec2c7bb5fcd12b7772cfadc93b2305 (v4.9.152~9) (which is the backport of 310ca162d77 for 4.9). Reverting 3ae3d167f5ec2c7bb5fcd12b7772cfadc93b2305 on top of v4.9.171 worked and fixed the respective issue. Can this commit in meanwhile be reverted or is there further ongoing work in integrating the followup fixes as mentioned in https://lore.kernel.org/stable/20190321104110.GF29086@xxxxxxxxxxxxxx/ . Regards, Salvatore [1] https://bugs.debian.org/928125
