Re: block loopback driver possible regression since next-20220211

[Christoph Hellwig <hch@lst.de>]

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.