Veritysetup and Cryptsetup: if loop-control present ->only max_loop executions possible

[GoogleCodeExporter]

The current usage of /dev/loop-control seems flawed...

If loop-control is present, loop_utils.c will attempt to get a new loop-device 
from the kernel via LOOP_CTL_GET_FREE and use it. 
However, when the loop-device is detached, it is not removed in the kernel via 
LOOP_CTL_REMOVE.

This means that after a series of get_device(), attach(), detach() calls (i.e. 
veritysetup create, remove, create, remove, ...) the kernel has no more 
loop-devices (available for creation), even though there is tens and hundreds 
of free loop devices around.

To reproduce just bash-loop through a create/remove series until it fails and 
have a look at "losetup -a"...

Possible Solutions:
1. When detaching a loop-device attempt to LOOP_CTL_REMOVE the device if 
/dev/loop-control is present.
2. First iterate over the existing loop-devices in search for a free one and 
only if none was found LOOP_CTL_GET_FREE a new one.

Recommendation:
- Include my patch for iterating over all loop-device (see Bug #173)

If someone with more insight could recommend one of the two proposed solutions, 
I'd me more than happy to quickly implement it and send the patch upstream.

Best regards,
Andreas

Original issue reported on code.google.com by AndreasFuchsSIT on 30 Aug 2013 at 8:42

[GoogleCodeExporter]

Loop device is created with autoclear flag, so it is autoremoved, no remove ctl 
needed.

Only if this functionality is not available, then you have to remove loop 
device manually. This is documented (see man cryptsetup "NOTES ON LOOPBACK 
DEVICE USE" - I think I forgot to add this note to veritysetup man page as 
well).

What is your kernel version? Why is loop autoremoval not working? (Paste 
veritysetup command with --debug switch please.)

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I have Ubuntu 12.10 kernel 3.5.0-39-generic now (I had 3.5.0.36 when it 
happened).
However I cannot reproduce my error anymore (and don't want to downgrade again 
for this).

I deleted my earlier comment since I was using an old libcryptsetup and some 
weird errors out of that.

Since I cannot reproduce the problem, I guess this bug can be closed.

P.S. I was wondering, if these two error-behaviours for small verity-devices 
was intended:
data_device size between 0 and 511: Header detected but device ./file1 is too 
small.
data_device size between 512 and 8191: Error during update of verity header on 
device ./file2.
(Especially the second Error was somewhat misleading for me)

Original comment by AndreasFuchsSIT on 2 Sep 2013 at 9:31

[GoogleCodeExporter]

The loop device allocation and autoremoval iotcl must work - if not it, is bug 
in kernel and should be fixed.
(Sequential /dev/loop* scan is just fallback for old kernels.)

For the device size - loop device it kind of tricky, its size must be at least 
one sector (512 bytes) otherwise loop doesn't work properly.
Losetup has the same problem - try to map file < 512 bytes with it. The same 
applies for the last incomplete sector in file. It is because loop is block 
device and atomic unit for access block device is sector but for file it is one 
byte.

The second error message is strange, I think at least error message is wrong.
Please, if you want, create new issue for this.

(I will check it once I have more time for it.)

Thanks!

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

• Changed state: Done