[Patch] Search all /dev/loop possibilities beyond gaps

[GoogleCodeExporter]

So far, crypt/veritysetup will stop searching /dev/loop%d as soon as they hit a 
non-existent path.
Sometimes however there may be gaps and one wants crypt/veritysetup to continue 
searching /dev/loop.

Patch attached to change the behaviour accordingly.

Original issue reported on code.google.com by AndreasFuchsSIT on 12 Aug 2013 at 9:15

Attachments:

• 0001-Search-for-loopback-devices-beyond-gaps-in-loop-numb.patch

[GoogleCodeExporter]

Well, it is intentionally this way. Which distro creates gaps in unused 
/dev/loopX?
Is this some hardened config with static manually created nodes in /dev?

(It is obsolete code anyway, recent kernel has better way to get free loop 
device and cryptsetup/veritsetup use it - it will falback to this code only if 
kernel is old.)

Readir() would be better to here and I also think stat() on nonexistent deice 
nodes can cause problems sometimes.

Original comment by gmazyl...@gmail.com on 17 Aug 2013 at 1:26

[GoogleCodeExporter]

Well in this case, it was about an early-boot script in an initramfs-tool's 
based initrd of Ubuntu.
In this environment, there is a udev under ${rootmnt}/dev and only a 
minimalistic /dev.
So I added some mknods for loop200 to 255, in order to not disturb the later 
runtime-system.

So here is the usecase.

My current workaround is to mknod loop0 to 55 that reference the 200 to 255 
devices.
However in order to be a little more consistent, I wanted to have the loops 
reference the correct devices.

Love to hear, if there is a more elegant solution.
Regarding the readdir vs stat: I tried to keep my patch minimal. I guess 
readdir could be nice regardless of my patch...

Cheers,
Andreas

Original comment by AndreasFuchsSIT on 19 Aug 2013 at 9:23

[GoogleCodeExporter]

BTW can you paste "cat /sys/module/loop/parameters/max_loop" ?

I think that max loop devices should correspond to this value (but will need to 
check kernel code, that is always some surprise).

Original comment by gmazyl...@gmail.com on 30 Aug 2013 at 9:32

[GoogleCodeExporter]

Sure, it's 0 ... I hope that means unbound, or possibly 255 ?

Original comment by AndreasFuchsSIT on 2 Sep 2013 at 7:42

[GoogleCodeExporter]

Here 0 means no preallocated loop devices, all devices should be created 
dynamically once needed (and there is no longer 255 loop devices limit).

From kernel source:
        /*                                                                                    * If max_loop is specified, create that many devices upfront.
 * This also becomes a hard limit. If max_loop is not specified,
 * create CONFIG_BLK_DEV_LOOP_MIN_COUNT loop devices at module
 * init time. Loop devices can be requested on-demand with the
 * /dev/loop-control interface, or be instantiated by accessing
 * a 'dead' device node.
 */                                            

Anyway, I think if you mount your /dev as tmpdevfs (which is in-kernel virtual 
fs used before udev takes over), loop allocation should work without need to 
pre-allocated static nodes.

Original comment by gmazyl...@gmail.com on 2 Sep 2013 at 5:21

[GoogleCodeExporter]

Hmmm... well, I guess I'll have to see what to do... Wanted to leave Ubuntu's 
initrd as untouched as possible. Also I don't know if there's side effects in 
having tmpdevfs and udev running at the same time...

Anyways, I guess I'll either stick to the current version.
If I ever find the time, I guess I could also move-mount or bindmount udev 
temporarily to /dev from /root/dev. But as always, time's short... ;-)

(To be closed then, I guess)

Thanks a lot for all the help. Sorry that I posted some false-positive reports.

Cheers,
Andreas

Original comment by AndreasFuchsSIT on 3 Sep 2013 at 7:20

[GoogleCodeExporter]

ok, closing this issue, I think dynamic kernel loop handling works as expected.
(But initrd environment is always tricky :)

Thanks.

Original comment by gmazyl...@gmail.com on 10 Nov 2013 at 9:15

• Changed state: Invalid