APPLIED: [J/L][PATCH v2 0/2] loop: fix regression from max_loop default value change

Stefan Bader stefan.bader at canonical.com
Thu Aug 3 18:03:02 UTC 2023


On 02.08.23 00:52, Mauricio Faria de Oliveira wrote:
> BugLink: https://bugs.launchpad.net/bugs/2015400
> 
> [ Changes ]
> 
>   * v2: Jammy: use fix as in Lunar, instead of a revert.
> 
> [ Impact ]
> 
>   * Regression in the loop block driver in Jammy kernel
>     between 5.15.0-67 to 5.15.0-68 (in v5.15.86 stable),
>     due to a change in the default behavior (value) of
>     kernel parameter `max_loop` (from 0 to 8) in commit:
>     `loop: Fix the max_loop commandline argument treatment
>     when it is set to 0` (comment #6).
> 
>   * Users of loop devices (major 7) with minor >= 8 now
>     fail to `open()` a loop device created with `mknod()`.
> 
>   * This is a corner case, as most people use `losetup`
>     with usual /dev/loopNUMBER (or `--find`) which are
>     not affected as it uses a different code path.
>     (`losetup` for `/dev/loopNOT-A-NUMBER` is affected.)
> 
>   * Workaround: kernel parameter `max_loop=0`.
> 
> [ Test Steps ]
> 
>   * Run the test cases (losetup and test-loop.c in comment #6):
>     - max_loop not set (default)
>     - max_loop=0
>     - max_loop=8
> 
>   * Verify the default behavior (max_loop not set) is restored.
> 
>   * Verify the modified behavior (max_loop is set) is unchanged.
> 
>   * Patches verified with jammy/lunar-proposed.
>   
> [ Regression Potential ]
> 
>   * Regressions would be limited to the loop block driver,
>     more specifically its default behavior (no parameters)
>     or specific usage of max_loop parameter (tested; looks OK).
> 
> [ Other Info ]
> 
>   * Patch 1 [1] is not quite a fix, but adds CONFIG guards that
>     Patch 2 [2] depends on. (Alternatively, a Patch 2 backport
>     with that could be done, but Patch 1 seems trivial enough.)
> 
>   * The fix on Jammy is only Patch 2, with a trivial backport
>     (that CONFIG option is not in Jammy/v5.15, only in v5.18).
> 
>   * The fix on Lunar is both patches; clean cherry-picks.
> 
>   * The fix on Mantic is both patches too,
>     now in v6.5-rc3, which should be automatically incorporated
>     as Mantic apparently will release with the 6.5 kernel [3]
> 
>     [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=23881aec85f3219e8462e87c708815ee2cd82358
>     [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5faa99f0ce40756ab7bbbce4f16c01ca5ebd5a
>     [3] https://discourse.ubuntu.com/t/introducing-kernel-6-5-for-the-23-10-mantic-minotaur-release
> 
> 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(-)
> 

Applied to lunar,jammy:linux/master-next. Thanks.

-Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE8675DEECBEECEA3.asc
Type: application/pgp-keys
Size: 44613 bytes
Desc: OpenPGP public key
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20230803/d971ab88/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20230803/d971ab88/attachment-0001.sig>


More information about the kernel-team mailing list