* WARNING: at floppy_interrupt, CPU: swapper/NUM/NUM
From: sanan.hasanou @ 2026-06-18 22:26 UTC (permalink / raw)
To: efremov, axboe, linux-block, linux-kernel; +Cc: syzkaller, contact
Good day, dear maintainers,
We found a bug using a modified version of syzkaller.
Kernel Branch: 7.0-rc1
Kernel Config: <https://drive.google.com/open?id=173DLEAEPKPhhR1TcqofdnkLpdoK7PMFl>
Unfortunately, we don't have any reproducer for this bug yet.
Thank you!
Best regards,
Sanan Hasanov
------------[ cut here ]------------
WARNING: at schedule_bh drivers/block/floppy.c:1000 [inline], CPU#0: swapper/0/1
WARNING: at floppy_interrupt+0x51b/0x560 drivers/block/floppy.c:1766, CPU#0: swapper/0/1
Modules linked in:
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc1 #1 PREEMPT(full)
Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:schedule_bh drivers/block/floppy.c:1000 [inline]
RIP: 0010:floppy_interrupt+0x51b/0x560 drivers/block/floppy.c:1766
Code: 35 3a c8 54 0c 48 c7 c7 80 fa 4b 8c 48 c7 c2 c0 f7 4b 8c 48 c7 c1 40 f9 4b 8c e8 a0 4a 3b fb e9 af fe ff ff e8 66 d9 d5 fb 90 <0f> 0b 90 e9 e8 fc ff ff 44 89 f9 80 e1 07 38 c1 0f 8c 27 fc ff ff
RSP: 0018:ffffc90000007af8 EFLAGS: 00010006
RAX: ffffffff85ec786a RBX: ffffffff85ecf380 RCX: ffff888016aeba80
RDX: 0000000000010100 RSI: 0000000000000001 RDI: 0000000000000000
RBP: 0000000000000000 R08: ffffffff8f3e2467 R09: 1ffffffff1e7c48c
R10: dffffc0000000000 R11: fffffbfff1e7c48d R12: dffffc0000000000
R13: 0000000000000000 R14: 0000000002000011 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8880d98df000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff888012801000 CR3: 000000000e6ff000 CR4: 00000000000006f0
Call Trace:
<IRQ>
__handle_irq_event_percpu+0x1d9/0x5d0 kernel/irq/handle.c:209
handle_irq_event_percpu kernel/irq/handle.c:246 [inline]
handle_irq_event+0x90/0x1e0 kernel/irq/handle.c:263
handle_edge_irq+0x239/0x9e0 kernel/irq/chip.c:855
generic_handle_irq_desc include/linux/irqdesc.h:186 [inline]
handle_irq arch/x86/kernel/irq.c:262 [inline]
call_irq_handler arch/x86/kernel/irq.c:286 [inline]
__common_interrupt+0xc5/0x170 arch/x86/kernel/irq.c:333
common_interrupt+0x4a/0xc0 arch/x86/kernel/irq.c:326
asm_common_interrupt+0x26/0x40 arch/x86/include/asm/idtentry.h:688
RIP: 0010:__raw_spin_unlock_irq include/linux/spinlock_api_smp.h:188 [inline]
RIP: 0010:_raw_spin_unlock_irq+0x19/0x30 kernel/locking/spinlock.c:202
Code: 00 02 00 00 75 db eb da e8 74 c0 a8 f5 5b c3 66 90 f3 0f 1e fa 0f 1f 44 00 00 e8 f2 b4 12 f6 e8 4d 86 41 f6 fb bf 01 00 00 00 <e8> d2 2a 07 f6 65 8b 05 8b 59 88 06 85 c0 74 01 c3 e8 41 c0 a8 f5
RSP: 0018:ffffc90000007d58 EFLAGS: 00000246
RAX: 0000000000000001 RBX: ffffffff85358ab0 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001
RBP: ffffc90000007ef8 R08: ffff88806ba2f683 R09: 1ffff1100d745ed0
R10: dffffc0000000000 R11: ffffed100d745ed1 R12: ffff88801d085478
R13: dffffc0000000000 R14: ffff88806ba2f680 R15: ffff88806ba2f698
expire_timers kernel/time/timer.c:1798 [inline]
__run_timers kernel/time/timer.c:2373 [inline]
__run_timer_base+0x700/0xa30 kernel/time/timer.c:2385
run_timer_base kernel/time/timer.c:2394 [inline]
run_timer_softirq+0xbc/0x190 kernel/time/timer.c:2404
handle_softirqs+0x1ed/0x700 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0x8e/0x270 kernel/softirq.c:723
irq_exit_rcu+0xe/0x30 kernel/softirq.c:739
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1056 [inline]
sysvec_apic_timer_interrupt+0x92/0xb0 arch/x86/kernel/apic/apic.c:1056
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0010:clear_pages arch/x86/include/asm/page_64.h:103 [inline]
RIP: 0010:clear_page arch/x86/include/asm/page_64.h:114 [inline]
RIP: 0010:clear_highpage_kasan_tagged include/linux/highmem.h:344 [inline]
RIP: 0010:kernel_init_pages mm/page_alloc.c:1265 [inline]
RIP: 0010:post_alloc_hook+0x3ff/0x480 mm/page_alloc.c:1887
Code: 03 49 c7 c7 20 2e 43 8e 49 c1 ef 03 eb 2f 48 8b 3d c6 74 21 0c 49 c1 e5 06 4c 29 ef 4c 01 e7 b9 00 10 00 00 31 c0 48 c1 e9 03 <f3> 48 ab 49 81 c4 00 10 00 00 49 ff ce 0f 84 31 fd ff ff 48 b8 00
RSP: 0018:ffffc9000001eed8 EFLAGS: 00000216
RAX: 0000000000000000 RBX: 1ffffffff1c865c6 RCX: 0000000000000200
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88801dc20000
RBP: 0000000000000003 R08: ffffffff9049fd6f R09: 0000000000000000
R10: ffffed1003b84000 R11: fffffbfff2093fae R12: fffa80001dc20000
R13: fffa800000000000 R14: 0000000000000008 R15: 1ffffffff1c865c4
prep_new_page mm/page_alloc.c:1897 [inline]
get_page_from_freelist+0x2240/0x2330 mm/page_alloc.c:3962
__alloc_frozen_pages_noprof+0x20e/0x3d0 mm/page_alloc.c:5250
__alloc_pages_noprof+0xf/0x30 mm/page_alloc.c:5284
vm_area_alloc_pages mm/vmalloc.c:-1 [inline]
__vmalloc_area_node mm/vmalloc.c:3876 [inline]
__vmalloc_node_range_noprof+0x79f/0x1580 mm/vmalloc.c:4064
__vmalloc_node_noprof mm/vmalloc.c:4124 [inline]
vzalloc_noprof+0xdf/0x120 mm/vmalloc.c:4202
allocate_partitions block/partitions/core.c:101 [inline]
check_partition block/partitions/core.c:123 [inline]
blk_add_partitions block/partitions/core.c:590 [inline]
bdev_disk_changed+0x628/0x1810 block/partitions/core.c:694
blkdev_get_whole+0x37e/0x500 block/bdev.c:764
bdev_open+0x35b/0xdc0 block/bdev.c:973
bdev_file_open_by_dev+0x1c3/0x240 block/bdev.c:1075
disk_scan_partitions+0x1be/0x2c0 block/genhd.c:387
add_disk_final block/genhd.c:416 [inline]
add_disk_fwnode+0x31e/0x470 block/genhd.c:610
add_disk include/linux/blkdev.h:785 [inline]
brd_alloc+0x5de/0x810 drivers/block/brd.c:340
brd_init+0xc6/0x120 drivers/block/brd.c:420
do_one_initcall+0x1a1/0x530 init/main.c:1382
do_initcall_level+0x117/0x1a0 init/main.c:1444
do_initcalls+0xe1/0x150 init/main.c:1460
kernel_init_freeable+0x207/0x310 init/main.c:1692
kernel_init+0x22/0x1d0 init/main.c:1582
ret_from_fork+0x608/0xc40 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:245
</TASK>
----------------
Code disassembly (best guess):
0: 00 02 add %al,(%rdx)
2: 00 00 add %al,(%rax)
4: 75 db jne 0xffffffe1
6: eb da jmp 0xffffffe2
8: e8 74 c0 a8 f5 call 0xf5a8c081
d: 5b pop %rbx
e: c3 ret
f: 66 90 xchg %ax,%ax
11: f3 0f 1e fa endbr64
15: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
1a: e8 f2 b4 12 f6 call 0xf612b511
1f: e8 4d 86 41 f6 call 0xf6418671
24: fb sti
25: bf 01 00 00 00 mov $0x1,%edi
* 2a: e8 d2 2a 07 f6 call 0xf6072b01 <-- trapping instruction
2f: 65 8b 05 8b 59 88 06 mov %gs:0x688598b(%rip),%eax # 0x68859c1
36: 85 c0 test %eax,%eax
38: 74 01 je 0x3b
3a: c3 ret
3b: e8 41 c0 a8 f5 call 0xf5a8c081
<<<<<<<<<<<<<<< tail report >>>>>>>>>>>>>>>
^ permalink raw reply
* Re: [PATCH] virtio-blk: use little-endian types for the zoned fields
From: Stefan Hajnoczi @ 2026-06-18 15:18 UTC (permalink / raw)
To: Michael Bommarito
Cc: Michael S . Tsirkin, Jason Wang, Stefano Garzarella,
Dmitry Fomichev, Damien Le Moal, Jens Axboe, Paolo Bonzini,
virtualization, linux-block, linux-kernel
In-Reply-To: <20260617151727.4071754-1-michael.bommarito@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2446 bytes --]
On Wed, Jun 17, 2026 at 11:17:27AM -0400, Michael Bommarito wrote:
> The zoned block-device fields in the virtio-blk header are typed
> __virtio{32,64}, so their endianness follows VIRTIO_F_VERSION_1. The
> zoned feature is only defined for VIRTIO 1.x devices, and the virtio
> specification defines all of its fields as little-endian. Commit
> b16a1756c716 ("virtio_blk: mark all zone fields LE") tagged them
> __le* for exactly this reason, but commit f1ba4e674feb ("virtio-blk:
> fix to match virtio spec") re-applied the reviewed version of the
> original zoned series -- which predated b16a1756 -- and silently
> restored the __virtio* typing together with the matching
> virtio*_to_cpu() / virtio_cread() accessors in the driver.
>
> Restore the little-endian typing for the zoned configuration-space
> characteristics, the zone descriptor, the zone report header and the
> ZONE_APPEND in-header sector, and read them with le*_to_cpu() and
> virtio_cread_le() to match.
>
> There is no functional change on any spec-compliant device: zoned
> requires VIRTIO_F_VERSION_1, and for a VERSION_1 device
> virtio*_to_cpu() is identical to le*_to_cpu(). The change makes the
> uapi types describe the actual wire format and removes a latent
> endianness mismatch for a (non-conformant) legacy device on a
> big-endian guest.
>
> Fixes: f1ba4e674feb ("virtio-blk: fix to match virtio spec")
> Suggested-by: Michael S. Tsirkin <mst@redhat.com>
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> ---
> Testing:
> - Builds with no new warnings; sparse endian-clean (C=2,
> __CHECK_ENDIAN__, CONFIG_BLK_DEV_ZONED=y) both before and after.
> - Booted under QEMU with a host-managed zoned device exposed through
> virtio-blk. Zone revalidation, blkzone report and a sequential
> write / write-pointer check return correct values; blktests zbd
> device tests 001-006 (sysfs+ioctl, report zone, reset, write split,
> write ordering, revalidate) pass, with results identical before and
> after this change -- expected, since on a VIRTIO_F_VERSION_1 device
> virtio*_to_cpu() == le*_to_cpu().
>
> drivers/block/virtio_blk.c | 38 +++++++++++++++------------------
> include/uapi/linux/virtio_blk.h | 18 ++++++++--------
> 2 files changed, 26 insertions(+), 30 deletions(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH blktests] Fix _get_page_size()
From: Jeff Moyer @ 2026-06-18 14:41 UTC (permalink / raw)
To: linux-block, shinichiro.kawasaki
There is no CONFIG_PAGE_SHIFT stored in /boot/config-`uname -r` on RHEL
systems (maybe all systems?). As a result, tests that make use of
_get_page_size() were doing the wrong thing. For example, throtl/002
used it to calculate I/O sizes for direct IO. Those sizes ended up not
being a multiple of the logical block size, and hence throtl/002 was
failing.
Fixes: 8eca9fa ("common/rc, scsi/011, zbd/010: introduce _page_size_equals() helper")
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
diff --git a/common/rc b/common/rc
index 20f7c7a..d60a125 100644
--- a/common/rc
+++ b/common/rc
@@ -562,13 +562,8 @@ _have_systemctl_unit() {
return 0
}
-# Get system page size from kernel conguration
_get_page_size() {
- local page_shift
-
- page_shift=$(_get_kernel_option PAGE_SHIFT)
-
- echo $((1<< page_shift))
+ getconf PAGE_SIZE
}
# Check if the system page size matches the required size (in bytes).
^ permalink raw reply related
* Re: [PATCH v6 1/4] block: add task-context bio completion infrastructure
From: Jan Kara @ 2026-06-18 14:26 UTC (permalink / raw)
To: Tal Zussman
Cc: Christoph Hellwig, Jan Kara, Jens Axboe, Matthew Wilcox (Oracle),
Christian Brauner, Darrick J. Wong, Carlos Maiolino,
Alexander Viro, Dave Chinner, Bart Van Assche, linux-block,
linux-kernel, linux-xfs, linux-fsdevel, linux-mm, Gao Xiang
In-Reply-To: <cuyklvhnt37xwk3jlr2iyyxxkzvt4bsf5iqv2gag4ixdicnbk2@rfqgjlclwesz>
On Mon 01-06-26 13:04:41, Jan Kara wrote:
> On Fri 29-05-26 16:46:15, Tal Zussman wrote:
> > On 5/27/26 9:00 AM, Christoph Hellwig wrote:
> > > On Wed, May 27, 2026 at 11:42:28AM +0200, Jan Kara wrote:
> > >> > I ran some experiments with fio on both XFS and a raw block device. Five
> > >> > iterations each for 60s. Results below.
> > >> >
> > >> > TLDR: Removing the delay doesn't significantly decrease user-visible
> > >> > latency or otherwise improve performance, but does significantly reduce
> > >> > throughput and increase context switches in some workloads (e.g. C).
> > >> > I think it makes sense to leave the delay as-is. Thoughts?
> > >>
> > >> Thanks for the test! One question below:
> > >
> > > Thanks from me as well!
> > >
> > >>
> > >> > Results:
> > >> >
> > >> > Workloads (all `uncached=1`):
> > >> > A: rw=write bs=128k iodepth=1 ioengine=pvsync2 # XFS
> > >> > B: rw=write bs=128k iodepth=128 ioengine=io_uring # XFS
> > >> > C: rw=randwrite bs=4k iodepth=32 ioengine=io_uring # XFS
> > >> > D: rw=rw 50/50 bs=64k iodepth=32 ioengine=io_uring # XFS
> > >> > E: rw=write bs=128k iodepth=128 ioengine=io_uring # raw /dev/nvmeXn1
> > >> > F: rw=write bs=128k iodepth=128 numjobs=4
> > >> > + vm.dirty_bytes=64MB, vm.dirty_background_bytes=32MB # XFS
> > >> >
> > >> > Mean ± stddev across 5 iterations:
> > >> >
> > >> > metric delay=1 delay=0 delta
> > >> > --------------------------------------------------------------
> > >> >
> > >> > A seq 128k qd1
> > >> > BW (MB/s) 4333 ± 27 4374 ± 34 +0.9%
> > >> > p99 (us) 36.2 ± 0.8 35.8 ± 0.4 -1.1%
> > >> > p999 (us) 3260 ± 75 3228 ± 29 -1.0%
> > >> > ctx-switches 184 k ± 59 k 3.68 M ± 65 k +1903%
> > >> > cs / io 0.09 ± 0.03 1.86 ± 0.03 +1888%
> > >> > avg bios/run 80.4 ± 0.6 1.1 ± 0.0 -98.7%
> > >>
> > >> So 1 jiffie delay is (with default HZ=1000) 1ms. That means for this load
> > >> the completion latency should be at least 1000us but your results show p99
> > >> latency of 36. What am I missing?
> > >
> > > Yes, this looks a bit odd. Unless there's multiple threads submitting
> > > and somehow the completions get batched this should complete one
> > > bio at a time and be the worst case for the delay scheme.
> >
> > Sorry, I should've clarified - the latency here is the userspace-visible
> > I/O completion latency (i.e. fio's clat value).
> >
> > I ran again and traced to get the actual time from __bio_complete_in_task()
> > to calling ->bi_end_io(). The results match the 1 jiffie delay now:
> >
> > metric delay=1 delay=0
> >
> > A seq 128k qd1
> > fio clat p99 38us 36us
> > bio cb p50 1.23ms 2.5us
> > bio cb p99 4.13ms 1.44ms
> > bio cb p999 5.01ms 2.63ms
>
> So I'm clearly missing something fundamental as I don't see how can fio
> reported IO completion time be lower than the end_io callback latency...
> Ahh, it is the strange meaning of clat in fio in combination with sync
> engine where clat means: "how long after the syscall has returned the data
> is ready". Which for sync engine is immediately so the clat number is
> meaningless. I think reporting 'lat' numbers from fio would make more
> sense but whatever.
>
> The bio cb latency indeed looks like what I'd roughly expect now. And
> notice how the median latency of IO completion is 1.23ms in delay=1 case
> and your throughput isn't abbysmal only because writes end up accumulating
> in the page cache and writeback infrastructure ends up submitting a lot of
> writeback IOs in parallel (you have ~80 bios to complete per run which
> amortizes the latency to decent level).
>
> However if you'd have IO that were to use BIO_COMPLETE_IN_TASK
> infrastructure which doesn't have so many IOs in flight (like direct IO
> with lower queue depth which has to do extent conversion on completion),
> you would very much see the latency hit on your throughput as well. In the
> extreme case of qd=1 direct IO you'd reduce the throughput to ~4MB/s.
>
> Now I'm not saying the delay is bad - it is a tradeoff with clear wins in
> CPU overhead your benchmarks are showing. I just wanted to point out
> there's also the cost side which your benchmarks don't show very clearly.
> So we might need to keep some stats showing how many IO completions we are
> offloading per second on each CPU and switch to delaying the work only once
> it crosses a threshold like 1000000/HZ per second or so (so we at most
> double the IO latency by delaying the end_io callback).
Any progress here? The patchset looks really promising so I'd love to have
it completed :)
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH v2 1/7] rust: module: add `THIS_MODULE` const to `ModuleMetadata` trait
From: Gary Guo @ 2026-06-18 14:16 UTC (permalink / raw)
To: Alvin Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block
In-Reply-To: <20260521-fix-fops-owner-v2-1-fd99079c5a04@linux.dev>
On Thu May 21, 2026 at 8:52 AM BST, Alvin Sun wrote:
> Add a `THIS_MODULE` const to the `ModuleMetadata` trait so that
> modules can provide their `ThisModule` pointer usable in const
> contexts such as static file_operations.
>
> Move the `THIS_MODULE` static from the `module!` macro into the
> `ModuleMetadata` impl, and update `__init` to use
> `LocalModule::THIS_MODULE` instead.
Perhaps you could mention that this is made possible by const_refs_to_static
which is stable since the MSRV bump.
Best,
Gary
>
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
> ---
> rust/kernel/lib.rs | 3 +++
> rust/macros/module.rs | 34 +++++++++++++++++-----------------
> 2 files changed, 20 insertions(+), 17 deletions(-)
>
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index b72b2fbe046d6..f0cf0705d9697 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -184,6 +184,9 @@ fn init(module: &'static ThisModule) -> impl pin_init::PinInit<Self, error::Erro
> pub trait ModuleMetadata {
> /// The name of the module as specified in the `module!` macro.
> const NAME: &'static crate::str::CStr;
> +
> + /// The module's `THIS_MODULE` pointer.
> + const THIS_MODULE: ThisModule;
> }
>
> /// Equivalent to `THIS_MODULE` in the C API.
> diff --git a/rust/macros/module.rs b/rust/macros/module.rs
> index 06c18e2075083..b6d7b3299fbf9 100644
> --- a/rust/macros/module.rs
> +++ b/rust/macros/module.rs
> @@ -497,28 +497,28 @@ pub(crate) fn module(info: ModuleInfo) -> Result<TokenStream> {
> /// Used by the printing macros, e.g. [`info!`].
> const __LOG_PREFIX: &[u8] = #name_cstr.to_bytes_with_nul();
>
> - // SAFETY: `__this_module` is constructed by the kernel at load time and will not be
> - // freed until the module is unloaded.
> - #[cfg(MODULE)]
> - static THIS_MODULE: ::kernel::ThisModule = unsafe {
> - extern "C" {
> - static __this_module: ::kernel::types::Opaque<::kernel::bindings::module>;
> - };
> -
> - ::kernel::ThisModule::from_ptr(__this_module.get())
> - };
> -
> - #[cfg(not(MODULE))]
> - static THIS_MODULE: ::kernel::ThisModule = unsafe {
> - ::kernel::ThisModule::from_ptr(::core::ptr::null_mut())
> - };
> -
> /// The `LocalModule` type is the type of the module created by `module!`,
> /// `module_pci_driver!`, `module_platform_driver!`, etc.
> type LocalModule = #type_;
>
> impl ::kernel::ModuleMetadata for #type_ {
> const NAME: &'static ::kernel::str::CStr = #name_cstr;
> +
> + #[cfg(MODULE)]
> + const THIS_MODULE: ::kernel::ThisModule = {
> + extern "C" {
> + static __this_module: ::kernel::types::Opaque<::kernel::bindings::module>;
> + }
> +
> + // SAFETY: `__this_module` is constructed by the kernel at load time
> + // and lives until the module is unloaded.
> + unsafe { ::kernel::ThisModule::from_ptr(__this_module.get()) }
> + };
> +
> + #[cfg(not(MODULE))]
> + const THIS_MODULE: ::kernel::ThisModule = unsafe {
> + ::kernel::ThisModule::from_ptr(::core::ptr::null_mut())
> + };
> }
>
> // Double nested modules, since then nobody can access the public items inside.
> @@ -616,7 +616,7 @@ pub extern "C" fn #ident_exit() {
> /// This function must only be called once.
> unsafe fn __init() -> ::kernel::ffi::c_int {
> let initer = <super::super::LocalModule as ::kernel::InPlaceModule>::init(
> - &super::super::THIS_MODULE
> + &<super::super::LocalModule as ::kernel::ModuleMetadata>::THIS_MODULE
> );
> // SAFETY: No data race, since `__MOD` can only be accessed by this module
> // and there only `__init` and `__exit` access it. These functions are only
^ permalink raw reply
* Re: [PATCH v2 4/7] rust: drm: set fops.owner from driver module pointer
From: Gary Guo @ 2026-06-18 14:15 UTC (permalink / raw)
To: Alvin Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block
In-Reply-To: <20260521-fix-fops-owner-v2-4-fd99079c5a04@linux.dev>
On Thu May 21, 2026 at 8:52 AM BST, Alvin Sun wrote:
> Change `create_fops()` to accept an owner module pointer instead of
> hardcoding `null_mut()`, ensuring the kernel correctly tracks the
> module owning the DRM device's file operations.
>
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
> ---
> rust/kernel/drm/device.rs | 3 ++-
> rust/kernel/drm/gem/mod.rs | 4 ++--
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/rust/kernel/drm/device.rs b/rust/kernel/drm/device.rs
> index 403fc35353c74..53e44a780ae97 100644
> --- a/rust/kernel/drm/device.rs
> +++ b/rust/kernel/drm/device.rs
> @@ -111,7 +111,8 @@ impl<T: drm::Driver> Device<T> {
> fops: &Self::GEM_FOPS,
> };
>
> - const GEM_FOPS: bindings::file_operations = drm::gem::create_fops();
> + const GEM_FOPS: bindings::file_operations =
> + drm::gem::create_fops(<T::ThisModule as crate::ModuleMetadata>::THIS_MODULE.as_ptr());
I wonder if the assoc type should just be called `Owner` or `OwnerModule`?
Best.
Gary
>
> /// Create a new `drm::Device` for a `drm::Driver`.
> pub fn new(dev: &device::Device, data: impl PinInit<T::Data, Error>) -> Result<ARef<Self>> {
> diff --git a/rust/kernel/drm/gem/mod.rs b/rust/kernel/drm/gem/mod.rs
> index 01b5bd47a3332..9a203efc59116 100644
> --- a/rust/kernel/drm/gem/mod.rs
> +++ b/rust/kernel/drm/gem/mod.rs
> @@ -357,10 +357,10 @@ impl<T: DriverObject> AllocImpl for Object<T> {
> };
> }
>
> -pub(super) const fn create_fops() -> bindings::file_operations {
> +pub(super) const fn create_fops(owner: *mut bindings::module) -> bindings::file_operations {
> let mut fops: bindings::file_operations = pin_init::zeroed();
>
> - fops.owner = core::ptr::null_mut();
> + fops.owner = owner;
> fops.open = Some(bindings::drm_open);
> fops.release = Some(bindings::drm_release);
> fops.unlocked_ioctl = Some(bindings::drm_ioctl);
^ permalink raw reply
* Re: [PATCH v2 2/7] rust: macros: auto-insert ThisModule in #[vtable]
From: Gary Guo @ 2026-06-18 14:13 UTC (permalink / raw)
To: Alvin Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block
In-Reply-To: <20260521-fix-fops-owner-v2-2-fd99079c5a04@linux.dev>
On Thu May 21, 2026 at 8:52 AM BST, Alvin Sun wrote:
> Auto-add `type ThisModule: ::kernel::ModuleMetadata;` as a required
> associated type on the trait side if not already defined, and
> auto-insert `type ThisModule = crate::LocalModule;` on the impl side
> if not explicitly provided, eliminating the need to manually declare
> and implement `ThisModule` in every vtable trait and impl.
>
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
Suggested-by: Gary Guo <gary@garyguo.net>
Link: https://lore.kernel.org/all/DIMMWHUOLPSH.13JFRHDKDQJGO@garyguo.net
> ---
> rust/macros/lib.rs | 6 ++++++
> rust/macros/vtable.rs | 38 +++++++++++++++++++++++++++++++++++++-
> 2 files changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/rust/macros/lib.rs b/rust/macros/lib.rs
> index 2cfd59e0f9e7c..d35e45ea745c0 100644
> --- a/rust/macros/lib.rs
> +++ b/rust/macros/lib.rs
> @@ -176,6 +176,12 @@ pub fn module(input: TokenStream) -> TokenStream {
> ///
> /// This macro should not be used when all functions are required.
> ///
> +/// Additionally, this macro automatically handles the `ThisModule`
> +/// associated type: on the trait side, `type ThisModule: ModuleMetadata;`
> +/// is added as a required associated type if not already defined; on the
> +/// impl side, `type ThisModule = LocalModule;` is automatically inserted
> +/// if not explicitly defined.
> +///
> /// # Examples
> ///
> /// ```
> diff --git a/rust/macros/vtable.rs b/rust/macros/vtable.rs
> index c6510b0c4ea1d..d3d0e9cbd7172 100644
> --- a/rust/macros/vtable.rs
> +++ b/rust/macros/vtable.rs
> @@ -23,6 +23,7 @@
>
> fn handle_trait(mut item: ItemTrait) -> Result<ItemTrait> {
> let mut gen_items = Vec::new();
> + let mut has_this_module = false;
>
> gen_items.push(parse_quote! {
> /// A marker to prevent implementors from forgetting to use [`#[vtable]`](vtable)
> @@ -30,6 +31,28 @@ fn handle_trait(mut item: ItemTrait) -> Result<ItemTrait> {
> const USE_VTABLE_ATTR: ();
> });
>
> + // Detect existing type ThisModule so we don't add a duplicate.
> + for i in &item.items {
> + if let TraitItem::Type(type_item) = i {
> + if type_item.ident == "ThisModule" {
> + has_this_module = true;
> + }
> + }
> + }
> +
> + // Add `type ThisModule: ModuleMetadata` as a required associated type if
> + // the trait does not already define it. No default is used because
> + // `associated_type_defaults` is unstable (issue #29661).
I don't think this is relevant. What's the sensible default anyway?
> + if !has_this_module {
Perhaps just make this an one liner :
if !item.items.iter().any(|i| matches!(item, TraitItem::Type(t) if t.ident == "ThisModule")) {
> + gen_items.push(parse_quote! {
> + /// The module implementing this vtable trait.
> + ///
> + /// Automatically set to `crate::LocalModule` by the `#[vtable]`
> + /// impl macro.
> + type ThisModule: ::kernel::ModuleMetadata;
> + });
> + }
> +
> for item in &item.items {
> if let TraitItem::Fn(fn_item) = item {
> let name = &fn_item.sig.ident;
> @@ -58,18 +81,31 @@ fn handle_trait(mut item: ItemTrait) -> Result<ItemTrait> {
> fn handle_impl(mut item: ItemImpl) -> Result<ItemImpl> {
> let mut gen_items = Vec::new();
> let mut defined_consts = HashSet::new();
> + let mut defined_types = HashSet::new();
I'd just rename `defined_consts` to `defined_items` to reuse the same set as
there cannot be assoc items with same name anyway.
Best,
Gary
>
> - // Iterate over all user-defined constants to gather any possible explicit overrides.
> + // Iterate over all user-defined constants and types to gather any possible explicit overrides.
> for item in &item.items {
> if let ImplItem::Const(const_item) = item {
> defined_consts.insert(const_item.ident.clone());
> }
> + if let ImplItem::Type(type_item) = item {
> + defined_types.insert(type_item.ident.clone());
> + }
> }
>
> gen_items.push(parse_quote! {
> const USE_VTABLE_ATTR: () = ();
> });
>
> + // Auto-insert `type ThisModule = crate::LocalModule` if not explicitly defined.
> + // `crate::LocalModule` resolves to the real module type (via `module!`) or a
> + // dummy fallback in non-module contexts (e.g., doctests).
> + if !defined_types.contains(&parse_quote!(ThisModule)) {
> + gen_items.push(parse_quote! {
> + type ThisModule = crate::LocalModule;
> + });
> + }
> +
> for item in &item.items {
> if let ImplItem::Fn(fn_item) = item {
> let name = &fn_item.sig.ident;
^ permalink raw reply
* Re: [PATCH] block: remove redundant GD_NEED_PART_SCAN in add_disk_final()
From: Christoph Hellwig @ 2026-06-18 14:07 UTC (permalink / raw)
To: Connor Williamson
Cc: axboe, linux-block, linux-kernel, stable, yukuai3, hch, jack,
nh-open-source
In-Reply-To: <20260615130715.53693-1-connordw@amazon.com>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH 1/1] block: validate user space vectors during extraction
From: Keith Busch @ 2026-06-18 13:51 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Keith Busch, linux-block, linux-fsdevel, dm-devel, axboe, brauner,
djwong, viro, stable
In-Reply-To: <20260618134346.GA2752@lst.de>
On Thu, Jun 18, 2026 at 03:43:46PM +0200, Christoph Hellwig wrote:
> On Thu, Jun 18, 2026 at 07:17:35AM -0600, Keith Busch wrote:
> > > > if (iov_iter_is_bvec(iter)) {
> > > > bio_iov_bvec_set(bio, iter);
> > > > +
> > > > + if (mp_bvec_iter_offset(bio->bi_io_vec, bio->bi_iter) &
> > > > + vec_align_mask)
> > > > + return -EINVAL;
> > >
> > > Can you add a comment here? Especially as the bvec iter doesn't actually
> > > require all individual bvecs to be aligned and I'm not entirely sure this
> > > handles all case - writing down the rules might help a bit with that.
> >
> > The rationale is that the only iter_bvec users come from io_uring
> > registered buffers, which are virtually contiguous.
>
> There's plenty of iov_iter_bdev users, and even without poking deep I
> know that two directly passed on bvecs from block-layer generated bios to
> the underlying file system's direct I/O code: loop and zloop.
Oh, I meant only users that go through this direct-io path, but you're
right, I was wrong about that too. The nvme target file backend can also
get here in addition to what you pointed out.
> So we need rules on what can be passed, and preferably some way to
> enforce that at least for debug builds.
Yeah.
^ permalink raw reply
* Re: [PATCH 1/1] block: validate user space vectors during extraction
From: Christoph Hellwig @ 2026-06-18 13:43 UTC (permalink / raw)
To: Keith Busch
Cc: Christoph Hellwig, Keith Busch, linux-block, linux-fsdevel,
dm-devel, axboe, brauner, djwong, viro, stable
In-Reply-To: <ajPv7yOoYsR5O6kf@kbusch-mbp>
On Thu, Jun 18, 2026 at 07:17:35AM -0600, Keith Busch wrote:
> > > if (iov_iter_is_bvec(iter)) {
> > > bio_iov_bvec_set(bio, iter);
> > > +
> > > + if (mp_bvec_iter_offset(bio->bi_io_vec, bio->bi_iter) &
> > > + vec_align_mask)
> > > + return -EINVAL;
> >
> > Can you add a comment here? Especially as the bvec iter doesn't actually
> > require all individual bvecs to be aligned and I'm not entirely sure this
> > handles all case - writing down the rules might help a bit with that.
>
> The rationale is that the only iter_bvec users come from io_uring
> registered buffers, which are virtually contiguous.
There's plenty of iov_iter_bdev users, and even without poking deep I
know that two directly passed on bvecs from block-layer generated bios to
the underlying file system's direct I/O code: loop and zloop.
So we need rules on what can be passed, and preferably some way to
enforce that at least for debug builds.
^ permalink raw reply
* Re: [PATCH 1/1] block: validate user space vectors during extraction
From: Keith Busch @ 2026-06-18 13:17 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Keith Busch, linux-block, linux-fsdevel, dm-devel, axboe, brauner,
djwong, viro, stable
In-Reply-To: <20260618102627.GA23200@lst.de>
On Thu, Jun 18, 2026 at 12:26:27PM +0200, Christoph Hellwig wrote:
> On Wed, Jun 17, 2026 at 04:32:35PM -0700, Keith Busch wrote:
> > @@ -1251,6 +1251,11 @@ int bio_iov_iter_get_pages(struct bio *bio, struct iov_iter *iter,
> >
> > if (iov_iter_is_bvec(iter)) {
> > bio_iov_bvec_set(bio, iter);
> > +
> > + if (mp_bvec_iter_offset(bio->bi_io_vec, bio->bi_iter) &
> > + vec_align_mask)
> > + return -EINVAL;
>
> Can you add a comment here? Especially as the bvec iter doesn't actually
> require all individual bvecs to be aligned and I'm not entirely sure this
> handles all case - writing down the rules might help a bit with that.
The rationale is that the only iter_bvec users come from io_uring
registered buffers, which are virtually contiguous. Subsequent IO
referencing it provides only an offset and a length, so the only
possible unlaignment could bne the first offset (we've already verified
the total length earlier). Every subsequent vector must be page aligned
at a minimum, which is the largest possible dma alignment the block
layer allows, so we don't need to check the rest.
> > ret = iov_iter_extract_bvecs(iter, bio->bi_io_vec,
> > BIO_MAX_SIZE - bio->bi_iter.bi_size,
> > - &bio->bi_vcnt, bio->bi_max_vecs, flags);
> > + &bio->bi_vcnt, bio->bi_max_vecs,
> > + vec_align_mask, flags);
> > if (ret <= 0) {
> > + if (ret == -EINVAL) {
> > + bio_release_pages(bio, false);
> > + bio_clear_flag(bio, BIO_PAGE_PINNED);
> > + bio->bi_iter.bi_size = 0;
> > + bio->bi_vcnt = 0;
> > + return ret;
> > + }
>
> Do we need all this cleanups beyoned the bio_release_pages()? Most
> callers just free the bio, so should not care about it, and the error
> handling in __blkdev_direct_IO that calls bio_endio looks buggy for
> other reasons..
Yeah, it's exactly for the __blkdev_direct_IO() error handling, though I
think clearing either the PINNED flag or bi_vcnt is sufficient after
bio_release_pages(). The rest is just resetting the bio to the initial
state since I didn't want to return both an error and something that
looks like a partially constructed bio, even if no one currently cares.
But since you mention it, __blkdev_direct_IO's handling does look wrong,
so maybe I can clean that up first.
^ permalink raw reply
* Re: [PATCH v2 3/5] btrfs: deny freezing a device while it is being removed
From: Johannes Thumshirn @ 2026-06-18 12:56 UTC (permalink / raw)
To: Christian Brauner, Chris Mason, Jens Axboe, David Sterba,
Jan Kara
Cc: Naohiro Aota, Josef Bacik, linux-btrfs, linux-block,
linux-fsdevel
In-Reply-To: <20260616-work-super-freeze_deny_upstream-v2-3-b3567c7f994b@kernel.org>
Looks good,
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
^ permalink raw reply
* Re: [PATCH v2 1/5] block: allow making a block device unfreezable
From: Johannes Thumshirn @ 2026-06-18 12:47 UTC (permalink / raw)
To: Christian Brauner, Chris Mason, Jens Axboe, David Sterba,
Jan Kara
Cc: Naohiro Aota, Josef Bacik, linux-btrfs, linux-block,
linux-fsdevel
In-Reply-To: <20260616-work-super-freeze_deny_upstream-v2-1-b3567c7f994b@kernel.org>
Looks good to me,
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
^ permalink raw reply
* Re: [PATCH v2 2/5] block: split bdev_yield_claim() out of bdev_fput()
From: Johannes Thumshirn @ 2026-06-18 12:40 UTC (permalink / raw)
To: Christian Brauner, Chris Mason, Jens Axboe, David Sterba,
Jan Kara
Cc: Naohiro Aota, Josef Bacik, linux-btrfs, linux-block,
linux-fsdevel
In-Reply-To: <20260616-work-super-freeze_deny_upstream-v2-2-b3567c7f994b@kernel.org>
Looks good to me,
Reviewd-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
^ permalink raw reply
* Re: [PATCH v2 3/7] rust: doctest: add LocalModule fallback for #[vtable] ThisModule
From: Andreas Hindborg @ 2026-06-18 12:13 UTC (permalink / raw)
To: Alvin Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block, Alvin Sun
In-Reply-To: <20260521-fix-fops-owner-v2-3-fd99079c5a04@linux.dev>
Alvin Sun <alvin.sun@linux.dev> writes:
> Add a `LocalModule` struct with a null-pointer `ModuleMetadata` impl
> in the doctest harness, so that `crate::LocalModule` (auto-inserted
> by `#[vtable]`) resolves correctly when there is no `module!` macro.
>
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Does this need to be ordered before the vtable auto insert in the patch series?
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v2 7/7] block: rnull: use `LocalModule` for `THIS_MODULE`
From: Andreas Hindborg @ 2026-06-18 12:17 UTC (permalink / raw)
To: Alvin Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block, Alvin Sun
In-Reply-To: <20260521-fix-fops-owner-v2-7-fd99079c5a04@linux.dev>
Alvin Sun <alvin.sun@linux.dev> writes:
> Replace the `THIS_MODULE` import with `LocalModule` from the crate,
> consistent with the move of `THIS_MODULE` into the `ModuleMetadata`
> trait.
>
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
You need to squash this with the previous patch.
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v2 2/7] rust: macros: auto-insert ThisModule in #[vtable]
From: Andreas Hindborg @ 2026-06-18 12:11 UTC (permalink / raw)
To: Alvin Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block, Alvin Sun
In-Reply-To: <20260521-fix-fops-owner-v2-2-fd99079c5a04@linux.dev>
Alvin Sun <alvin.sun@linux.dev> writes:
> Auto-add `type ThisModule: ::kernel::ModuleMetadata;` as a required
> associated type on the trait side if not already defined, and
> auto-insert `type ThisModule = crate::LocalModule;` on the impl side
> if not explicitly provided, eliminating the need to manually declare
> and implement `ThisModule` in every vtable trait and impl.
>
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v2 1/7] rust: module: add `THIS_MODULE` const to `ModuleMetadata` trait
From: Andreas Hindborg @ 2026-06-18 12:04 UTC (permalink / raw)
To: Alvin Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block, Alvin Sun
In-Reply-To: <20260521-fix-fops-owner-v2-1-fd99079c5a04@linux.dev>
"Alvin Sun" <alvin.sun@linux.dev> writes:
> Add a `THIS_MODULE` const to the `ModuleMetadata` trait so that
> modules can provide their `ThisModule` pointer usable in const
> contexts such as static file_operations.
>
> Move the `THIS_MODULE` static from the `module!` macro into the
> `ModuleMetadata` impl, and update `__init` to use
> `LocalModule::THIS_MODULE` instead.
>
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
> ---
> rust/kernel/lib.rs | 3 +++
> rust/macros/module.rs | 34 +++++++++++++++++-----------------
> 2 files changed, 20 insertions(+), 17 deletions(-)
>
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index b72b2fbe046d6..f0cf0705d9697 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -184,6 +184,9 @@ fn init(module: &'static ThisModule) -> impl pin_init::PinInit<Self, error::Erro
> pub trait ModuleMetadata {
> /// The name of the module as specified in the `module!` macro.
> const NAME: &'static crate::str::CStr;
> +
> + /// The module's `THIS_MODULE` pointer.
> + const THIS_MODULE: ThisModule;
> }
>
> /// Equivalent to `THIS_MODULE` in the C API.
> diff --git a/rust/macros/module.rs b/rust/macros/module.rs
> index 06c18e2075083..b6d7b3299fbf9 100644
> --- a/rust/macros/module.rs
> +++ b/rust/macros/module.rs
> @@ -497,28 +497,28 @@ pub(crate) fn module(info: ModuleInfo) -> Result<TokenStream> {
> /// Used by the printing macros, e.g. [`info!`].
> const __LOG_PREFIX: &[u8] = #name_cstr.to_bytes_with_nul();
>
> - // SAFETY: `__this_module` is constructed by the kernel at load time and will not be
> - // freed until the module is unloaded.
> - #[cfg(MODULE)]
> - static THIS_MODULE: ::kernel::ThisModule = unsafe {
> - extern "C" {
> - static __this_module: ::kernel::types::Opaque<::kernel::bindings::module>;
> - };
> -
> - ::kernel::ThisModule::from_ptr(__this_module.get())
> - };
> -
> - #[cfg(not(MODULE))]
> - static THIS_MODULE: ::kernel::ThisModule = unsafe {
> - ::kernel::ThisModule::from_ptr(::core::ptr::null_mut())
> - };
> -
> /// The `LocalModule` type is the type of the module created by `module!`,
> /// `module_pci_driver!`, `module_platform_driver!`, etc.
> type LocalModule = #type_;
>
> impl ::kernel::ModuleMetadata for #type_ {
> const NAME: &'static ::kernel::str::CStr = #name_cstr;
> +
> + #[cfg(MODULE)]
> + const THIS_MODULE: ::kernel::ThisModule = {
> + extern "C" {
> + static __this_module: ::kernel::types::Opaque<::kernel::bindings::module>;
> + }
> +
> + // SAFETY: `__this_module` is constructed by the kernel at load time
> + // and lives until the module is unloaded.
> + unsafe { ::kernel::ThisModule::from_ptr(__this_module.get()) }
> + };
> +
> + #[cfg(not(MODULE))]
> + const THIS_MODULE: ::kernel::ThisModule = unsafe {
> + ::kernel::ThisModule::from_ptr(::core::ptr::null_mut())
> + };
> }
>
> // Double nested modules, since then nobody can access the public items inside.
> @@ -616,7 +616,7 @@ pub extern "C" fn #ident_exit() {
> /// This function must only be called once.
> unsafe fn __init() -> ::kernel::ffi::c_int {
> let initer = <super::super::LocalModule as ::kernel::InPlaceModule>::init(
> - &super::super::THIS_MODULE
> + &<super::super::LocalModule as ::kernel::ModuleMetadata>::THIS_MODULE
Is it possible we could make this more ergonomic? Perhaps by adding a
helper:
fn this_module<M: ::kernel::ModuleMetadata>() -> &'static ::kernel::ThisModule {
&M::THIS_MODULE
}
Then the invocation is a little better:
let initer = <super::super::LocalModule as ::kernel::InPlaceModule>::init(
this_module::<super::super::LocalModule>()
);
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v3 6/7] rust: block: rnull: use vertical import style
From: Andreas Hindborg @ 2026-06-18 10:41 UTC (permalink / raw)
To: Alvin Sun, Arnd Bergmann, Greg Kroah-Hartman, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Jens Axboe,
Brendan Higgins, David Gow, Rae Moar
Cc: rust-for-linux, linux-block, linux-kselftest, kunit-dev,
Alvin Sun
In-Reply-To: <20260521-miscdev-use-format-v3-6-56240ca70d0c@linux.dev>
"Alvin Sun" <alvin.sun@linux.dev> writes:
> Convert `use` imports to vertical layout for better readability and
> maintainability.
>
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v2 4/5] rust: block: mq: use vertical import style
From: Andreas Hindborg @ 2026-06-18 10:29 UTC (permalink / raw)
To: Jens Axboe
Cc: Alvin Sun, Arnd Bergmann, Greg Kroah-Hartman, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Alice Ryhl, Trevor Gross, Danilo Krummrich, rust-for-linux,
linux-block, Alvin Sun
In-Reply-To: <20260520-miscdev-use-format-v2-4-64dc48fc1345@linux.dev>
"Alvin Sun" <alvin.sun@linux.dev> writes:
> Convert `use` imports to vertical layout for better readability and
> maintainability.
>
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v2 5/5] rust: block: mq: remove redundant imports and format
From: Andreas Hindborg @ 2026-06-18 10:32 UTC (permalink / raw)
To: Jens Axboe
Cc: Alvin Sun, Arnd Bergmann, Greg Kroah-Hartman, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Alice Ryhl, Trevor Gross, Danilo Krummrich, rust-for-linux,
linux-block, Alvin Sun
In-Reply-To: <20260520-miscdev-use-format-v2-5-64dc48fc1345@linux.dev>
"Alvin Sun" <alvin.sun@linux.dev> writes:
> Drop `Result`, `Pin`, `pin_data`, `pinned_drop`, `PinInit`, and
> `try_pin_init` imports already provided by `kernel::prelude`.
>
> Simplify `error` imports and flatten parameters formatting.
>
> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
Acked-by: Andreas Hindborg <a.hindborg@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>
@Jens can you pick 4/5 and 5/5?
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH 1/1] block: validate user space vectors during extraction
From: Christoph Hellwig @ 2026-06-18 10:26 UTC (permalink / raw)
To: Keith Busch
Cc: linux-block, linux-fsdevel, dm-devel, hch, axboe, brauner, djwong,
viro, Keith Busch, stable
In-Reply-To: <20260617233235.1016063-2-kbusch@meta.com>
On Wed, Jun 17, 2026 at 04:32:35PM -0700, Keith Busch wrote:
> @@ -1242,7 +1242,7 @@ static int bio_iov_iter_align_down(struct bio *bio, struct iov_iter *iter,
> * is returned only if 0 pages could be pinned.
> */
> int bio_iov_iter_get_pages(struct bio *bio, struct iov_iter *iter,
> - unsigned len_align_mask)
> + unsigned len_align_mask, unsigned vec_align_mask)
vec_align_mask needs to be documented in the kernel doc. And I find
the vec_align_mask name a bit confusing. This is all about the physical
address (really the dma address, but the page aligned offset map 1:1),
so maybe phys_align_mask or dma_align_mask might be better names?
Also wouldn't it be more natural to pass the start alignment requirement
before the length alignment paramter?
> @@ -1251,6 +1251,11 @@ int bio_iov_iter_get_pages(struct bio *bio, struct iov_iter *iter,
>
> if (iov_iter_is_bvec(iter)) {
> bio_iov_bvec_set(bio, iter);
> +
> + if (mp_bvec_iter_offset(bio->bi_io_vec, bio->bi_iter) &
> + vec_align_mask)
> + return -EINVAL;
Can you add a comment here? Especially as the bvec iter doesn't actually
require all individual bvecs to be aligned and I'm not entirely sure this
handles all case - writing down the rules might help a bit with that.
> ret = iov_iter_extract_bvecs(iter, bio->bi_io_vec,
> BIO_MAX_SIZE - bio->bi_iter.bi_size,
> - &bio->bi_vcnt, bio->bi_max_vecs, flags);
> + &bio->bi_vcnt, bio->bi_max_vecs,
> + vec_align_mask, flags);
> if (ret <= 0) {
> + if (ret == -EINVAL) {
> + bio_release_pages(bio, false);
> + bio_clear_flag(bio, BIO_PAGE_PINNED);
> + bio->bi_iter.bi_size = 0;
> + bio->bi_vcnt = 0;
> + return ret;
> + }
Do we need all this cleanups beyoned the bio_release_pages()? Most
callers just free the bio, so should not care about it, and the error
handling in __blkdev_direct_IO that calls bio_endio looks buggy for
other reasons..
> + * @align_mask: reject with -EINVAL if the source address or length is not
> + * aligned to this mask
Maybe use the same paramater name as on the bio side here?
And not for this patch, but this makes me wonder if we should handle the
len alignment in iov_iter_extract_bvecs as well, as that should simplify
it quite a bit.
^ permalink raw reply
* Re: [PATCH 1/1] block: validate user space vectors during extraction
From: kernel test robot @ 2026-06-18 10:22 UTC (permalink / raw)
To: Keith Busch, linux-block, linux-fsdevel
Cc: llvm, oe-kbuild-all, dm-devel, hch, axboe, brauner, djwong, viro,
Keith Busch, stable
In-Reply-To: <20260617233235.1016063-2-kbusch@meta.com>
Hi Keith,
kernel test robot noticed the following build warnings:
[auto build test WARNING on axboe/for-next]
[also build test WARNING on brauner-vfs/vfs.all akpm-mm/mm-nonmm-unstable linus/master v7.1 next-20260616]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Keith-Busch/block-validate-user-space-vectors-during-extraction/20260618-073522
base: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git for-next
patch link: https://lore.kernel.org/r/20260617233235.1016063-2-kbusch%40meta.com
patch subject: [PATCH 1/1] block: validate user space vectors during extraction
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260618/202606181254.ohF2ZO9K-lkp@intel.com/config)
compiler: clang version 22.1.8 (https://github.com/llvm/llvm-project ca7933e47d3a3451d81e72ac174dcb5aa28b59d1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260618/202606181254.ohF2ZO9K-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606181254.ohF2ZO9K-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> Warning: block/bio.c:1245 function parameter 'vec_align_mask' not described in 'bio_iov_iter_get_pages'
>> Warning: block/bio.c:1245 function parameter 'vec_align_mask' not described in 'bio_iov_iter_get_pages'
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH RFC 0/1] block: fix concurrent elevator change failure
From: Shin'ichiro Kawasaki @ 2026-06-18 8:04 UTC (permalink / raw)
To: Nilay Shroff; +Cc: Ming Lei, linux-block, Jens Axboe
In-Reply-To: <2371227f-43ef-4a0d-ad8f-da23eea43357@linux.ibm.com>
On Jun 17, 2026 / 16:38, Nilay Shroff wrote:
[...]
> Given the above, I'm fine with the earlier approach of upgrading update_nr_hwq_lock from
> a reader lock to a writer lock in elv_iosched_store(). That directly serializes concurrent
> scheduler updates and avoids the race on q->elevator without introducing additional lock
> ordering concerns.
Thanks for the comment. I will prepare the "writer lock in elv_iosched_store()"
approach as v2 patch.
^ permalink raw reply
* Re: [PATCH] virtio-blk: use little-endian types for the zoned fields
From: Stefano Garzarella @ 2026-06-18 7:41 UTC (permalink / raw)
To: Michael Bommarito
Cc: Michael S . Tsirkin, Jason Wang, Stefan Hajnoczi, Dmitry Fomichev,
Damien Le Moal, Jens Axboe, Paolo Bonzini, virtualization,
linux-block, linux-kernel
In-Reply-To: <20260617151727.4071754-1-michael.bommarito@gmail.com>
On Wed, Jun 17, 2026 at 11:17:27AM -0400, Michael Bommarito wrote:
>The zoned block-device fields in the virtio-blk header are typed
>__virtio{32,64}, so their endianness follows VIRTIO_F_VERSION_1. The
>zoned feature is only defined for VIRTIO 1.x devices, and the virtio
>specification defines all of its fields as little-endian. Commit
>b16a1756c716 ("virtio_blk: mark all zone fields LE") tagged them
>__le* for exactly this reason, but commit f1ba4e674feb ("virtio-blk:
>fix to match virtio spec") re-applied the reviewed version of the
>original zoned series -- which predated b16a1756 -- and silently
>restored the __virtio* typing together with the matching
>virtio*_to_cpu() / virtio_cread() accessors in the driver.
>
>Restore the little-endian typing for the zoned configuration-space
>characteristics, the zone descriptor, the zone report header and the
>ZONE_APPEND in-header sector, and read them with le*_to_cpu() and
>virtio_cread_le() to match.
>
>There is no functional change on any spec-compliant device: zoned
>requires VIRTIO_F_VERSION_1, and for a VERSION_1 device
>virtio*_to_cpu() is identical to le*_to_cpu(). The change makes the
>uapi types describe the actual wire format and removes a latent
>endianness mismatch for a (non-conformant) legacy device on a
>big-endian guest.
Not for this patch, but at this point should we do the same also for the
fields gated by the following features that IIUC are all added in 1.*:
- VIRTIO_BLK_F_MQ
- VIRTIO_BLK_F_DISCARD
- VIRTIO_BLK_F_WRITE_ZEROES
- VIRTIO_BLK_F_SECURE_ERASE
>
>Fixes: f1ba4e674feb ("virtio-blk: fix to match virtio spec")
>Suggested-by: Michael S. Tsirkin <mst@redhat.com>
>Assisted-by: Claude:claude-opus-4-8
>Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
>---
>Testing:
> - Builds with no new warnings; sparse endian-clean (C=2,
> __CHECK_ENDIAN__, CONFIG_BLK_DEV_ZONED=y) both before and after.
> - Booted under QEMU with a host-managed zoned device exposed through
> virtio-blk. Zone revalidation, blkzone report and a sequential
> write / write-pointer check return correct values; blktests zbd
> device tests 001-006 (sysfs+ioctl, report zone, reset, write split,
> write ordering, revalidate) pass, with results identical before and
> after this change -- expected, since on a VIRTIO_F_VERSION_1 device
> virtio*_to_cpu() == le*_to_cpu().
>
> drivers/block/virtio_blk.c | 38 +++++++++++++++------------------
> include/uapi/linux/virtio_blk.h | 18 ++++++++--------
> 2 files changed, 26 insertions(+), 30 deletions(-)
>
>diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
>index b1c9a27fe00f3..5532cfbde7bfe 100644
>--- a/drivers/block/virtio_blk.c
>+++ b/drivers/block/virtio_blk.c
>@@ -99,7 +99,7 @@ struct virtblk_req {
> * be the last byte.
> */
> struct {
>- __virtio64 sector;
>+ __le64 sector;
> u8 status;
> } zone_append;
> } in_hdr;
>@@ -335,14 +335,12 @@ static inline void virtblk_request_done(struct request *req)
> {
> struct virtblk_req *vbr = blk_mq_rq_to_pdu(req);
> blk_status_t status = virtblk_result(virtblk_vbr_status(vbr));
>- struct virtio_blk *vblk = req->mq_hctx->queue->queuedata;
>
> virtblk_unmap_data(req, vbr);
> virtblk_cleanup_cmd(req);
>
> if (req_op(req) == REQ_OP_ZONE_APPEND)
>- req->__sector = virtio64_to_cpu(vblk->vdev,
>- vbr->in_hdr.zone_append.sector);
>+ req->__sector = le64_to_cpu(vbr->in_hdr.zone_append.sector);
>
> blk_mq_end_request(req, status);
> }
>@@ -589,13 +587,13 @@ static int virtblk_parse_zone(struct virtio_blk *vblk,
> {
> struct blk_zone zone = { };
>
>- zone.start = virtio64_to_cpu(vblk->vdev, entry->z_start);
>+ zone.start = le64_to_cpu(entry->z_start);
> if (zone.start + vblk->zone_sectors <= get_capacity(vblk->disk))
> zone.len = vblk->zone_sectors;
> else
> zone.len = get_capacity(vblk->disk) - zone.start;
>- zone.capacity = virtio64_to_cpu(vblk->vdev, entry->z_cap);
>- zone.wp = virtio64_to_cpu(vblk->vdev, entry->z_wp);
>+ zone.capacity = le64_to_cpu(entry->z_cap);
>+ zone.wp = le64_to_cpu(entry->z_wp);
>
> switch (entry->z_type) {
> case VIRTIO_BLK_ZT_SWR:
>@@ -687,8 +685,7 @@ static int virtblk_report_zones(struct gendisk *disk, sector_t sector,
> if (ret)
> goto fail_report;
>
>- nz = min_t(u64, virtio64_to_cpu(vblk->vdev, report->nr_zones),
>- nr_zones);
>+ nz = min_t(u64, le64_to_cpu(report->nr_zones), nr_zones);
> if (!nz)
> break;
>
>@@ -698,8 +695,7 @@ static int virtblk_report_zones(struct gendisk *disk, sector_t sector,
> if (ret)
> goto fail_report;
>
>- sector = virtio64_to_cpu(vblk->vdev,
>- report->zones[i].z_start) +
>+ sector = le64_to_cpu(report->zones[i].z_start) +
> vblk->zone_sectors;
> zone_idx++;
> }
>@@ -725,18 +721,18 @@ static int virtblk_read_zoned_limits(struct virtio_blk *vblk,
>
> lim->features |= BLK_FEAT_ZONED;
>
>- virtio_cread(vdev, struct virtio_blk_config,
>- zoned.max_open_zones, &v);
>+ virtio_cread_le(vdev, struct virtio_blk_config,
>+ zoned.max_open_zones, &v);
> lim->max_open_zones = v;
> dev_dbg(&vdev->dev, "max open zones = %u\n", v);
>
>- virtio_cread(vdev, struct virtio_blk_config,
>- zoned.max_active_zones, &v);
>+ virtio_cread_le(vdev, struct virtio_blk_config,
>+ zoned.max_active_zones, &v);
> lim->max_active_zones = v;
> dev_dbg(&vdev->dev, "max active zones = %u\n", v);
>
>- virtio_cread(vdev, struct virtio_blk_config,
>- zoned.write_granularity, &wg);
>+ virtio_cread_le(vdev, struct virtio_blk_config,
>+ zoned.write_granularity, &wg);
> if (!wg) {
> dev_warn(&vdev->dev, "zero write granularity reported\n");
> return -ENODEV;
>@@ -750,8 +746,8 @@ static int virtblk_read_zoned_limits(struct virtio_blk *vblk,
> * virtio ZBD specification doesn't require zones to be a power of
> * two sectors in size, but the code in this driver expects that.
> */
>- virtio_cread(vdev, struct virtio_blk_config, zoned.zone_sectors,
>- &vblk->zone_sectors);
>+ virtio_cread_le(vdev, struct virtio_blk_config, zoned.zone_sectors,
>+ &vblk->zone_sectors);
> if (vblk->zone_sectors == 0 || !is_power_of_2(vblk->zone_sectors)) {
> dev_err(&vdev->dev,
> "zoned device with non power of two zone size %u\n",
>@@ -767,8 +763,8 @@ static int virtblk_read_zoned_limits(struct virtio_blk *vblk,
> lim->max_hw_discard_sectors = 0;
> }
>
>- virtio_cread(vdev, struct virtio_blk_config,
>- zoned.max_append_sectors, &v);
>+ virtio_cread_le(vdev, struct virtio_blk_config,
>+ zoned.max_append_sectors, &v);
> if (!v) {
> dev_warn(&vdev->dev, "zero max_append_sectors reported\n");
> return -ENODEV;
>diff --git a/include/uapi/linux/virtio_blk.h b/include/uapi/linux/virtio_blk.h
>index 3744e4da1b2a7..5af2a0300bb9d 100644
>--- a/include/uapi/linux/virtio_blk.h
>+++ b/include/uapi/linux/virtio_blk.h
>@@ -140,11 +140,11 @@ struct virtio_blk_config {
>
To avoid making this mistake again, how about adding a note here to
clarify that all the fields listed below are defined only for VIRTIO 1.x
devices and are therefore always little-endian?
Anyway, the patch LGTM:
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
> /* Zoned block device characteristics (if VIRTIO_BLK_F_ZONED) */
> struct virtio_blk_zoned_characteristics {
>- __virtio32 zone_sectors;
>- __virtio32 max_open_zones;
>- __virtio32 max_active_zones;
>- __virtio32 max_append_sectors;
>- __virtio32 write_granularity;
>+ __le32 zone_sectors;
>+ __le32 max_open_zones;
>+ __le32 max_active_zones;
>+ __le32 max_append_sectors;
>+ __le32 write_granularity;
> __u8 model;
> __u8 unused2[3];
> } zoned;
>@@ -241,11 +241,11 @@ struct virtio_blk_outhdr {
> */
> struct virtio_blk_zone_descriptor {
> /* Zone capacity */
>- __virtio64 z_cap;
>+ __le64 z_cap;
> /* The starting sector of the zone */
>- __virtio64 z_start;
>+ __le64 z_start;
> /* Zone write pointer position in sectors */
>- __virtio64 z_wp;
>+ __le64 z_wp;
> /* Zone type */
> __u8 z_type;
> /* Zone state */
>@@ -254,7 +254,7 @@ struct virtio_blk_zone_descriptor {
> };
>
> struct virtio_blk_zone_report {
>- __virtio64 nr_zones;
>+ __le64 nr_zones;
> __u8 reserved[56];
> struct virtio_blk_zone_descriptor zones[];
> };
>--
>2.53.0
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox