Previously, the imu_timestamp_us variable was incremented twice per
report, causing it to advance by two times the desired amount.
This resulted in incorrect jumps in IMU timestamps reported using
MSC_TIMESTAMP, so userspace applications saw corrupted timing on
functions such as gyroscope-based aim and motion controls.
This is fixed by removing the redundant increment at the start of the
report handling so the remaining can account for the full report
interval.
Fixes: 4ff5b10840 ("HID: nintendo: add IMU support")
Signed-off-by: Christos Maragkos <whitetowersoftware@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Christian Brauner <brauner@kernel.org> says:
Summary:
* all kthreads are isolated in a separate SB_KERNMOUNT of nullfs.
-> no lookup of anything else, no mounting on top of it, completely
isolated.
* init has a separate fs_struct from all kthreads
* scoped_with_init_fs() allows a kthread to temporarily assume init's
fs_struct for filesystem operations.
So this is a bit of a crazy series. When the kernel is started it
roughly goes like this:
init_task
==> create pid 1 (systemd etc.)
==> pid 2 (kthreadd)
After this point all kthreads and PID 1 share the same filesystem state.
That obviously already came up when we discussed pivot_root() as this
allows pivot_root() to rewrite the fs_struct of all kthreads.
This rewriting is really weird and mostly done so kthread can use init's
filesystem state when they would like to. But this really should be
discouraged. The rewriting should also stop completely. I worked a bit
to get rid of it in a more fundamental way. Is it crazy? Yes. Is it
likely broken? Yes. Does it at least boot? Yes.
Instead of sharing fs_struct between kernel threads and pid 1, pid 1
get's a completely separate fs_struct. All kthreads continue sharing
init_fs as before and pid 1's fs_struct is isolated from kthread's
filesystem state. IOW, userspace init cannot affect kthreads filesystem
state anymore and kthreads cannot affect userspace's filesystem state
anymore - without explicit opt-in.
All kthreads are anchored in a kernel internal mount of nullfs that
cannot be mounted on and that cannot be used to follow other mounts.
It's a completely private mount that insulates kthreads.
This series makes performing mountains of filesystem work such as path
lookup and file opening and so on from kthreads hard - painfully so. I
think this is a benefit because it takes the idea of just offloading
_security sensitive_ operations in init's filesystem state and
running random binaries or opening and creating files to kthreads
difficult behind the shed... And imho it should.
The only remaining kernel tasks that actually share init's filesystem
state are usermodhelpers - as they execute random binaries in the root
filesystem. Another concept we should really show the back of the shed.
This gives a lot stronger guarantees than what we have now. This also
makes path lookup from kthreads fail by default. IOW, it won't be
possible anymore to just lookup random stuff in init's filesytem state
without explicitly opting in to that.
The places that need to perform lookup in init's filesystem state may
use scoped_with_init_fs() which will temporarily override the caller's
fs_struct with init's fs_struct.
We now also warn and notice when pid 1 simply stops sharing filesystem
state with us, i.e., abandons it's userspace_init_fs.
On older kernels if PID 1 unshared its filesystem state with us the
kernel simply used the stale fs_struct state implicitly pinning
anything that PID 1 had last used. Even if PID 1 might've moved on to
some completely different fs_struct state and might've even unmounted
the old root.
This has hilarious consequences: Think continuing to dump coredump
state into an implicitly pinned directory somewhere. Calling random
binaries in the old rootfs via usermodehelpers.
Be aggressive about this: We simply reject operating on stale
fs_struct state by reverting userspace_init_fs to nullfs. Every kworker
that does lookups after this point will fail. Every usermodehelper call
will fail. This is a lot stronger but I wouldn't know what it means for
pid 1 to simply stop sharing its fs state with the kernel. Clearly it
wanted to separate so cut all ties.
I've went through the kernel and looked at hopefully everything that
does path lookup from kthreads (workqueues, ...).
TL;DR:
==== PID 1 (systemd) ====
root@localhost:~# stat --file-system /proc/1/root
File: "/proc/1/root"
ID: e3cb00dd533cd3d7 Namelen: 255 Type: ext2/ext3
root@localhost:~# cat /proc/1/mountinfo | wc -l
30
==== PID 2 (kthreadd) ====
root@localhost:~# stat --file-system /proc/2/root
File: "/proc/2/root"
ID: 200000000 Namelen: 255 Type: nullfs
root@localhost:~# cat /proc/2/mountinfo | wc -l
0
* patches from https://patch.msgid.link/20260601-work-kthread-nullfs-v4-0-77ee053060e0@kernel.org: (25 commits)
fs: stop rewriting paths for PF_EXITING | PF_DUMPCORE
fs: stop rewriting kthread fs structs
fs: start all kthreads in nullfs
nullfs: make nullfs multi-instance
devtmpfs: create private mount namespace
fs: add umh argument to struct kernel_clone_args
fs: stop sharing fs_struct between init_task and pid 1
af_unix: use scoped_with_init_fs() for coredump socket lookup
initramfs: use scoped_with_init_fs() for rootfs unpacking
pnfs/blocklayout: use scoped_with_init_fs() for SCSI device lookup
ksmbd: use scoped_with_init_fs() for VFS path operations
ksmbd: use scoped_with_init_fs() for filesystem info path lookup
ksmbd: use scoped_with_init_fs() for share path resolution
fs: use scoped_with_init_fs() for kernel_read_file_from_path_initns()
coredump: use scoped_with_init_fs() for coredump path resolution
btrfs: use scoped_with_init_fs() for update_dev_time()
scsi: target: use scoped_with_init_fs() for APTPL metadata
scsi: target: use scoped_with_init_fs() for ALUA metadata
crypto: ccp: use scoped_with_init_fs() for SEV file access
rnbd: use scoped_with_init_fs() for block device open
...
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-0-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Skip exiting and core-dumping tasks when rewriting fs_struct paths in
chroot_fs_refs(). Such a task is about to release its fs_struct via
exit_fs() anyway, so the worst case is that it lingers on a stale
root/pwd until it does.
This isn't entirely free: a skipped task keeps its reference on the old
root, so after a pivot_root() the old root can't be torn down until the
task is gone. With umount2(MNT_DETACH) that only defers destruction of
the old rootfs; a plain umount() could in principle fail with -EBUSY.
In practice this doesn't matter -- pivot_root(2) is meant to be paired
with MNT_DETACH and isn't issued while other tasks are actively using
the mount namespace -- so the transient pin is harmless.
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-25-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Point init_task's fs_struct (root and pwd) at a private nullfs instance
instead of the mutable rootfs. All kthreads now start isolated in nullfs
and must use scoped_with_init_fs() for any path resolution.
PID 1 is moved from nullfs into the initramfs by init_userspace_fs().
Usermodehelper threads use userspace_init_fs via the umh flag in
copy_fs(). All subsystems that need init's filesystem state for path
resolution already use scoped_with_init_fs() from earlier commits in
this series.
This isolates kthreads from userspace filesystem state and makes it
hard to perform filesystem operations from kthread context.
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-23-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Allow multiple instances of nullfs to be created. Right now we're only
going to use it for kernel-internal purposes but ultimately we can allow
userspace to use it too to e.g., safely overmount stuff.
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-22-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Kernel threads start in a completely isolated nullfs mount. Use
UNSHARE_EMPTY_MNTNS to give the devtmpfsd kthread a private empty mount
namespace with its root and pwd already set up, so it can mount its own
devtmpfs instance instead of unsharing a copy of the initial mount
namespace.
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-21-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Add a umh field to struct kernel_clone_args. When set, copy_fs() copies
from pid 1's fs_struct instead of the kthread's fs_struct. This ensures
usermodehelper threads always get init's filesystem state regardless of
their parent's (kthreadd's) fs.
Usermodehelper threads are not allowed to create mount namespaces
(CLONE_NEWNS), share filesystem state (CLONE_FS), or be started from
a non-initial mount namespace. No usermodehelper currently does this so
we don't need to worry about this restriction.
Set .umh = 1 in user_mode_thread(). At this stage pid 1's fs points to
rootfs which is the same as kthreadd's fs, so this is functionally
equivalent.
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-20-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
wacom_intuos_bt_irq() duplicates the received Bluetooth report with
kmemdup() so that it can pass 10-byte input report payloads to the
common Intuos parser. The helper then copies each payload back into
wacom->data before calling wacom_intuos_irq().
Avoid the allocation and copy by temporarily pointing wacom->data at the
current 10-byte payload while the common parser runs, then restoring the
original report pointer. The Bluetooth report parser keeps using the
original report buffer for dispatch and battery parsing, while the common
parser sees the same payload bytes as before.
This also removes the unchecked kmemdup() result from the Bluetooth IRQ
path.
Suggested-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Spawn kernel_init (PID 1) via kernel_clone() directly instead of
user_mode_thread(), without CLONE_FS. This gives PID 1 its own private
copy of init_task's fs_struct rather than sharing it.
This is a prerequisite for isolating kthreads in nullfs: when
init_task's fs is later pointed at nullfs, PID 1 must not share it
or init_userspace_fs() would modify init_task's fs as well, defeating
the isolation.
At this stage PID 1 still gets rootfs (a private copy rather than a
shared reference), so there is no functional change.
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-19-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Use scoped_with_init_fs() to temporarily override current->fs for the
coredump unix socket path resolution. This replaces the init_root() +
vfs_path_lookup() pattern with scoped_with_init_fs() + kern_path().
The old code used LOOKUP_BENEATH to confine the lookup beneath init's
root. This is dropped because the coredump socket path is absolute and
resolved from root (where ".." is a no-op), and LOOKUP_NO_SYMLINKS
already blocks any symlink-based escape. LOOKUP_BENEATH was redundant
in this context.
unix_find_bsd(SOCK_COREDUMP) ← coredump_sock_connect() ← do_coredump() —
same crashing userspace process
Same security rationale as coredump.
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-18-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Extract the initramfs unpacking code into a separate
unpack_initramfs() function and wrap its invocation from
do_populate_rootfs() with scoped_with_init_fs(). This ensures all
file operations during initramfs unpacking (including filp_open()
calls in do_name() and populate_initrd_image()) happen in init's
filesystem context.
Note that security_initramfs_populated() needs the scope as well since
it does use current->fs to derive the initramfs superblock.
do_populate_rootfs() ← async_schedule_domain() ← kworker (async
workqueue)
May also run synchronously from PID 1 in case async workqueue is
considered full. Overriding in that case is fine as well.
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-17-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
The MSI Raider A18 HX A9WJG exposes two internal SteelSeries USB HID
devices for RGB lighting: KLC (1038:1122) for the keyboard and ALC
(1038:1161) for the lightbar/logo zones.
Add DMI-gated support for these devices and expose them as multicolor
LED class devices. The driver sends the same HID class SET_REPORT
control transfer as the tested userspace implementation for this
machine and writes a uniform RGB value to all known keyboard keys or
ALC zones.
The ALC payload uses sparse LED IDs on this chassis: 0x00, 0x01,
0x02 and 0x03 are physical zones, while 0x04 and 0x05 do not appear
to map to physical LEDs. Unused payload LED ID slots are initialized
to 0xff so they are ignored by the controller instead of defaulting
to LED ID 0x00.
Limit RGB support to USB interface 0 and the tested DMI system because
the KLC product ID is shared across MSI laptop designs and the key
layout mapping is model-specific. If the DMI or interface check does
not match, keep the device bound as a regular HID device instead of
failing probe.
Also make the existing Arctis 9 vendor usage-page check defensive by
returning false for report descriptors shorter than three bytes before
inspecting hdev->rdesc[0..2].
Tested on MSI Raider A18 HX A9WJG. Both internal SteelSeries ALC
(1038:1161) and KLC (1038:1122) HID devices bind on interface 0 and
create steelseries::lightbar and steelseries::kbd_backlight. Setting
multi_intensity and brightness changes the keyboard and lightbar
colors.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202606010709.X0QYNjFZ-lkp@intel.com/
Signed-off-by: David Glushkov <david.glushkov@sntiq.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
bl_open_path() resolves pNFS block device paths under /dev/disk/by-id/
via bdev_file_open_by_path() -> lookup_bdev() -> kern_path(). This
path resolution uses current->fs->root.
With kthreads now starting in nullfs, this fails when the call
originates from writeback kworker context because current->fs->root
points at the empty nullfs. The full callchain from kworker is:
wb_workfn [kworker writeback callback]
...
nfs_writepages [address_space_operations.writepages]
nfs_do_writepage
nfs_pageio_add_request
...
bl_pg_init_write [nfs_pageio_ops.pg_init]
pnfs_generic_pg_init_write
pnfs_update_layout
nfs4_proc_layoutget [synchronous RPC]
pnfs_layout_process
bl_alloc_lseg
bl_alloc_extent
bl_find_get_deviceid
bl_alloc_deviceid_node
bl_parse_deviceid
bl_parse_scsi
bl_open_path
bdev_file_open_by_path
lookup_bdev
kern_path <- current->fs->root
bl_open_path() can also be reached from userspace process context (e.g.
open, read, write syscalls via pnfs_update_layout). In that case
current->fs must not be overridden as the path should resolve against
the calling process's filesystem root.
Add a tsk_is_kthread() conditional in bl_open_path() to only apply
scoped_with_init_fs() in kthread context.
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-16-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
A driver's probe calls hid_device_io_start() to enable input delivery,
then fails at a later initialization step and unwinds via hid_hw_stop().
The unwind frees struct hidraw via hidraw_disconnect() while in-flight
HID reports may still be running on another CPU, dereferencing the
freed object through hidraw_report_event(). syzbot reports the
resulting use-after-free for the corsair-psu HID driver.
Edward Adam Davis posted a per-driver fix for corsair-psu that adds
an explicit hid_device_io_stop() before hid_hw_stop() in the probe
error path ("hwmon: prevent packets from going to driver for probe",
2026-04-28). Auditing the tree shows 15 drivers call
hid_device_io_start(); 7 also call hid_device_io_stop() and 8 do not:
drivers calling hid_device_io_start() without a matching
hid_device_io_stop() before hid_hw_stop():
drivers/hwmon/corsair-psu.c (fix posted by Edward)
drivers/hwmon/corsair-cpro.c
drivers/hwmon/nzxt-kraken3.c
drivers/hwmon/nzxt-smart2.c
drivers/hwmon/gigabyte_waterforce.c
drivers/hid/hid-logitech-dj.c
drivers/hid/hid-nintendo.c
drivers/hid/hid-mcp2221.c
Roughly half of all callers of the API are exposed. Centralize the
quiesce in hid_hw_stop() so callers do not have to remember the
matching stop: if a driver has left hdev->io_started true on entry,
call hid_device_io_stop() before hid_disconnect().
For the 7 drivers that already call hid_device_io_stop() correctly,
hdev->io_started is false on entry, the guard short-circuits, and
behavior is unchanged.
No Fixes: tag because the affected drivers gained their
hid_device_io_start() calls independently over years; the bug is a
class-wide API misuse rather than a regression from one commit.
Reported-by: syzbot+9eebf5f6544c5e873858@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9eebf5f6544c5e873858
Signed-off-by: Philipp Weber <kernel@phwe.de>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
In picolcd_send_and_wait(), an integer overflow of the signed loop counter
'k' can theoretically lead to a NULL pointer dereference of 'raw_data'.
If the loop executes more than INT_MAX times, 'k' becomes negative,
making the condition 'k < size' true even when 'size' is 0.
Change the type of 'k' to 'unsigned int' to prevent the overflow and
eliminate the out-of-bounds access.
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
[jkosina@suse.com: extended hash length]
Fixes: fabdbf2fd2 ("HID: picoLCD: split driver code")
Signed-off-by: Georgiy Osokin <g.osokin@auroraos.dev>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
appleir_remove() runs hid_hw_stop() before timer_delete_sync().
hid_hw_stop() synchronously unregisters the HID input device via
hid_disconnect() -> hidinput_disconnect() -> input_unregister_device(),
which drops the last reference and frees the underlying input_dev when
no userspace handle holds it open.
key_up_tick() reads appleir->input_dev and calls input_report_key() /
input_sync() on it. The timer is armed from appleir_raw_event() with
a HZ/8 (~125 ms) timeout on every keydown and key-repeat report. If a
key was pressed shortly before the device is disconnected, the timer
can fire after hid_hw_stop() has freed input_dev but before the
teardown drains it.
A simple reorder is not sufficient. Putting the timer drain first
still leaves a window where a USB URB completion (raw_event) running
during hid_hw_stop() can call mod_timer() and re-arm the timer, which
then fires after hidinput_disconnect() has freed input_dev. The same
URB-completion window also lets raw_event() reach key_up(), key_down()
and battery_flat() directly, all of which dereference
appleir->input_dev.
Introduce a 'removing' flag on struct appleir, gated by the existing
spinlock. appleir_remove() sets the flag under the lock and then
shuts down the timer with timer_shutdown_sync(), which both drains any
in-flight callback and permanently disables further mod_timer() calls.
appleir_raw_event() and key_up_tick() bail out early if the flag is
set, so no path can arm or run the timer, or dereference
appleir->input_dev, after remove() has started tearing down.
The keyrepeat and flatbattery branches of appleir_raw_event()
previously called into the input layer without holding the spinlock;
take it now so the flag check is well-defined. This incidentally
closes a pre-existing read-side race on appleir->current_key in the
keyrepeat branch.
This bug is structurally a sibling of commit 4db2af9292 ("HID:
appletb-kbd: fix UAF in inactivity-timer cleanup path") and has been
present since the driver was introduced.
Fixes: 9a4a5574ce ("HID: appleir: add support for Apple ir devices")
Cc: stable@vger.kernel.org
Signed-off-by: Manish Khadka <maskmemanish@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Use scoped_with_init_fs() to temporarily override current->fs for
the kern_path() call in smb2_get_info_filesystem() so the share
path lookup happens in init's filesystem context.
All ksmbd paths ← SMB command handlers ← handle_ksmbd_work() ← workqueue
← ksmbd_conn_handler_loop() ← kthread
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-14-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Use scoped_with_init_fs() to temporarily override current->fs for
the kern_path() call in share_config_request() so the share path
lookup happens in init's filesystem context.
All ksmbd paths ← SMB command handlers ← handle_ksmbd_work() ← workqueue
← ksmbd_conn_handler_loop() ← kthread
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-13-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Replace the manual init_task root retrieval with scoped_with_init_fs()
to temporarily override current->fs. This allows using the simpler
filp_open() instead of the init_root() + file_open_root() pattern.
kernel_read_file_from_path_initns() ← fw_get_filesystem_firmware() ←
_request_firmware() ← request_firmware_work_func() ← kworker (async
firmware loading)
Also called synchronously from request_firmware() which can be user or
kthread context.
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-12-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Use scoped_with_init_fs() to temporarily override current->fs for
the filp_open() call so the coredump path lookup happens in init's
filesystem context. This replaces the init_root() + file_open_root()
pattern with the simpler scoped override.
coredump_file() ← do_coredump() ← vfs_coredump() ← get_signal() — runs
as the crashing userspace process
Uses init's root to prevent a chrooted/user-namespaced process from
controlling where suid coredumps land. Not a kthread, but intentionally
needs init's fs for security.
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-11-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
update_dev_time() can be called from both kthread and process context.
Use scoped_with_init_fs() to temporarily override current->fs for
the kern_path() call when running in kthread context so the path
lookup happens in init's filesystem context.
update_dev_time() ← btrfs_scratch_superblocks() ←
btrfs_dev_replace_finishing() ← btrfs_dev_replace_kthread()
← kthread (kthread_run)
Also called from ioctl (user process).
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-10-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Use scoped_with_init_fs() to temporarily override current->fs for
the filp_open() call in __core_scsi3_write_aptpl_to_file() so the
path lookup happens in init's filesystem context.
__core_scsi3_write_aptpl_to_file() ← core_scsi3_update_and_write_aptpl()
← PR command handlers ← target_queued_submit_work() ← kworker
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-9-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
core_alua_write_tpg_metadata() can be called from both kthread and user
process context. Use scoped_with_init_fs() to temporarily override
current->fs for the filp_open() call when running in kthread context so
the path lookup happens in init's filesystem context.
core_alua_write_tpg_metadata() ← core_alua_update_tpg_primary_metadata()
← core_alua_do_transition_tg_pt() ← target_queued_submit_work() ←
kworker (target submission workqueue)
Also reached synchronously from configfs (user process) via the
alua_access_state and alua_tg_pt_offline attributes:
core_alua_write_tpg_metadata() ← core_alua_update_tpg_primary_metadata()
← core_alua_do_transition_tg_pt() ← core_alua_do_port_transition() ←
target_tg_pt_gp_alua_access_state_store()
In that case current->fs must not be overridden as the path should
resolve against the calling process's filesystem root.
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-8-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Replace the manual init_task root retrieval with scoped_with_init_fs()
to temporarily override current->fs. This allows using the simpler
filp_open() instead of the init_root() + file_open_root() pattern.
open_file_as_root() ← sev_read_init_ex_file() / sev_write_init_ex_file()
← sev_platform_init() ← __sev_guest_init() ← KVM ioctl — user process context
Needs init's root because the SEV init_ex file path should resolve
against the real root, not a KVM user's chroot.
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-7-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Use scoped_with_init_fs() to temporarily override current->fs for
the bdev_file_open_by_path() call so the path lookup happens in
init's filesystem context.
process_msg_open() ← rnbd_srv_rdma_ev() ← RDMA completion callback ←
ib_cq_poll_work() ← kworker (InfiniBand completion workqueue)
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-6-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Change userspace_init_fs from a declared-but-unused extern struct to
a dynamically initialized pointer. Add init_userspace_fs() which is
called early in kernel_init() (PID 1) to record PID 1's fs_struct
as the canonical userspace filesystem state.
Wire up __override_init_fs() and __revert_init_fs() to actually swap
current->fs to/from userspace_init_fs. Previously these were no-ops
that stored current->fs back to itself.
Fix nullfs_userspace_init() to compare against userspace_init_fs
instead of &init_fs. When PID 1 unshares its filesystem state, revert
userspace_init_fs to init_fs's root (nullfs) so that stale filesystem
state is not silently inherited by kworkers and usermodehelpers.
At this stage PID 1's fs still points to rootfs (set by
init_mount_tree), so userspace_init_fs points to rootfs and
scoped_with_init_fs() is functionally equivalent to its previous no-op
behavior.
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-5-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Add a real_fs field to task_struct that always mirrors the fs field.
This lays the groundwork for distinguishing between a task's permanent
fs_struct and one that is temporarily overridden via scoped_with_init_fs().
When a kthread temporarily overrides current->fs for path lookup, we
need to know the original fs_struct for operations like exit_fs() and
unshare_fs_struct() that must operate on the real, permanent fs.
For now real_fs is always equal to fs. It is maintained alongside fs in
all the relevant paths: exit_fs(), unshare_fs_struct(),
switch_fs_struct(), and copy_fs().
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-4-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
letsketch_driver does not provide a .remove callback, but
letsketch_probe() arms a per-device timer:
timer_setup(&data->inrange_timer, letsketch_inrange_timeout, 0);
The timer is re-armed from letsketch_raw_event() with a 100 ms
timeout on every pen-in-range report, and its callback dereferences
data->input_tablet to deliver a synthetic BTN_TOOL_PEN release.
letsketch_data is allocated with devm_kzalloc(), and its input_dev
fields are devm-allocated via letsketch_setup_input_tablet(). On
device unbind (USB unplug or rmmod), the HID core runs its default
teardown and devm cleanup frees both letsketch_data and the input
devices. Because no .remove callback exists, nothing drains the
timer first: if raw_event armed it within ~100 ms of the unbind,
the pending timer fires on freed memory. This is a UAF read of
data and of data->input_tablet, followed by input_report_key() /
input_sync() into the freed input_dev.
The same problem can occur on the probe error path: if
hid_hw_start() enabled I/O on an always-poll-quirk device and then
failed, raw_event may have armed the timer before devm releases
data.
Fix by adding a .remove callback that calls hid_hw_stop() first.
hid_hw_stop() synchronously kills the URBs that deliver raw_event(),
so once it returns no path can re-arm the timer. timer_shutdown_sync()
then drains any in-flight callback and permanently disables further
mod_timer() calls. Apply the same timer_shutdown_sync() in the probe
error path so the timer is guaranteed not to outlive data.
Fixes: 33a5c27934 ("HID: Add new Letsketch tablet driver")
Cc: stable@vger.kernel.org
Signed-off-by: Manish Khadka <maskmemanish@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Similar to scoped_with_kernel_creds() allow a temporary override of
current->fs to serve the few places where lookup is performed from
kthread context or needs init's filesytem state.
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-3-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
PID 1 may choose to stop sharing fs_struct state with us. Either via
unshare(CLONE_FS) or unshare(CLONE_NEWNS). Of course, PID 1 could have
chosen to create arbitrary process trees that all share fs_struct state
via CLONE_FS. This is a strong statement: We only care about PID 1 aka
the thread-group leader so subthread's fs_struct state doesn't matter.
PID 1 unsharing fs_struct state is a bug. PID 1 relies on various
kthreads to be able to perform work based on its fs_struct state.
Breaking that contract sucks for both sides. So just don't bother with
extra work for this. No sane init system should ever do this.
Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-2-77ee053060e0@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
The HDCP 2.2 specification requires the seq_num_v to be monotonically
increasing, and repeated seq_num_v needs to be treated as an integrity
failure. Make it so.
For the first message, seq_num_v must be zero, and is already
checked. We can only check for less-than-or-equal for the subsequent
messages, where hdcp2_encrypted is true.
Discovered using AI-assisted static analysis confirmed by Intel Product
Security.
Reported-by: Martin Hodo <martin.hodo@intel.com>
Fixes: d849178e2c ("drm/i915: Implement HDCP2.2 repeater authentication")
Cc: stable@vger.kernel.org # v5.2+
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260625104407.1025614-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Since commit 9c10525510 ("pinctrl: pinconf-generic: perform basic
checks on pincfg properties"), the generic pinconf parser logs an error
when a pin configuration node specifies more than one bias mode.
Several ZynqMP boards described SDIO card-detect and write-protect pins
with both bias-high-impedance and bias-pull-up, which triggers at
pinctrl probe:
generic pinconfig core: /firmware/zynqmp-firmware/pinctrl/.../conf-cd:
cannot have multiple bias configurations
On ZynqMP, bias-high-impedance enables tri-state while bias-pull-up
enables the internal pull resistor; these are mutually exclusive bias
settings and only pull-up is needed for CD/WP inputs. Drop the redundant
bias-high-impedance property and keep bias-pull-up.
Reported-by: Mikko Rapeli (Linaro) <mikko.rapeli@linaro.org>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221586
Link: https://patch.msgid.link/e01c8e60e1d9ed68c347f1a3741f89149109d8b7.1780496388.git.michal.simek@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
Christian Brauner <brauner@kernel.org> says:
ovl: support idmapped overlay mounts
I've been asked about this feature multiple times and had actually
implemented it right when I did the initial idmapped layer support.
So here's a new version of this series.
This series lets the merged overlayfs mount itself be idmapped via
mount_setattr(MOUNT_ATTR_IDMAP), in addition to the already supported
idmapped lower and upper layers. It allows the same overlay tree to
be exposed under a different ownership view, e.g. a container seeing
the merged tree as 0:0 regardless of the on-disk or per-layer ids.
Overlayfs already normalizes every underlying id through the relevant
layer idmap when it copies attributes into the overlay inode
(ovl_copyattr()), so the overlay inode's i_{u,g}id are "overlay-final"
ids. The overlay mount idmap O composes on top of that pivot:
caller view <--O--> overlay-final id <--layer idmap--> on-disk
O is applied at the overlay-inode boundary only - permission, getattr,
setattr, the ACL owner checks and inode_init_owner() - while the
underlying layers keep being accessed with the mounter's credentials
through their own, possibly idmapped, mounts. The mount idmap thus
only changes how the caller sees the overlay inode and never widens
the mounter's access to the layers: the second, mounter-credential
check in ovl_permission() against the real inode stays on the layer
idmap.
Most paths need no change because the VFS applies O to the overlay
inode before overlayfs runs (sticky/rename/unlink/create gating) or
after it returns at the syscall boundary (the POSIX ACL get/set
translation). Overlayfs only acts where it bypasses the generic path:
getattr (it stats the real path), the setattr forward to the upper
(the requested id is rebased from O into overlay-final space before
being handed down), inode_init_owner() on create/tmpfile, and its own
owner checks in ovl_set_acl().
FS_ALLOW_IDMAP is set last, once every operation honors O, so there is
no bisection point where the mount is idmappable but an operation
still ignores the idmapping.
Note that fstests will be broken by this temporarily as they rely on the
ability to create whiteouts for unprivileged device node creation. That
can be adjusted.
* patches from https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-0-7381632aa402@kernel.org:
ovl: document security.capability idmapping on the xattr forward paths
selftests/filesystems/overlayfs: test idmapped overlay mounts
selftests/filesystems/overlayfs: fix set_layers_via_fds link error
docs: document idmapped overlay mounts
ovl: allow idmapping overlay mounts
ovl: handle idmapped mounts in ovl_set_acl()
ovl: handle idmapped mounts in ovl_getattr()
ovl: handle idmapped mounts in ovl_setattr()
ovl: handle idmapped mounts in ovl_permission()
ovl: handle idmapped mounts in ovl_create_object() and ovl_tmpfile()
Link: https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-0-7381632aa402@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Now that an overlay mount can itself be idmapped, every id exposed at
the overlay-inode boundary is mapped through the overlay mount idmap.
security.capability is the one id-bearing xattr that overlayfs does not
translate in its own boundary code: the embedded rootid of a v3 fscap
is instead mapped by the capability LSM inside vfs_getxattr() and
vfs_setxattr().
It still composes correctly only because the xattr read and write
forwards go through the security-aware vfs_getxattr() / vfs_setxattr()
rather than the raw __vfs_*xattr() variants: commoncap maps the rootid
through the layer idmap at the overlay-to-real forward, while the
overlay mount idmap is applied by the outer vfs_getxattr() at the
syscall boundary, mirroring the layer-then-mount composition used by
ovl_getattr().
The raw __vfs_*xattr() variants skip the security hooks and would
silently drop the rootid mapping. Comment both forwards - the read in
ovl_xattr_get() and the write in ovl_do_setxattr() - so they are not
converted to them by accident.
No functional change.
Link: https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-10-7381632aa402@kernel.org
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Add a selftest for idmapping the merged overlay mount itself. It
applies an idmapping to a freshly created (still detached) overlay
mount with mount_setattr(MOUNT_ATTR_IDMAP) and checks that:
- getattr reports ownership mapped through the mount idmap;
- a file created through the idmapped mount is stored on the upper
layer with the corresponding overlay-final id;
- chown through the idmapped mount round-trips;
- an nfs_export overlay can be idmapped and decodable file handles
round-trip through it with correctly mapped ownership.
The layers live on a private tmpfs and are owned by the host id so that
they map to id 0 through the test idmapping, allowing the root caller
to operate on them.
Link: https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-9-7381632aa402@kernel.org
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
set_layers_via_fds.c calls open_tree() directly, but that wrapper is
not provided by all C libraries, so the test fails to link with
"undefined reference to open_tree" on toolchains without it.
Use sys_open_tree() from ../wrappers.h, the syscall wrapper already
used for move_mount(), fsmount() and friends here. This is also a
prerequisite for building the new idmapped_mounts test added to this
directory.
Link: https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-8-7381632aa402@kernel.org
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Describe that the merged overlay mount itself can be turned into an
idmapped mount with mount_setattr(2), how the overlay mount idmapping
composes with any layer idmappings, and that the mounter's access to
the underlying layers is unaffected.
Link: https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-7-7381632aa402@kernel.org
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Now that every overlay inode operation honors the overlay mount idmap,
allow the merged overlay mount itself to be idmapped by setting
FS_ALLOW_IDMAP on ovl_fs_type. mount_setattr(MOUNT_ATTR_IDMAP) can
then apply an idmapping to an overlay mount, exposing the merged tree
under a different ownership view.
The composition is clean because overlayfs already normalizes every
underlying id through the relevant layer idmap when it copies
attributes into the overlay inode (ovl_copyattr()); the overlay inode's
i_{u,g}id are thus "overlay-final" ids. The overlay mount idmap
composes on top of that pivot: it is applied to (getattr) and removed
from (setattr, create) those ids at the overlay-inode boundary -
permission, getattr, setattr, ACL owner checks and inode_init_owner() -
while the underlying layers keep being accessed with the mounter's
credentials through their own, possibly idmapped, mounts. The mount
idmap therefore only changes how the caller sees the overlay inode and
never widens the mounter's access to the layers.
This is deliberately the final code patch of the series: only once
every operation honors the mount idmap is it safe to make overlay
mounts idmappable.
Link: https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-6-7381632aa402@kernel.org
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
The two checks ovl_set_acl() performs on the overlay inode itself -
inode_owner_or_capable() and the setgid-stripping test - were done with
&nop_mnt_idmap. On an idmapped overlay mount this compares the overlay
inode's id space directly against the caller's: it denies the rightful
owner (as seen through the mount idmap) the right to set an ACL, and
evaluates the setgid-drop decision in the wrong id space, which can
mis-set the mode on the upper inode.
Use the struct mnt_idmap passed in by the VFS for both. Fold the
open-coded "caller not in group and not CAP_FSETID privileged" test
into in_group_or_capable() with i_gid_into_vfsgid(), the same
idmap-aware helpers used by setattr_should_drop_sgid().
The subsequent internal forced setgid-kill via ovl_setattr() stays on
&nop_mnt_idmap: it carries only ATTR_KILL_SGID with no uid/gid to
translate and is overlayfs' own mode change, not a user-driven
operation through the mount.
No functional change until FS_ALLOW_IDMAP is set on ovl_fs_type.
Link: https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-5-7381632aa402@kernel.org
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
ovl_getattr() fetches attributes from the real (upper or lower) path
via vfs_getattr(), so the returned stat->uid/stat->gid are already
mapped through the real layer idmap but not through the overlay mount
idmap. Unlike the generic path, the VFS does not re-apply the
accessing mount's idmap after ->getattr returns - generic_fillattr()
does it, but overlayfs bypasses it - so overlayfs has to do it itself.
Map stat->uid/stat->gid through the overlay mount idmap before
returning, mirroring generic_fillattr(). The owner reported through an
idmapped overlay mount is thus the overlay-final id translated by the
mount idmap.
No functional change until FS_ALLOW_IDMAP is set on ovl_fs_type; until
then make_vfsuid()/make_vfsgid() are the identity for &nop_mnt_idmap.
Link: https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-4-7381632aa402@kernel.org
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Pass the mount's struct mnt_idmap to setattr_prepare() so that the
permission checks for a chown/chmod performed through an idmapped
overlay mount are evaluated in the mount's id space.
The ownership requested in @attr is expressed relative to the overlay
mount idmap. Before forwarding the change to the upper layer via
ovl_do_notify_change() - whose notify_change() applies the upper layer
idmap in turn - rebase ia_vfsuid/ia_vfsgid into the overlay's own id
space, i.e. the same space as the overlay inode's i_{u,g}id established
by ovl_copyattr(). Without this rebase the upper layer would interpret
the caller's mount-relative id as an upper-relative one and store the
wrong owner on disk, or reject it with -EOVERFLOW.
from_vfsuid() returns INVALID_UID for an id that the overlay mount
idmap does not map; that invalid id is carried faithfully into the
forwarded iattr and rejected by the upper notify_change() via
vfsuid_has_fsmapping(), so no bogus owner can be written.
No functional change until FS_ALLOW_IDMAP is set on ovl_fs_type; until
then the overlay mount idmap is &nop_mnt_idmap and from_vfsuid() is the
identity.
Link: https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-3-7381632aa402@kernel.org
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
When the overlay mount is idmapped, the permission check on the overlay
inode must account for the mount's idmapping. Use the struct mnt_idmap
passed in by the VFS instead of the hardcoded &nop_mnt_idmap when
checking the overlay inode against the caller's credentials.
The second check, which verifies that the mounter may access the
underlying real inode, continues to use the real layer's idmap
mnt_idmap(realpath.mnt) under the mounter's credentials and is
deliberately left unchanged. The overlay mount idmap only affects how
the caller views the overlay inode, not the mounter's access to the
layers, so it cannot widen access to the real files.
No functional change until FS_ALLOW_IDMAP is set on ovl_fs_type; until
then the overlay mount idmap is always &nop_mnt_idmap.
Link: https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-2-7381632aa402@kernel.org
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
In preparation for allowing the overlay mount itself to be idmapped,
thread the mount's struct mnt_idmap into the inode creation path and
use it for inode_init_owner() instead of the hardcoded &nop_mnt_idmap.
The preallocated overlay inode's i_{u,g}id are copied into the override
credentials by ovl_override_creator_creds() to create the real upper
inode, so honoring the overlay mount idmap here makes newly created
files, directories, special files, symlinks and tmpfiles get the
caller's mapped fs{u,g}id once overlay mounts can be idmapped.
No functional change: until FS_ALLOW_IDMAP is set on ovl_fs_type the
overlay mount idmap is always &nop_mnt_idmap, so inode_init_owner()
behaves exactly as before.
Link: https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-1-7381632aa402@kernel.org
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Christian Brauner <brauner@kernel.org> says:
fs: support freeze/thaw/mark_dead/sync with shared devices
This is a generalization of the device number to superblock so it works
for actual block device and anonymous (or even mtd) devices.
fs_holder_ops recovers the affected superblock from bdev->bd_holder. That
forces the holder of a block device to be exactly one superblock and makes
it impossible for several superblocks to share a single device.
erofs does exactly that. It can mount read-only "blob" devices that are
shared between many superblocks: a metadata-only erofs that indexes a set
of per-layer blobs (one filesystem instead of one per OCI layer), or an
incremental image whose base device is shared by several updates. Because
the block layer only tracks a single holder, a freeze, thaw, removal or
sync on such a device is never propagated to all the superblocks using it,
and the current infrastructure has no way to find them.
This series replaces the bd_holder-based lookup with a global, dev_t-keyed
table mapping each block device to the superblock(s) using it. The holder
argument becomes purely the block layer's exclusivity token -- a superblock,
or the file_system_type for a device shared within one filesystem type --
and the fs_holder_ops callbacks look the device up in the table and act on
every superblock registered for it: 1:1 for most filesystems, 1:many for
erofs.
Filesystems claim and release their devices through new
fs_bdev_file_open_by_{dev,path}() and fs_bdev_file_release() helpers; the
per-fs patches convert xfs, btrfs, ext4, f2fs and erofs over to them and
fix cramfs and romfs, which released the registered main device with a
raw bdev_fput().
Since every superblock is registered under its s_dev the table also
replaces the last s_dev-keyed walk of the super_blocks list:
user_get_super() resolves device numbers through it, so ustat() and
quotactl() now work on any device a filesystem claims and no longer
take sb_lock.
The longer-term motivation is to let userspace decide which devices may be
onlined from one central place, without having to teach every filesystem
about it individually.
* patches from https://patch.msgid.link/20260616-work-super-bdev_holder_global-v2-0-7df6b864028e@kernel.org:
selftests/filesystems: add ustat() coverage
fs: look up the superblock via the device table in user_get_super()
super: make fs_holder_ops private
f2fs: open via dedicated fs bdev helpers
erofs: open via dedicated fs bdev helpers
fs: tolerate per-superblock freeze errors on shared devices
fs: look up superblocks via the device table in fs_holder_ops
ext4: open via dedicated fs bdev helpers
btrfs: open via dedicated fs bdev helpers
xfs: port to fs_bdev_file_open_by_path()
fs: add dedicated block device open helpers for filesystems
fs: maintain a global device-to-superblock table
ocfs2: don't reset s_dev on dismount
ext4: use anonymous devices for KUnit test superblocks
fs, block: move blk_mode_t and fop_flags_t into <linux/types.h>
super: take lock after last reference count
super: convert s_count to refcount_t s_passive
Link: https://patch.msgid.link/20260616-work-super-bdev_holder_global-v2-0-7df6b864028e@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
user_get_super() is now backed by the global device-to-superblock table
instead of a walk of the super_blocks list. ustat(2) is its most direct
user-visible consumer but nothing in the tree exercises it.
Add a small regression test: the device number of a mounted tmpfs (an
anonymous device, registered in the table by sget_fc()) must resolve,
it must stop resolving after the unmount (the entry is dropped again in
kill_super_notify()), and bogus device numbers keep reporting EINVAL.
The test passes on kernels before the conversion: it pins down the
semantics the table-backed lookup must preserve.
Link: https://patch.msgid.link/20260616-work-super-bdev_holder_global-v2-18-7df6b864028e@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
user_get_super() still finds the superblock for a device number by
walking the global super_blocks list under sb_lock. Every superblock is
registered in the device table under its s_dev since sget_fc() inserts
it there, including superblocks on anonymous devices, so use the table
instead.
The refcount-pinning cursor helpers super_dev_{get,first,next}() only
touch table state and do not depend on CONFIG_BLOCK, so drop the
CONFIG_BLOCK guard around them: their new caller serves anonymous
devices as well (ustat() on e.g. tmpfs) and is built without
CONFIG_BLOCK. The guard falls in this patch rather than separately
since without this caller the helpers would be unused without
CONFIG_BLOCK.
The pinned entry holds a passive reference on the superblock so
super_lock() can be called directly; once the superblock is locked grab
a passive reference for the caller before dropping the pin.
The device table contains more than the old walk could find: a
superblock is also registered for every additional device it claims
(the xfs log and realtime devices, btrfs member devices, the ext4
external journal, erofs blob devices). Don't filter those out:
specifying any device a filesystem uses now resolves to that
filesystem, so ustat() and quotactl() work on e.g. the xfs log device
or a btrfs member device (the latter used to fail outright as btrfs
superblocks carry an anonymous s_dev that never matches a member
device). When several superblocks share a device (erofs blob devices)
the first live superblock wins.
The cursor also keeps scanning past dying superblocks where the old
walk gave up after the first s_dev match, so a mount racing with the
unmount of the same device (or with the reuse of a recycled anonymous
dev_t) finds the live superblock where the old walk could spuriously
return NULL.
This removes the last s_dev-keyed walk of the super_blocks list and
takes ustat() and quotactl()'s block device lookup off sb_lock
entirely.
Link: https://patch.msgid.link/20260616-work-super-bdev_holder_global-v2-17-7df6b864028e@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
