On Sat, Feb 19, 2022 at 11:05:23AM -0800, Luis Chamberlain wrote:

Indeed. The issue is that dropping that also does not allow the
association of extra custom higher number loop block nodes created manually
even if you *do* load a respective module before use. That is by design
by the commit, since we're stuffing the nasty old probe logic now under the new
CONFIG_BLOCK_LEGACY_AUTOLOAD. Subtle difference, but same deprecation
effect.

I agree with the approach to stuff all this nasty cruft under
BLOCK_LEGACY_AUTOLOAD however I suspect v5.19 might be too soon to tell if we
can nuke it safely by then though.

Yeah.  5.19 was planned when I submitted this for 5.17, but with it
appearing in 5.18 it is far too early anyway.

I'd go so far as to say that we should sadly make
BLOCK_LEGACY_AUTOLOAD=y for a while before going with an axe to kill it.
I think we have a few hidden gems we'll soon discover might need a bit
more time to adjust.

Probably.

FWIW below is a simple test, which now fails to explain what I mean with
the above.

root@kdevops ~ # cat loop-high-devs.sh 

The interesting part is that the script works if I remove this mknod:

if [[ ! -e $LOOPDEV ]]; then
	mknod $LOOPDEV b 7 $NUM
fi

so it seems like losetup is trying to be smart here and skip the manual
creation if the device exists.  I'll take a look at the code and wіll
prepare a patch for that.