linux-kernel - Re: Loopback device hung [was Re: xfs deadlock on 3.9-rc5 running xfstests case #78]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 04 Apr 2013 16:30:54 -0400
From:	Phillip Susi <psusi@...ntu.com>
To:	Jens Axboe <axboe@...nel.dk>
CC:	CAI Qian <caiqian@...hat.com>, Dave Chinner <david@...morbit.com>,
	xfs@....sgi.com, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Loopback device hung [was Re: xfs deadlock on 3.9-rc5 running
 xfstests case #78]

> I have not tested it yet, but I am pretty sure it won't work.  It
> looks like the patch changes the BLKRRPART path to go ahead and remove
> existing partitions when GENHD_FL_NO_PARTSCAN is set.  loop doesn't
> issue the BLKRRPART ioctl when !LO_FLAGS_PARTSCAN so this won't help.
>  I think loop needs to set GENHD_FL_NO_PARTSCAN and then issue the
> ioctl regardless of the LO_FLAGS_PARTSCAN flag to get the partitions
> to be removed.  I will try to test tonight.

After testing, my initial thoughts appeared to have been correct.  I had
to modify the patch as follows.  To test, simply do:

truncate -s 10m img
losetup /dev/loop0 img
parted /dev/loop0
mklabel msdos
mkpart primary ext2 1m 2m
quit
ls /dev/loop0*

Note the /dev/loop0p1 node.  Run losetup -d /dev/loop0 and see if it is
still there.



View attachment "loop.diff" of type "text/plain" (1671 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (554 bytes)