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

Stefan Bader stefan.bader at canonical.com
Thu Jul 27 08:06:41 UTC 2023


On 25.07.23 20:27, Mauricio Faria de Oliveira wrote:
> BugLink: https://bugs.launchpad.net/bugs/2015400
> 
> [ 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 (but it's that now)
>     or specific usage of max_loop parameter (tested; looks OK).
> 
> [ Other Info ]
> 
>   * The fix on Jammy is just a Revert, since it had not been
>     released with the offending patch.
> 
>   * The fix on Lunar is the recently accepted 2 patches [1, 2]
>     as it was released with the offending patch, so let's keep
>     that patch's improvement/behavior for the max_loop=0 case,
>     and "fix"/restore the historical no-limit default behavior.
> 
>   * The fix on Mantic is the recently accepted 2 patches too,
>     now in v6.5-rc3, which should be automatically incorporated
>     as Mantic apparently will release with the 6.5 kernel [3]
> 
>   * 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.)
> 
>     [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 (1):
>    UBUNTU: SAUCE: Revert "loop: Fix the max_loop commandline argument
>      treatment when it is set to 0"
> 
>   drivers/block/loop.c | 28 ++++++++++++++++------------
>   1 file changed, 16 insertions(+), 12 deletions(-)
> 

Rejected for the following reasons:
The patch which introduced the problem was part of upstream stable, so 
regardless of whether the initial release was without it, we should not 
just drop it. Even more so since we will have newer kernels fixed up. 
This would otherwise create a deviated behavior between HWE and base 
release kernels. For that reason 5.15 and 6.2 should be fixed the same way.

-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/20230727/15602200/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/20230727/15602200/attachment-0001.sig>


More information about the kernel-team mailing list