On Wed 20-03-19 16:16:01, Greg KH wrote: > On Wed, Mar 20, 2019 at 04:12:31PM +0100, Greg KH wrote: > > 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. > > > > Ugh, ok. > > > > > Another option would be to backport other locking fixes for the loop > > > device but honestly I don't think that's a stable material - never heard > > > of real users hitting problems, only syzkaller could, and we are still > > > fixing up some small glitches resulting from that rework... > > > > I tried to backport a number of the loop fixes, and odds are I am the > > one that grabbed this. There are other loop locking fixes in the stable > > releases, I don't know if I can just revert this one, let me check... > > Nope, does not revert cleanly due to the other loop fixes I added after > this one. > > So either I back out _all_ of the loop patches, or we leave what we have > now, or we add the proper fixes to get things working. I'd like to have > this all work properly, so why not just have me backport the needed > fixes that are upstream? Sure, that is another option. Be sure to include recent fixups: 40853d6fc619 "loop: do not print warn message if partition scan is successful" 758a58d0bc67 "loop: set GENHD_FL_NO_PART_SCAN after blkdev_reread_part()" otherwise you need commits: b1ab5fa309e6 "block/loop: Don't grab "struct file" for vfs_getattr() operation." ... 628bd8594709 "loop: Fix double mutex_unlock(&loop_ctl_mutex) in loop_control_ioctl()" to drivers/block/loop.c. It's just that my experience tells me that when there were 15 original patches in the series and then 3 followup fixups, the series is not usually worth the risk for something nobody hit besides fuzzers... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
