Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #956505

Bug#928125: Revert commit 310ca162d77

Cross-posted to 2 groups.

Show all headers | View raw

On Mon, Apr 29, 2019 at 02:05:42PM +0200, Salvatore Bonaccorso wrote:
> 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@quack2.suse.cz/ .

Sorry for the delay here.  No, I didn't find any time for the followup
stuff here, and Jan is right, this should just be dropped.

I've now reverted it from 3.18.y, 4.4.y, 4.9.y, and 4.14.y.

thanks,

greg k-h

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever Brad Barnett <debian-bugs2@L8R.net> - 2019-04-28 18:10 +0200
  Bug#928125: more info Brad Barnett <debian-bugs2@L8R.net> - 2019-04-28 18:30 +0200
  Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever Michael Biebl <biebl@debian.org> - 2019-04-28 19:50 +0200
    Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever Michael Biebl <biebl@debian.org> - 2019-04-28 19:50 +0200
    Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever Michael Biebl <biebl@debian.org> - 2019-04-28 20:10 +0200
    Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever Brad Barnett <debian-bugs2@L8R.net> - 2019-04-28 20:40 +0200
  Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever Salvatore Bonaccorso <carnil@debian.org> - 2019-04-28 23:10 +0200
  Bug#928125: Revert commit 310ca162d77 Greg KH <gregkh@linuxfoundation.org> - 2019-04-29 16:20 +0200
  Bug#928125: losetup causes Dead systemd-udevd processes, blocks forever Salvatore Bonaccorso <carnil@debian.org> - 2019-05-03 14:20 +0200

csiph-web