Regression in Jammy ------------------- Before:
$ uname -rv 5.15.0-67-generic #74-Ubuntu SMP Wed Feb 22 14:14:39 UTC 2023 $ truncate -s 1M disk.img $ sudo mknod /dev/loopNaN b 7 8 $ sudo losetup /dev/loopNaN disk.img $ $ sudo ./test-loop $ ... After: $ uname -rv 5.15.0-68-generic #75-Ubuntu SMP Fri Feb 24 13:01:57 UTC 2023 $ truncate -s 1M disk.img $ sudo mknod /dev/loopNaN b 7 8 $ sudo losetup /dev/loopNaN disk.img losetup: /dev/loopNaN: failed to set up loop device: No such device or address $ sudo ./test-loop open: /dev/loop8: No such device or address ... Upstream stable release bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2005113 ... Test-case: $ cat test-loop.c #include <fcntl.h> #include <stdio.h> #include <linux/major.h> #include <sys/stat.h> #include <sys/sysmacros.h> #define LOOP_MINOR 8 #define _DEV_LOOP(x) "/dev/loop" #x #define DEV_LOOP(x) _DEV_LOOP(x) int main() { int rc, fd; rc = mknodat(AT_FDCWD, DEV_LOOP(LOOP_MINOR), S_IFBLK | 0660, makedev(LOOP_MAJOR, LOOP_MINOR)); if (rc == -1) { perror("mknod: " DEV_LOOP(LOOP_MINOR)); return 1; } fd = open(DEV_LOOP(LOOP_MINOR), O_RDWR, 0); if (fd == -1) { perror("open: " DEV_LOOP(LOOP_MINOR)); return 1; } return 0; } $ gcc -o test-loop test-loop.c ** Description changed: + [ 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.) + + [ 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. ** Also affects: linux (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux-hwe-5.15 (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Mantic) Importance: Medium Assignee: Mauricio Faria de Oliveira (mfo) Status: In Progress ** Also affects: linux-hwe-5.15 (Ubuntu Mantic) Importance: Undecided Status: Invalid ** Also affects: linux (Ubuntu Lunar) Importance: Undecided Status: New ** Also affects: linux-hwe-5.15 (Ubuntu Lunar) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Jammy) Status: New => In Progress ** Changed in: linux (Ubuntu Jammy) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Jammy) Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo) ** Changed in: linux (Ubuntu Lunar) Status: New => In Progress ** Changed in: linux (Ubuntu Lunar) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Lunar) Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo) ** Changed in: linux (Ubuntu Mantic) Status: In Progress => Invalid ** Changed in: linux (Ubuntu Mantic) Importance: Medium => Undecided ** Changed in: linux (Ubuntu Mantic) Assignee: Mauricio Faria de Oliveira (mfo) => (unassigned) ** Changed in: linux-hwe-5.15 (Ubuntu Lunar) Status: New => Invalid ** Changed in: linux-hwe-5.15 (Ubuntu Jammy) Status: New => Invalid ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux-hwe-5.15 (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Focal) Status: New => Invalid ** Changed in: linux-hwe-5.15 (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: linux-hwe-5.15 (Ubuntu Focal) Status: New => In Progress ** Changed in: linux-hwe-5.15 (Ubuntu Focal) Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo) ** Description changed: [ 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.) + * 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 + * 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. - + * 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). - + * 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 + * 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. -- 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
