[J/L][PATCH 0/2] loop: fix regression from max_loop default value change
https://lists.ubuntu.com/archives/kernel-team/2023-July/141350.html

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-hwe-5.15 in Ubuntu.
https://bugs.launchpad.net/bugs/2015400

Title:
  losetup with mknod fails on jammy with kernel 5.15.0-69-generic

Status in linux package in Ubuntu:
  Invalid
Status in linux-hwe-5.15 package in Ubuntu:
  Invalid
Status in linux source package in Focal:
  Invalid
Status in linux-hwe-5.15 source package in Focal:
  In Progress
Status in linux source package in Jammy:
  In Progress
Status in linux-hwe-5.15 source package in Jammy:
  Invalid
Status in linux source package in Lunar:
  In Progress
Status in linux-hwe-5.15 source package in Lunar:
  Invalid
Status in linux source package in Mantic:
  Invalid
Status in linux-hwe-5.15 source package in Mantic:
  Invalid

Bug description:
  [ 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.

  [ 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

  Original Description:
  ---

  losetup fails with devices created manually by mknod on kernel
  5.15.0-69-generic

  # fallocate -l 1G test
  # mknod -m 660 /dev/loop8 b 7 8
  # chown root:disk /dev/loop8
  # losetup /dev/loop8 ./test
  losetup: ./test: failed to set up loop device: Device or resource busy

  Possibly as a result of this patch:
  
https://lore.kernel.org/lkml/20221208200605.756287-1-isaacmanjar...@google.com/T/

  which was introduced in 5.15.0-68:
  
http://launchpadlibrarian.net/653145495/linux_5.15.0-67.74_5.15.0-68.75.diff.gz

  On a machine prior to this change (no issue with losetup):
  # cat /sys/module/loop/parameters/max_loop
  0
  # uname -r
  5.15.0-58-generic

  On a machine after the change (has losetup issue as described above):
  # cat /sys/module/loop/parameters/max_loop
  8
  # uname -r
  5.15.0-69-generic

  So it looks like the default changed and the max amount of loop
  devices that can be created with mknod (not loop-control) is 8. If we
  set max_loop=0 on the kernel command line, it works as before. Cannot
  unload and reload module on a running system to change the parameter
  because it is built into the kernel.

  Another workaround is to use `losetup --find` but that means you
  cannot create with named devices created with mknod.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2015400/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to