losetup with mknod fails on jammy with kernel 5.15.0-69-generic
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Focal |
Invalid
|
Undecided
|
Unassigned | ||
Jammy |
Fix Committed
|
Medium
|
Mauricio Faria de Oliveira | ||
Lunar |
Won't Fix
|
Medium
|
Mauricio Faria de Oliveira | ||
Mantic |
Invalid
|
Undecided
|
Unassigned |
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-
* 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 ]
* 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:/
[2] https:/
[3] https:/
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://<email address hidden>/T/
which was introduced in 5.15.0-68:
http://
On a machine prior to this change (no issue with losetup):
# cat /sys/module/
0
# uname -r
5.15.0-58-generic
On a machine after the change (has losetup issue as described above):
# cat /sys/module/
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.
affects: | nvidia-graphics-drivers-525 (Ubuntu) → ubuntu |
affects: | ubuntu → linux (Ubuntu) |
affects: | linux (Ubuntu) → linux |
affects: | linux → linux (Ubuntu) |
tags: | added: jammy |
tags: | added: kernel-bug |
description: | updated |
Changed in linux (Ubuntu Lunar): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Jammy): | |
status: | In Progress → Fix Committed |
Changed in linux-hwe-5.15 (Ubuntu Focal): | |
assignee: | Mauricio Faria de Oliveira (mfo) → nobody |
no longer affects: | linux-hwe-5.15 (Ubuntu) |
no longer affects: | linux-hwe-5.15 (Ubuntu Focal) |
no longer affects: | linux-hwe-5.15 (Ubuntu Jammy) |
no longer affects: | linux-hwe-5.15 (Ubuntu Lunar) |
no longer affects: | linux-hwe-5.15 (Ubuntu Mantic) |
Status changed to 'Confirmed' because the bug affects multiple users.