NACK/Cmnt: [J/L][PATCH 0/2] loop: fix regression from max_loop default value change
Mauricio Faria de Oliveira
mfo at canonical.com
Tue Aug 1 16:35:53 UTC 2023
On Thu, Jul 27, 2023 at 5:06 AM Stefan Bader <stefan.bader at canonical.com> wrote:
>
> 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
Thanks for the detailed clarification / rationale.
I'll re-submit the series with the same fix for both releases.
--
Mauricio Faria de Oliveira
More information about the kernel-team
mailing list