Apparently, there's an unintended consequence of the improvement for max_loop=0
in commit 85c50197716c ("loop: Fix the max_loop commandline argument treatment
when it is set to 0") which might break programs that handle /dev/loop devices.
The (deprecated) autoloading path fails (ENXIO) if the requested minor number
is greater than or equal to the (new) default (CONFIG_BLK_DEV_LOOP_MIN_COUNT),
when [loop.]max_loop is not specified. This behavior used to work previously.
Patch 1/2 just notes the loop driver's autoloading path is deprecated/legacy.
Patch 2/2 detects whether or not max_loop is set to restore default behavior
as before the regression (and keeps the improvement done by the commit above).
More details in the commit message. This does not seem to be urgent, as the
impact is to very specific/custom applications, and most users (eg, losetup)
should not be impacted, as the dynamic add ioctl() is used.
Thanks,
Mauricio
Mauricio Faria de Oliveira (2):
loop: deprecate autoloading callback loop_probe()
loop: do not enforce max_loop hard limit by (new) default
drivers/block/loop.c | 43 ++++++++++++++++++++++++++++++++++++++++---
1 file changed, 40 insertions(+), 3 deletions(-)
--
2.39.2
