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).
Tested on v6.5-rc2.
v2:
- 1/2: simpler change per Christoph's suggestion.
same test results (specially the last one), as expected.
- 2/2: added Reviewed-by: Christoph.
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 | 40 ++++++++++++++++++++++++++++++++++++++--
1 file changed, 38 insertions(+), 2 deletions(-)
--
2.39.2
