* [PATCH v16 07/10] rust: page: update formatting of `use` statements
From: Andreas Hindborg @ 2026-02-24 11:18 UTC (permalink / raw)
To: Miguel Ojeda, Gary Guo, Björn Roy Baron, Benno Lossin,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman,
Dave Ertman, Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
Rafael J. Wysocki, David Airlie, Simona Vetter, Alexander Viro,
Christian Brauner, Jan Kara, Igor Korotin, Daniel Almeida,
Lorenzo Stoakes, Liam R. Howlett, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Bjorn Helgaas, Krzysztof Wilczyński,
Boqun Feng, Vlastimil Babka, Uladzislau Rezki, Boqun Feng
Cc: linux-kernel, rust-for-linux, linux-block, linux-security-module,
dri-devel, linux-fsdevel, linux-mm, linux-pm, linux-pci,
Andreas Hindborg
In-Reply-To: <20260224-unique-ref-v16-0-c21afcb118d3@kernel.org>
Update formatting in preparation for next patch
Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
---
rust/kernel/page.rs | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/rust/kernel/page.rs b/rust/kernel/page.rs
index 432fc0297d4a8..bf3bed7e2d3fe 100644
--- a/rust/kernel/page.rs
+++ b/rust/kernel/page.rs
@@ -3,17 +3,23 @@
//! Kernel page allocation and management.
use crate::{
- alloc::{AllocError, Flags},
+ alloc::{
+ AllocError,
+ Flags, //
+ },
bindings,
error::code::*,
error::Result,
- uaccess::UserSliceReader,
+ uaccess::UserSliceReader, //
};
use core::{
marker::PhantomData,
mem::ManuallyDrop,
ops::Deref,
- ptr::{self, NonNull},
+ ptr::{
+ self,
+ NonNull, //
+ }, //
};
/// A bitwise shift for the page size.
--
2.51.2
^ permalink raw reply related
* Re: [RFC PATCH] fs/pidfs: Add permission check to pidfd_info()
From: Christian Brauner @ 2026-02-24 11:18 UTC (permalink / raw)
To: Daniel Durning
Cc: linux-fsdevel, linux-security-module, selinux, viro, jack, paul,
stephen.smalley.work, omosnace, Oleg Nesterov
In-Reply-To: <CAKrb_fFEvf5VzY_-zcc800wjVGOFbiGrpzC7S6Ghy9qhYJrZ1w@mail.gmail.com>
On Fri, Feb 20, 2026 at 03:45:00PM -0500, Daniel Durning wrote:
> On Tue, Feb 17, 2026 at 7:01 AM Christian Brauner <brauner@kernel.org> wrote:
> >
> > On Wed, Feb 11, 2026 at 02:43:21PM -0500, Daniel Durning wrote:
> > > On Mon, Feb 9, 2026 at 9:01 AM Christian Brauner <brauner@kernel.org> wrote:
> > > >
> > > > On Fri, Feb 06, 2026 at 06:02:48PM +0000, danieldurning.work@gmail.com wrote:
> > > > > From: Daniel Durning <danieldurning.work@gmail.com>
> > > > >
> > > > > Added a permission check to pidfd_info(). Originally, process info
> > > > > could be retrieved with a pidfd even if proc was mounted with hidepid
> > > > > enabled, allowing pidfds to be used to bypass those protections. We
> > > > > now call ptrace_may_access() to perform some DAC checking as well
> > > > > as call the appropriate LSM hook.
> > > > >
> > > > > The downside to this approach is that there are now more restrictions
> > > > > on accessing this info from a pidfd than when just using proc (without
> > > > > hidepid). I am open to suggestions if anyone can think of a better way
> > > > > to handle this.
> > > >
> > > > This isn't really workable since this would regress userspace quite a
> > > > bit. I think we need a different approach. I've given it some thought
> > > > and everything's kinda ugly but this might work.
> > > >
> > > > In struct pid_namespace record whether anyone ever mounted a procfs
> > > > with hidepid turned on for this pidns. In pidfd_info() we check whether
> > > > hidepid was ever turned on. If it wasn't we're done and can just return
> > > > the info. This will be the common case. If hidepid was ever turned on
> > > > use kern_path("/proc") to lookup procfs. If not found check
> > > > ptrace_may_access() to decide whether to return the info or not. If
> > > > /proc is found check it's hidepid settings and make a decision based on
> > > > that.
> > > >
> > > > You can probably reorder this to call ptrace_may_access() first and then
> > > > do the procfs lookup dance. Thoughts?
> > >
> > > Thanks for the feedback. I think your solution makes sense.
> > >
> > > Unfortunately, it seems like systemd mounts procfs with hidepid enabled on
> > > boot for services with the ProtectProc option enabled. This means that
> > > procfs will always have been mounted with hidepid in the init pid namespace.
> > > Do you think it would be viable to record whether or not procfs was mounted
> > > with hidepid enabled in the mount namespace instead?
> >
> > I guess we can see what it looks like.
>
> Having looked into this some more I am not sure if the mount
> namespace is viable either since a single proc instance could be in
> multiple mount namespaces. In addition the mount namespace
> does not seem to be easily accessible in the function where proc
> mount options are applied. I also considered adding an option
> similar to hidepid to pidfs, but since pidfs is not userspace-mounted
> I do not think that is possible without some significant changes.
>
> Doing a proc lookup with kern_path() does work, but it does not seem
> practical in terms of performance unless we had some other way to
> skip it in the common case.
>
> Curious if anyone else has any ideas or suggestions on how this
> could be implemented.
Ok, so there's another series that adds support for allowing to mount
procfs with subset=pid. That series currently uses an arcane mechanism
where it walks all mounts in the caller mounts namespace to find procfs
mounts and check its mount options (mount_too_revealing()). To get away
from this barbaric hack I proposed recording all fully visible procfs
mounts in a separate list on struct mnt_namespace that it can walk
whenever a new procfs mount gets plugged in. Once we've done that work
we effectively track whenever a procfs mount comes and goes from a given
mount namespace. When we plug in that mount we simply remember the
option used for the least restrictive procfs mount in that namespace in
a per-mntns "proc_visiblity" field or something.
Then in pidfs we simply do a:
visibility_restricted = READ_ONCE(current->ns_proxy->mnt_ns);
and be done with it. No locks, no lookup, no perf hit. Thoughts?
^ permalink raw reply
* Re: [PATCH v15 1/9] rust: types: Add Ownable/Owned types
From: Andreas Hindborg @ 2026-02-24 10:41 UTC (permalink / raw)
To: aliceryhl
Cc: Miguel Ojeda, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
Rafael J. Wysocki, David Airlie, Simona Vetter, Alexander Viro,
Christian Brauner, Jan Kara, Igor Korotin, Daniel Almeida,
Lorenzo Stoakes, Liam R. Howlett, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Bjorn Helgaas, Krzysztof Wilczyński,
Boqun Feng, linux-kernel, rust-for-linux, linux-block,
linux-security-module, dri-devel, linux-fsdevel, linux-mm,
linux-pm, linux-pci, Asahi Lina, Oliver Mangold
In-Reply-To: <aZ1VQmtapuoerpVo@google.com>
<aliceryhl@google.com> writes:
> On Mon, Feb 23, 2026 at 03:59:22PM +0100, Andreas Hindborg wrote:
>> Alice Ryhl <aliceryhl@google.com> writes:
>>
>> > On Fri, Feb 20, 2026 at 10:51:10AM +0100, Andreas Hindborg wrote:
>> >> From: Asahi Lina <lina+kernel@asahilina.net>
>> >>
>> >> By analogy to `AlwaysRefCounted` and `ARef`, an `Ownable` type is a
>> >> (typically C FFI) type that *may* be owned by Rust, but need not be. Unlike
>> >> `AlwaysRefCounted`, this mechanism expects the reference to be unique
>> >> within Rust, and does not allow cloning.
>> >>
>> >> Conceptually, this is similar to a `KBox<T>`, except that it delegates
>> >> resource management to the `T` instead of using a generic allocator.
>> >>
>> >> [ om:
>> >> - Split code into separate file and `pub use` it from types.rs.
>> >> - Make from_raw() and into_raw() public.
>> >> - Remove OwnableMut, and make DerefMut dependent on Unpin instead.
>> >> - Usage example/doctest for Ownable/Owned.
>> >> - Fixes to documentation and commit message.
>> >> ]
>> >>
>> >> Link: https://lore.kernel.org/all/20250202-rust-page-v1-1-e3170d7fe55e@asahilina.net/
>> >> Signed-off-by: Asahi Lina <lina+kernel@asahilina.net>
>> >> Co-developed-by: Oliver Mangold <oliver.mangold@pm.me>
>> >> Signed-off-by: Oliver Mangold <oliver.mangold@pm.me>
>> >> Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
>> >> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
>> >> [ Andreas: Updated documentation, examples, and formatting ]
>> >> Reviewed-by: Gary Guo <gary@garyguo.net>
>> >> Co-developed-by: Andreas Hindborg <a.hindborg@kernel.org>
>> >> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>> >
>> >> +/// let result = NonNull::new(KBox::into_raw(result))
>> >> +/// .expect("Raw pointer to newly allocation KBox is null, this should never happen.");
>> >
>> > KBox should probably have an into_raw_nonnull().
>>
>> I can add that.
>>
>> >
>> >> +/// let foo = Foo::new().expect("Failed to allocate a Foo. This shouldn't happen");
>> >> +/// assert!(*FOO_ALLOC_COUNT.lock() == 1);
>> >
>> > Use ? here.
>>
>> Ok.
>>
>> >
>> >> +/// }
>> >> +/// // `foo` is out of scope now, so we expect no live allocations.
>> >> +/// assert!(*FOO_ALLOC_COUNT.lock() == 0);
>> >> +/// ```
>> >> +pub unsafe trait Ownable {
>> >> + /// Releases the object.
>> >> + ///
>> >> + /// # Safety
>> >> + ///
>> >> + /// Callers must ensure that:
>> >> + /// - `this` points to a valid `Self`.
>> >> + /// - `*this` is no longer used after this call.
>> >> + unsafe fn release(this: NonNull<Self>);
>> >
>> > Honestly, not using it after this call may be too strong. I can imagine
>> > wanting a value where I have both an ARef<_> and Owned<_> reference to
>> > something similar to the existing Arc<_>/ListArc<_> pattern, and in that
>> > case the value may in fact be accessed after this call if you still have
>> > an ARef<_>.
>>
>> I do not understand your use case.
>>
>> You are not supposed to have both an `ARef` and an `Owned` at the same
>> time. The `Owned` is to `ARef` what `UniqueArc` is to `Arc`. It is
>> supposed to be unique and no `ARef` can be live while the `Owned` is
>> live.
>>
>> A `ListArc` is "at most one per list link" and it takes a refcount on
>> the object by owning an `Arc`. As far as I recall, it does not provide
>> mutable access to anything but the list link. To me, that is a very
>> different situation.
>
> I mean, even Page is kind of an example like that.
>
> Pages are refcounted, but when you have a higher-order page, the
> __free_pages() call does something special beyond what put_page(). For
> example, if you have an order-2 page, which consists of 4 pages, then
> the refcount only keeps the first page alive, and __free_pages() frees
> the 3 extra pages right away even if refcount is still non-zero. The
> first page then stays alive until the last put_page() is called.
I see. We currently only support order 0 pages. I think we can handle
this situation later, if we need to handle higher order pages.
In that case, we could hand out `Owned<Page>` for the head page and then
provide some way of getting a `&Page` for the tail pages. Obtaining
`Owned<Page>` for a tail page does not make sense.
More likely we will build an abstraction for `struct folio`. We can
still hand some kind of page reference for tail pages from an `Owned<Folio>`.
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v2 12/15] ovl: change ovl_create_real() to get a new lock when re-opening created file.
From: Christian Brauner @ 2026-02-24 9:20 UTC (permalink / raw)
To: Chris Mason
Cc: NeilBrown, Alexander Viro, David Howells, Jan Kara, Chuck Lever,
Jeff Layton, Miklos Szeredi, Amir Goldstein, John Johansen,
Paul Moore, James Morris, Serge E. Hallyn, Stephen Smalley,
Darrick J. Wong, linux-kernel, netfs, linux-fsdevel, linux-nfs,
linux-unionfs, apparmor, linux-security-module, selinux
In-Reply-To: <20260223132424.105125-1-clm@meta.com>
On Mon, Feb 23, 2026 at 05:23:00AM -0800, Chris Mason wrote:
> NeilBrown <neilb@ownmail.net> wrote:
> > From: NeilBrown <neil@brown.name>
> >
> > When ovl_create_real() is used to create a file on the upper filesystem
> > it needs to return the resulting dentry - positive and hashed.
> > It is usually the case the that dentry passed to the create function
> > (e.g. vfs_create()) will be suitable but this is not guaranteed. The
> > filesystem may unhash that dentry forcing a repeat lookup next time the
> > name is wanted.
> >
>
> Hi everyone,
>
> Amir suggested I run these through, and this commit was flagged:
>
> commit 62d49d1e44667e4f93bec415faabec5526992ac0
> Author: NeilBrown <neil@brown.name>
>
> ovl: change ovl_create_real() to get a new lock when re-opening created file.
>
> This commit changes ovl_create_real() to drop the directory lock and
> reacquire a new lock for lookup when the created dentry is unhashed. It
> also removes ovl_lookup_upper() which is no longer used.
>
> Signed-off-by: NeilBrown <neil@brown.name>
Fwiw, all patches that are applied go through AI review. My plan is to
have a discussion on getting automation set up for this at LSFMM so that
we can have the bot directly reply to reviews but under our control so
we can vet reviews.
^ permalink raw reply
* [syzbot] [mm?] INFO: rcu detected stall in sys_rename (8)
From: syzbot @ 2026-02-24 8:50 UTC (permalink / raw)
To: jmorris, linux-kernel, linux-mm, linux-security-module, paul,
penguin-kernel, serge, syzkaller-bugs, takedakn
Hello,
syzbot found the following issue on:
HEAD commit: 44982d352c33 Add linux-next specific files for 20260219
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10ef3c02580000
kernel config: https://syzkaller.appspot.com/x/.config?x=51f859f3211496bc
dashboard link: https://syzkaller.appspot.com/bug?extid=1e663068a97140bb66f3
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1177fe52580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/173e988354ac/disk-44982d35.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/69062373098e/vmlinux-44982d35.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3dd3887dc600/bzImage-44982d35.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1e663068a97140bb66f3@syzkaller.appspotmail.com
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P1034/2:b..l P5873/1:b..l
rcu: (detected by 1, t=10504 jiffies, g=14085, q=669 ncpus=2)
task:udevd state:R running task stack:23784 pid:5873 tgid:5873 ppid:5200 task_flags:0x400140 flags:0x00080800
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5295 [inline]
__schedule+0x1585/0x5340 kernel/sched/core.c:6907
preempt_schedule_irq+0x4d/0xa0 kernel/sched/core.c:7234
irqentry_exit+0x599/0x620 kernel/entry/common.c:239
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0010:lock_acquire+0x20b/0x2e0 kernel/locking/lockdep.c:5872
Code: e9 30 ff ff ff e8 c5 f3 18 0a f7 c3 00 02 00 00 0f 84 38 ff ff ff 65 48 8b 05 41 01 a0 11 48 3b 44 24 30 75 33 fb 48 83 c4 38 <5b> 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 48 8d 3d fe 3b 95
RSP: 0018:ffffc90003f073d8 EFLAGS: 00000286
RAX: a296ff60d4053400 RBX: 0000000000000246 RCX: 0000000000000046
RDX: 00000000112c4056 RSI: ffffffff8e287ccb RDI: ffffffff8c2a0a00
RBP: 0000000000000000 R08: ffffffff8176da45 R09: ffffffff8e9602e0
R10: ffffc90003f07538 R11: ffffffff81b115b0 R12: 0000000000000002
R13: ffffffff8e9602e0 R14: 0000000000000000 R15: 0000000000000000
rcu_lock_acquire include/linux/rcupdate.h:312 [inline]
rcu_read_lock include/linux/rcupdate.h:850 [inline]
class_rcu_constructor include/linux/rcupdate.h:1193 [inline]
unwind_next_frame+0xc2/0x23c0 arch/x86/kernel/unwind_orc.c:495
arch_stack_walk+0x11b/0x150 arch/x86/kernel/stacktrace.c:25
stack_trace_save+0xa9/0x100 kernel/stacktrace.c:122
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__do_kmalloc_node mm/slub.c:5219 [inline]
__kmalloc_noprof+0x35c/0x760 mm/slub.c:5231
kmalloc_noprof include/linux/slab.h:966 [inline]
tomoyo_realpath_from_path+0xe3/0x5d0 security/tomoyo/realpath.c:251
tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
tomoyo_path2_perm+0x2c5/0x760 security/tomoyo/file.c:927
tomoyo_path_rename+0x14e/0x1b0 security/tomoyo/tomoyo.c:300
security_path_rename+0x248/0x460 security/security.c:1518
filename_renameat2+0x4c1/0x9c0 fs/namei.c:6139
__do_sys_rename fs/namei.c:6188 [inline]
__se_sys_rename+0x55/0x2c0 fs/namei.c:6184
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f6cd687acc7
RSP: 002b:00007ffec20235f8 EFLAGS: 00000202 ORIG_RAX: 0000000000000052
RAX: ffffffffffffffda RBX: 000055db72eaa280 RCX: 00007f6cd687acc7
RDX: 000055db72ea2010 RSI: 00007ffec2023610 RDI: 00007ffec2023a10
RBP: 000055db72ebff10 R08: 00000000000001e0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffec2023610
R13: 00007ffec2023a10 R14: 0000000000000000 R15: 000055db6bd089dd
</TASK>
task:kworker/u8:7 state:R running task stack:24416 pid:1034 tgid:1034 ppid:2 task_flags:0x4208060 flags:0x00080000
Workqueue: ipv6_addrconf addrconf_dad_work
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5295 [inline]
__schedule+0x1585/0x5340 kernel/sched/core.c:6907
preempt_schedule_common+0x82/0xd0 kernel/sched/core.c:7091
preempt_schedule_thunk+0x16/0x30 arch/x86/entry/thunk.S:12
__local_bh_enable_ip+0xe1/0x130 kernel/softirq.c:457
local_bh_enable include/linux/bottom_half.h:33 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline]
__dev_queue_xmit+0x1e6c/0x38a0 net/core/dev.c:4864
NF_HOOK_COND include/linux/netfilter.h:307 [inline]
ip6_output+0x340/0x550 net/ipv6/ip6_output.c:246
NF_HOOK include/linux/netfilter.h:318 [inline]
ndisc_send_skb+0xbaa/0x14e0 net/ipv6/ndisc.c:512
ndisc_send_ns+0xd7/0x160 net/ipv6/ndisc.c:670
addrconf_dad_work+0xac4/0x14c0 net/ipv6/addrconf.c:4287
process_one_work+0x949/0x1650 kernel/workqueue.c:3279
process_scheduled_works kernel/workqueue.c:3362 [inline]
worker_thread+0xb46/0x1140 kernel/workqueue.c:3443
kthread+0x388/0x470 kernel/kthread.c:467
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
rcu: rcu_preempt kthread starved for 10573 jiffies! g14085 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:R running task stack:27616 pid:16 tgid:16 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5295 [inline]
__schedule+0x1585/0x5340 kernel/sched/core.c:6907
__schedule_loop kernel/sched/core.c:6989 [inline]
schedule+0x164/0x360 kernel/sched/core.c:7004
schedule_timeout+0x158/0x2c0 kernel/time/sleep_timeout.c:99
rcu_gp_fqs_loop+0x312/0x11d0 kernel/rcu/tree.c:2095
rcu_gp_kthread+0x9e/0x2b0 kernel/rcu/tree.c:2297
kthread+0x388/0x470 kernel/kthread.c:467
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
rcu: Stack dump where RCU GP kthread last ran:
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 UID: 0 PID: 6085 Comm: syz.0.27 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
RIP: 0010:check_kcov_mode kernel/kcov.c:194 [inline]
RIP: 0010:write_comp_data kernel/kcov.c:246 [inline]
RIP: 0010:__sanitizer_cov_trace_const_cmp4+0x36/0x90 kernel/kcov.c:314
Code: 28 e9 7b 11 65 8b 0d 49 e9 7b 11 81 e1 00 01 ff 00 74 11 81 f9 00 01 00 00 75 5b 83 ba 54 16 00 00 00 74 52 8b 8a 30 16 00 00 <83> f9 03 75 47 48 8b 8a 38 16 00 00 44 8b 8a 34 16 00 00 49 c1 e1
RSP: 0018:ffffc900025e7a88 EFLAGS: 00000046
RAX: ffffffff81b67144 RBX: ffff8880b8423e40 RCX: 0000000000000000
RDX: ffff88802df49e40 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: ffffffff81b32095 R09: ffffffff9a518508
R10: 0000000000000003 R11: ffffffff81742750 R12: 00000000100006b5
R13: dffffc0000000000 R14: 00000000000001ed R15: 0000000000000020
FS: 00007f9fec4f96c0(0000) GS:ffff888125002000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000200000000058 CR3: 0000000075658000 CR4: 00000000003526f0
Call Trace:
<TASK>
clockevents_program_event+0x1d4/0x350 kernel/time/clockevents.c:336
hrtimer_start_range_ns+0x1687/0x1ff0 kernel/time/hrtimer.c:1331
__posixtimer_deliver_signal kernel/time/posix-timers.c:314 [inline]
posixtimer_deliver_signal+0x1ce/0x410 kernel/time/posix-timers.c:340
dequeue_signal+0x249/0x370 kernel/signal.c:660
get_signal+0x55d/0x1330 kernel/signal.c:2914
arch_do_signal_or_restart+0xbc/0x830 arch/x86/kernel/signal.c:337
__exit_to_user_mode_loop kernel/entry/common.c:64 [inline]
exit_to_user_mode_loop+0x86/0x480 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
do_syscall_64+0x32d/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f9feb59c629
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f9fec4f90e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 00007f9feb815fa8 RCX: 00007f9feb59c629
RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007f9feb815fa8
RBP: 00007f9feb815fa0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f9feb816038 R14: 00007ffda92b66d0 R15: 00007ffda92b67b8
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH] landlock: Fix deadlock in restrict_one_thread_callback
From: Günther Noack @ 2026-02-24 8:48 UTC (permalink / raw)
To: Yihan Ding
Cc: Mickaël Salaün, Paul Moore, Jann Horn,
linux-security-module, linux-kernel, syzbot+7ea2f5e9dfd468201817
In-Reply-To: <20260224062729.2908692-1-dingyihan@uniontech.com>
Hello!
Thanks for sending the patch!
On Tue, Feb 24, 2026 at 02:27:29PM +0800, Yihan Ding wrote:
> syzbot found a deadlock in landlock_restrict_sibling_threads().
> When multiple threads concurrently call landlock_restrict_self() with
> sibling thread restriction enabled, they can deadlock by mutually
> queueing task_works on each other and then blocking in kernel space
> (waiting for the other to finish).
>
> Fix this by serializing the TSYNC operations within the same process
> using the exec_update_lock. This prevents concurrent invocations
> from deadlocking.
>
> Additionally, update the comments in the interrupt recovery path to
> clarify that cancel_tsync_works() is an opportunistic cleanup, and
> waiting for completion is strictly necessary to prevent a Use-After-Free
> of the stack-allocated shared_ctx.
>
> Fixes: 42fc7e6543f6 ("landlock: Multithreading support for landlock_restrict_self()")
> Reported-by: syzbot+7ea2f5e9dfd468201817@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=7ea2f5e9dfd468201817
> Signed-off-by: Yihan Ding <dingyihan@uniontech.com>
> ---
> security/landlock/tsync.c | 19 +++++++++++++++----
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/security/landlock/tsync.c b/security/landlock/tsync.c
> index de01aa899751..4e91af271f3b 100644
> --- a/security/landlock/tsync.c
> +++ b/security/landlock/tsync.c
> @@ -447,6 +447,12 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
> shared_ctx.new_cred = new_cred;
> shared_ctx.set_no_new_privs = task_no_new_privs(current);
>
> + /*
> + * Serialize concurrent TSYNC operations to prevent deadlocks
> + * when multiple threads call landlock_restrict_self() simultaneously.
> + */
> + down_write(¤t->signal->exec_update_lock);
Should we use the *_killable variant of this lock acquisition?
> /*
> * We schedule a pseudo-signal task_work for each of the calling task's
> * sibling threads. In the task work, each thread:
> @@ -527,14 +533,17 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
> -ERESTARTNOINTR);
>
> /*
> - * Cancel task works for tasks that did not start running yet,
> - * and decrement all_prepared and num_unfinished accordingly.
> + * Opportunistic improvement: try to cancel task works
> + * for tasks that did not start running yet. We do not
> + * have a guarantee that it cancels any of the enqueued
> + * task works (because task_work_run() might already have
> + * dequeued them).
> */
> cancel_tsync_works(&works, &shared_ctx);
>
> /*
> - * The remaining task works have started running, so waiting for
> - * their completion will finish.
> + * We must wait for the remaining task works to finish to
> + * prevent a use-after-free of the local shared_ctx.
> */
> wait_for_completion(&shared_ctx.all_prepared);
I do not think that we must wait for all_prepared here, as your
updated comment says: The landlock_restrict_sibling_threads() function
still waits for all of these task works to finish at the bottom where
it waits for "all_finished", so there is no UAF on the local shared
context?
I would recommend replacing the
wait_for_completion(&shared_ctx.all_prepared) call and its comment
with an explicit "break":
/*
* Break the loop with error. The cleanup code after the loop
* unblocks the remaining task_works.
*/
break;
Please also update the comment above the complete_all(ready_to_commit):
We now have either (a) all sibling threads blocking and in
"prepared" state in the task work, or (b) the preparation error is
set. Ask all threads to commit (or abort).
Then it is a bit more explicit about the error handling variant of this.
(FYI, I have tested the patch variant where I only removed the
wait_for_completion(all_prepared) call, and where I did *not* add the
additional lock at the top. In this configuration, I was unable to
get it to hang any more, even with added mdelays. But as discussed in
section 2.2 of [1], there are still difficult to reproduce scenarios
where this can theoretically fail, and it is better to use the lock at
the top.)
[1] https://lore.kernel.org/all/20260223.52c45aed20f8@gnoack.org/
Please also feel free to split up the change into a part that adds the
exec_guard_lock and a part that changes the path where the calling
thread gets interrupted. Strictly speaking, the part where we change
the interruption logic is only a nicety once we have the
exec_guard_lock in place.
> }
> @@ -557,5 +566,7 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
>
> tsync_works_release(&works);
>
> + up_write(¤t->signal->exec_update_lock);
> +
> return atomic_read(&shared_ctx.preparation_error);
> }
> --
> 2.51.0
>
Thanks,
–Günther
^ permalink raw reply
* Re: [PATCH v15 1/9] rust: types: Add Ownable/Owned types
From: aliceryhl @ 2026-02-24 7:37 UTC (permalink / raw)
To: Andreas Hindborg
Cc: Miguel Ojeda, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
Rafael J. Wysocki, David Airlie, Simona Vetter, Alexander Viro,
Christian Brauner, Jan Kara, Igor Korotin, Daniel Almeida,
Lorenzo Stoakes, Liam R. Howlett, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Bjorn Helgaas, Krzysztof Wilczyński,
Boqun Feng, linux-kernel, rust-for-linux, linux-block,
linux-security-module, dri-devel, linux-fsdevel, linux-mm,
linux-pm, linux-pci, Asahi Lina, Oliver Mangold
In-Reply-To: <87wm0333qt.fsf@t14s.mail-host-address-is-not-set>
On Mon, Feb 23, 2026 at 03:59:22PM +0100, Andreas Hindborg wrote:
> Alice Ryhl <aliceryhl@google.com> writes:
>
> > On Fri, Feb 20, 2026 at 10:51:10AM +0100, Andreas Hindborg wrote:
> >> From: Asahi Lina <lina+kernel@asahilina.net>
> >>
> >> By analogy to `AlwaysRefCounted` and `ARef`, an `Ownable` type is a
> >> (typically C FFI) type that *may* be owned by Rust, but need not be. Unlike
> >> `AlwaysRefCounted`, this mechanism expects the reference to be unique
> >> within Rust, and does not allow cloning.
> >>
> >> Conceptually, this is similar to a `KBox<T>`, except that it delegates
> >> resource management to the `T` instead of using a generic allocator.
> >>
> >> [ om:
> >> - Split code into separate file and `pub use` it from types.rs.
> >> - Make from_raw() and into_raw() public.
> >> - Remove OwnableMut, and make DerefMut dependent on Unpin instead.
> >> - Usage example/doctest for Ownable/Owned.
> >> - Fixes to documentation and commit message.
> >> ]
> >>
> >> Link: https://lore.kernel.org/all/20250202-rust-page-v1-1-e3170d7fe55e@asahilina.net/
> >> Signed-off-by: Asahi Lina <lina+kernel@asahilina.net>
> >> Co-developed-by: Oliver Mangold <oliver.mangold@pm.me>
> >> Signed-off-by: Oliver Mangold <oliver.mangold@pm.me>
> >> Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
> >> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
> >> [ Andreas: Updated documentation, examples, and formatting ]
> >> Reviewed-by: Gary Guo <gary@garyguo.net>
> >> Co-developed-by: Andreas Hindborg <a.hindborg@kernel.org>
> >> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
> >
> >> +/// let result = NonNull::new(KBox::into_raw(result))
> >> +/// .expect("Raw pointer to newly allocation KBox is null, this should never happen.");
> >
> > KBox should probably have an into_raw_nonnull().
>
> I can add that.
>
> >
> >> +/// let foo = Foo::new().expect("Failed to allocate a Foo. This shouldn't happen");
> >> +/// assert!(*FOO_ALLOC_COUNT.lock() == 1);
> >
> > Use ? here.
>
> Ok.
>
> >
> >> +/// }
> >> +/// // `foo` is out of scope now, so we expect no live allocations.
> >> +/// assert!(*FOO_ALLOC_COUNT.lock() == 0);
> >> +/// ```
> >> +pub unsafe trait Ownable {
> >> + /// Releases the object.
> >> + ///
> >> + /// # Safety
> >> + ///
> >> + /// Callers must ensure that:
> >> + /// - `this` points to a valid `Self`.
> >> + /// - `*this` is no longer used after this call.
> >> + unsafe fn release(this: NonNull<Self>);
> >
> > Honestly, not using it after this call may be too strong. I can imagine
> > wanting a value where I have both an ARef<_> and Owned<_> reference to
> > something similar to the existing Arc<_>/ListArc<_> pattern, and in that
> > case the value may in fact be accessed after this call if you still have
> > an ARef<_>.
>
> I do not understand your use case.
>
> You are not supposed to have both an `ARef` and an `Owned` at the same
> time. The `Owned` is to `ARef` what `UniqueArc` is to `Arc`. It is
> supposed to be unique and no `ARef` can be live while the `Owned` is
> live.
>
> A `ListArc` is "at most one per list link" and it takes a refcount on
> the object by owning an `Arc`. As far as I recall, it does not provide
> mutable access to anything but the list link. To me, that is a very
> different situation.
I mean, even Page is kind of an example like that.
Pages are refcounted, but when you have a higher-order page, the
__free_pages() call does something special beyond what put_page(). For
example, if you have an order-2 page, which consists of 4 pages, then
the refcount only keeps the first page alive, and __free_pages() frees
the 3 extra pages right away even if refcount is still non-zero. The
first page then stays alive until the last put_page() is called.
> > If you modify Owned<_> invariants and Owned::from_raw() safety
> > requirements along the lines of what I say below, then this could just
> > say that the caller must have permission to call this function. The
> > concrete implementer can specify what that means more directly, but here
> > all it means is that a prior call to Owned::from_raw() promised to give
> > you permission to call it.
>
> I don't think we need the "permission" wording. How about this:
>
>
> /// A mutable reference to an owned `T`.
> ///
> /// The [`Ownable`] is automatically freed or released when an instance of [`Owned`] is
> /// dropped.
> ///
> /// # Invariants
> ///
> /// - Until `T::release` is called, this `Owned<T>` exclusively owns the underlying `T`.
> /// - The `T` value is pinned.
> pub struct Owned<T: Ownable> {...}
>
>
> impl<T: Ownable> Owned<T> {
> /// Creates a new instance of [`Owned`].
> ///
> /// This function takes over ownership of the underlying object.
> ///
> /// # Safety
> ///
> /// Callers must ensure that:
> /// - `ptr` points to a valid instance of `T`.
> /// - Until `T::release` is called, the returned `Owned<T>` exclusively owns the underlying `T`.
> pub unsafe fn from_raw(ptr: NonNull<T>) -> Self {...}
> }
>
> pub trait Ownable {
> /// Tear down this `Ownable`.
> ///
> /// Implementers of `Ownable` can use this function to clean up the use of `Self`. This can
> /// include freeing the underlying object.
> ///
> /// # Safety
> ///
> /// Callers must ensure that the caller has exclusive ownership of `T`, and this ownership can
> /// be transferred to the `release` method.
> unsafe fn release(&mut self);
> }
>
>
> Note `Ownable` not being an unsafe trait.
It looks ok but see my above reply.
> >> +/// A mutable reference to an owned `T`.
> >> +///
> >> +/// The [`Ownable`] is automatically freed or released when an instance of [`Owned`] is
> >> +/// dropped.
> >> +///
> >> +/// # Invariants
> >> +///
> >> +/// - The [`Owned<T>`] has exclusive access to the instance of `T`.
> >> +/// - The instance of `T` will stay alive at least as long as the [`Owned<T>`] is alive.
> >> +pub struct Owned<T: Ownable> {
> >> + ptr: NonNull<T>,
> >> +}
> >
> > I think some more direct and less fuzzy invariants would be:
> >
> > - This `Owned<T>` holds permissions to call `T::release()` on the value once.
> > - Until `T::release()` is called, this `Owned<T>` may perform mutable access on the `T`.
>
> I do not like the wording for mutable access. Formulating safety
> requirements for `from_raw` and safety comments for that function
> becomes convoluted like this. I'd rather formulate the
> access capability in terms of ownership;
>
> - Until `T::release()` is called, this `Owned<T>` exclusively owns the
> underlying `T`.
>
> How is that?
>
> > - The `T` value is pinned.
>
> I am unsure about the pinning terminology. If we say that `T` is pinned,
> does this mean that it will never move, even if `T: Unpin`? Or is it
> implied that `T` may move if it is `Unpin`?
Values that are `Unpin` can always move - pinning is a no-op for them.
Alice
^ permalink raw reply
* [PATCH] landlock: Fix deadlock in restrict_one_thread_callback
From: Yihan Ding @ 2026-02-24 6:27 UTC (permalink / raw)
To: Mickaël Salaün, Günther Noack
Cc: Paul Moore, Jann Horn, linux-security-module, linux-kernel,
syzbot+7ea2f5e9dfd468201817, Yihan Ding
In-Reply-To: <20260223.52c45aed20f8@gnoack.org>
syzbot found a deadlock in landlock_restrict_sibling_threads().
When multiple threads concurrently call landlock_restrict_self() with
sibling thread restriction enabled, they can deadlock by mutually
queueing task_works on each other and then blocking in kernel space
(waiting for the other to finish).
Fix this by serializing the TSYNC operations within the same process
using the exec_update_lock. This prevents concurrent invocations
from deadlocking.
Additionally, update the comments in the interrupt recovery path to
clarify that cancel_tsync_works() is an opportunistic cleanup, and
waiting for completion is strictly necessary to prevent a Use-After-Free
of the stack-allocated shared_ctx.
Fixes: 42fc7e6543f6 ("landlock: Multithreading support for landlock_restrict_self()")
Reported-by: syzbot+7ea2f5e9dfd468201817@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7ea2f5e9dfd468201817
Signed-off-by: Yihan Ding <dingyihan@uniontech.com>
---
security/landlock/tsync.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/security/landlock/tsync.c b/security/landlock/tsync.c
index de01aa899751..4e91af271f3b 100644
--- a/security/landlock/tsync.c
+++ b/security/landlock/tsync.c
@@ -447,6 +447,12 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
shared_ctx.new_cred = new_cred;
shared_ctx.set_no_new_privs = task_no_new_privs(current);
+ /*
+ * Serialize concurrent TSYNC operations to prevent deadlocks
+ * when multiple threads call landlock_restrict_self() simultaneously.
+ */
+ down_write(¤t->signal->exec_update_lock);
+
/*
* We schedule a pseudo-signal task_work for each of the calling task's
* sibling threads. In the task work, each thread:
@@ -527,14 +533,17 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
-ERESTARTNOINTR);
/*
- * Cancel task works for tasks that did not start running yet,
- * and decrement all_prepared and num_unfinished accordingly.
+ * Opportunistic improvement: try to cancel task works
+ * for tasks that did not start running yet. We do not
+ * have a guarantee that it cancels any of the enqueued
+ * task works (because task_work_run() might already have
+ * dequeued them).
*/
cancel_tsync_works(&works, &shared_ctx);
/*
- * The remaining task works have started running, so waiting for
- * their completion will finish.
+ * We must wait for the remaining task works to finish to
+ * prevent a use-after-free of the local shared_ctx.
*/
wait_for_completion(&shared_ctx.all_prepared);
}
@@ -557,5 +566,7 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
tsync_works_release(&works);
+ up_write(¤t->signal->exec_update_lock);
+
return atomic_read(&shared_ctx.preparation_error);
}
--
2.51.0
^ permalink raw reply related
* Re: [syzbot] [kernel?] INFO: task hung in restrict_one_thread_callback
From: Ding Yihan @ 2026-02-24 3:02 UTC (permalink / raw)
To: Günther Noack
Cc: Günther Noack, syzbot, Mickaël Salaün,
linux-security-module, Jann Horn, Paul Moore
In-Reply-To: <aZxvXARvYf6aQBUv@google.com>
Hi Günther,
Thank you for the detailed analysis! I completely agree that serializing the TSYNC
operations is the right way to prevent this deadlock. I have drafted a patch using
`exec_update_lock` (similar to how seccomp uses `cred_guard_mutex`).
Regarding your proposal to split this into two patches (one for the cleanup
path and one for the lock): Maybe combining them into a single patch is a better choice. Here is why:
We actually *cannot* remove `wait_for_completion(&shared_ctx.all_prepared)`
in the interrupt recovery path. Since `shared_ctx` is allocated on the local
stack of the caller, removing the wait would cause a severe Use-After-Free (UAF) if the
thread returns to userspace while sibling task_works are still executing and dereferencing `ctx`.
By adding the lock, we inherently resolve the deadlock, meaning the sibling task_works
will never get stuck. Thus, `wait_for_completion` becomes perfectly safe to keep,
and it remains strictly necessary to protect the stack memory. Therefore, the "fix" for the
cleanup path is simply updating the comments to reflect this reality, which is tightly coupled with the locking fix.
It felt more cohesive as a single patch.
I have test the patch on my laptop,and it will not trigger the issue.Let's have syzbot test this combined logic:
#syz test:
--- a/security/landlock/tsync.c
+++ b/security/landlock/tsync.c
@@ -447,6 +447,12 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
shared_ctx.new_cred = new_cred;
shared_ctx.set_no_new_privs = task_no_new_privs(current);
+ /*
+ * Serialize concurrent TSYNC operations to prevent deadlocks
+ * when multiple threads call landlock_restrict_self() simultaneously.
+ */
+ down_write(¤t->signal->exec_update_lock);
+
/*
* We schedule a pseudo-signal task_work for each of the calling task's
* sibling threads. In the task work, each thread:
@@ -527,14 +533,17 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
-ERESTARTNOINTR);
/*
- * Cancel task works for tasks that did not start running yet,
- * and decrement all_prepared and num_unfinished accordingly.
+ * Opportunistic improvement: try to cancel task works
+ * for tasks that did not start running yet. We do not
+ * have a guarantee that it cancels any of the enqueued
+ * task works (because task_work_run() might already have
+ * dequeued them).
*/
cancel_tsync_works(&works, &shared_ctx);
/*
- * The remaining task works have started running, so waiting for
- * their completion will finish.
+ * We must wait for the remaining task works to finish to
+ * prevent a use-after-free of the local shared_ctx.
*/
wait_for_completion(&shared_ctx.all_prepared);
}
@@ -557,5 +566,7 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
tsync_works_release(&works);
+ up_write(¤t->signal->exec_update_lock);
+
return atomic_read(&shared_ctx.preparation_error);
}
--
在 2026/2/23 23:16, Günther Noack 写道:
> Hello!
>
> On Mon, Feb 23, 2026 at 07:29:56PM +0800, Ding Yihan wrote:
>> Thank you for the detailed analysis and the clear breakdown.
>> Apologies for the delayed response. I spent the last couple of days
>> thoroughly reading through the previous mailing list discussions. I
>> was trying hard to see if there was any viable pure lockless design
>> that could solve this concurrency issue while preserving the original
>> architecture.
>>
>> However, after looking at the complexities you outlined, I completely
>> agree with your conclusion: serializing the TSYNC operations is indeed
>> the most robust and reasonable path forward to prevent the deadlock.
>>
>> Regarding the lock choice, since 'cred_guard_mutex' is explicitly
>> marked as deprecated for new code in the kernel,maybe we can use its
>> modern replacement: 'exec_update_lock' (using down_write_trylock /
>> up_write on current->signal). This aligns with the current subsystem
>> standards and was also briefly touched upon by Jann in the older
>> discussions.
>>
>> I fully understand the requirement for the two-part patch series:
>> 1. Cleaning up the cancellation logic and comments.
>> 2. Introducing the serialization lock for TSYNC.
>>
>> I will take some time to draft and test this patch series properly.
>> I also plan to discuss this with my kernel colleagues here at
>> UnionTech to see if they have any additional suggestions on the
>> implementation details before I submit it.
>>
>> I will send out the v1 patch series to the list as soon as it is
>> ready. Thanks again for your guidance and the great discussion!
>
> Thank you, Ding, this is much appreciated!
>
> I agree, the `exec_update_lock` might be the better solution;
> I also need to familiarize myself more with it to double-check.
>
> —Günther
>
^ permalink raw reply
* Re: [syzbot] [kernel?] INFO: task hung in restrict_one_thread_callback
From: syzbot @ 2026-02-24 3:03 UTC (permalink / raw)
To: dingyihan
Cc: dingyihan, gnoack3000, gnoack, jannh, linux-security-module, mic,
paul, linux-kernel, syzkaller-bugs
In-Reply-To: <D0013EA515055145+3e08a07b-e384-4c08-ab17-f558f0130d30@uniontech.com>
> Hi Günther,
>
> Thank you for the detailed analysis! I completely agree that serializing the TSYNC
> operations is the right way to prevent this deadlock. I have drafted a patch using
> `exec_update_lock` (similar to how seccomp uses `cred_guard_mutex`).
>
> Regarding your proposal to split this into two patches (one for the cleanup
> path and one for the lock): Maybe combining them into a single patch is a better choice. Here is why:
>
> We actually *cannot* remove `wait_for_completion(&shared_ctx.all_prepared)`
> in the interrupt recovery path. Since `shared_ctx` is allocated on the local
> stack of the caller, removing the wait would cause a severe Use-After-Free (UAF) if the
> thread returns to userspace while sibling task_works are still executing and dereferencing `ctx`.
>
> By adding the lock, we inherently resolve the deadlock, meaning the sibling task_works
> will never get stuck. Thus, `wait_for_completion` becomes perfectly safe to keep,
> and it remains strictly necessary to protect the stack memory. Therefore, the "fix" for the
> cleanup path is simply updating the comments to reflect this reality, which is tightly coupled with the locking fix.
> It felt more cohesive as a single patch.
>
> I have test the patch on my laptop,and it will not trigger the issue.Let's have syzbot test this combined logic:
>
> #syz test:
"---" does not look like a valid git repo address.
>
> --- a/security/landlock/tsync.c
>
> +++ b/security/landlock/tsync.c
>
> @@ -447,6 +447,12 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
>
> shared_ctx.new_cred = new_cred;
>
> shared_ctx.set_no_new_privs = task_no_new_privs(current);
>
>
>
> + /*
>
> + * Serialize concurrent TSYNC operations to prevent deadlocks
>
> + * when multiple threads call landlock_restrict_self() simultaneously.
>
> + */
>
> + down_write(¤t->signal->exec_update_lock);
>
> +
>
> /*
>
> * We schedule a pseudo-signal task_work for each of the calling task's
>
> * sibling threads. In the task work, each thread:
>
> @@ -527,14 +533,17 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
>
> -ERESTARTNOINTR);
>
>
>
> /*
>
> - * Cancel task works for tasks that did not start running yet,
>
> - * and decrement all_prepared and num_unfinished accordingly.
>
> + * Opportunistic improvement: try to cancel task works
>
> + * for tasks that did not start running yet. We do not
>
> + * have a guarantee that it cancels any of the enqueued
>
> + * task works (because task_work_run() might already have
>
> + * dequeued them).
>
> */
>
> cancel_tsync_works(&works, &shared_ctx);
>
>
>
> /*
>
> - * The remaining task works have started running, so waiting for
>
> - * their completion will finish.
>
> + * We must wait for the remaining task works to finish to
>
> + * prevent a use-after-free of the local shared_ctx.
>
> */
>
> wait_for_completion(&shared_ctx.all_prepared);
>
> }
>
> @@ -557,5 +566,7 @@ int landlock_restrict_sibling_threads(const struct cred *old_cred,
>
>
>
> tsync_works_release(&works);
>
>
>
> + up_write(¤t->signal->exec_update_lock);
>
> +
>
> return atomic_read(&shared_ctx.preparation_error);
>
> }
>
> --
> 在 2026/2/23 23:16, Günther Noack 写道:
>> Hello!
>>
>> On Mon, Feb 23, 2026 at 07:29:56PM +0800, Ding Yihan wrote:
>>> Thank you for the detailed analysis and the clear breakdown.
>>> Apologies for the delayed response. I spent the last couple of days
>>> thoroughly reading through the previous mailing list discussions. I
>>> was trying hard to see if there was any viable pure lockless design
>>> that could solve this concurrency issue while preserving the original
>>> architecture.
>>>
>>> However, after looking at the complexities you outlined, I completely
>>> agree with your conclusion: serializing the TSYNC operations is indeed
>>> the most robust and reasonable path forward to prevent the deadlock.
>>>
>>> Regarding the lock choice, since 'cred_guard_mutex' is explicitly
>>> marked as deprecated for new code in the kernel,maybe we can use its
>>> modern replacement: 'exec_update_lock' (using down_write_trylock /
>>> up_write on current->signal). This aligns with the current subsystem
>>> standards and was also briefly touched upon by Jann in the older
>>> discussions.
>>>
>>> I fully understand the requirement for the two-part patch series:
>>> 1. Cleaning up the cancellation logic and comments.
>>> 2. Introducing the serialization lock for TSYNC.
>>>
>>> I will take some time to draft and test this patch series properly.
>>> I also plan to discuss this with my kernel colleagues here at
>>> UnionTech to see if they have any additional suggestions on the
>>> implementation details before I submit it.
>>>
>>> I will send out the v1 patch series to the list as soon as it is
>>> ready. Thanks again for your guidance and the great discussion!
>>
>> Thank you, Ding, this is much appreciated!
>>
>> I agree, the `exec_update_lock` might be the better solution;
>> I also need to familiarize myself more with it to double-check.
>>
>> —Günther
>>
>
^ permalink raw reply
* Re: [PATCH v2 12/15] ovl: change ovl_create_real() to get a new lock when re-opening created file.
From: NeilBrown @ 2026-02-23 22:30 UTC (permalink / raw)
To: Chris Mason
Cc: Christian Brauner, Alexander Viro, David Howells, Jan Kara,
Chuck Lever, Jeff Layton, Miklos Szeredi, Amir Goldstein,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Stephen Smalley, Darrick J. Wong, linux-kernel, netfs,
linux-fsdevel, linux-nfs, linux-unionfs, apparmor,
linux-security-module, selinux
In-Reply-To: <20260223132424.105125-1-clm@meta.com>
On Tue, 24 Feb 2026, Chris Mason wrote:
> NeilBrown <neilb@ownmail.net> wrote:
> > From: NeilBrown <neil@brown.name>
> >
> > When ovl_create_real() is used to create a file on the upper filesystem
> > it needs to return the resulting dentry - positive and hashed.
> > It is usually the case the that dentry passed to the create function
> > (e.g. vfs_create()) will be suitable but this is not guaranteed. The
> > filesystem may unhash that dentry forcing a repeat lookup next time the
> > name is wanted.
> >
>
> Hi everyone,
>
> Amir suggested I run these through, and this commit was flagged:
>
> commit 62d49d1e44667e4f93bec415faabec5526992ac0
> Author: NeilBrown <neil@brown.name>
>
> ovl: change ovl_create_real() to get a new lock when re-opening created file.
>
> This commit changes ovl_create_real() to drop the directory lock and
> reacquire a new lock for lookup when the created dentry is unhashed. It
> also removes ovl_lookup_upper() which is no longer used.
>
> Signed-off-by: NeilBrown <neil@brown.name>
>
> > diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
> > index c4feb89ad1e39..6285069ccc590 100644
> > --- a/fs/overlayfs/dir.c
> > +++ b/fs/overlayfs/dir.c
> > @@ -159,7 +159,8 @@ int ovl_cleanup_and_whiteout(struct ovl_fs *ofs, struct dentry *dir,
> > }
> >
> > struct dentry *ovl_create_real(struct ovl_fs *ofs, struct dentry *parent,
> > - struct dentry *newdentry, struct ovl_cattr *attr)
> > + struct dentry *newdentry, struct qstr *qname,
> > + struct ovl_cattr *attr)
> > {
> > struct inode *dir = parent->d_inode;
> > int err;
> > @@ -221,19 +222,29 @@ struct dentry *ovl_create_real(struct ovl_fs *ofs, struct dentry *parent,
> > struct dentry *d;
> > /*
> > * Some filesystems (i.e. casefolded) may return an unhashed
> > - * negative dentry from the ovl_lookup_upper() call before
> > + * negative dentry from the ovl_start_creating_upper() call before
> > * ovl_create_real().
> > * In that case, lookup again after making the newdentry
> > * positive, so ovl_create_upper() always returns a hashed
> > - * positive dentry.
> > + * positive dentry. We lookup using qname which should be
> > + * the same name as newentry, but is certain not to change.
> > + * As we have to drop the lock before the lookup a race
> > + * could result in a lookup failure. In that case we return
> > + * an error.
> > */
> > - d = ovl_lookup_upper(ofs, newdentry->d_name.name, parent,
> > - newdentry->d_name.len);
> > - dput(newdentry);
> > - if (IS_ERR_OR_NULL(d))
> > + end_creating_keep(newdentry);
> > + d = ovl_start_creating_upper(ofs, parent, qname);
> > +
> > + if (IS_ERR_OR_NULL(d)) {
> > err = d ? PTR_ERR(d) : -ENOENT;
> > + } else if (d->d_inode != newdentry->d_inode) {
> > + err = -EIO;
> > + dput(newdentry);
> > + } else {
> > + dput(newdentry);
> > return d;
> > + }
> > + return ERR_PTR(err);
> > }
>
> Does this leak the newdentry reference when IS_ERR_OR_NULL(d) is true?
>
> The code now calls end_creating_keep(newdentry) which keeps the reference,
> then calls ovl_start_creating_upper(). If that returns an error or NULL,
> the function returns ERR_PTR(err) without cleaning up newdentry:
>
> end_creating_keep(newdentry);
> d = ovl_start_creating_upper(ofs, parent, qname);
>
> if (IS_ERR_OR_NULL(d)) {
> err = d ? PTR_ERR(d) : -ENOENT;
> } ...
> return ERR_PTR(err);
>
> The old code always went through the 'out:' label which called
> end_creating(newdentry) on error. The new code bypasses that cleanup.
>
>
> Does this leak both the parent lock and the dentry 'd' when the lookup
> returns a different inode?
>
> When d->d_inode != newdentry->d_inode, the code sets err = -EIO and calls
> dput(newdentry), but doesn't clean up 'd':
>
> } else if (d->d_inode != newdentry->d_inode) {
> err = -EIO;
> dput(newdentry);
> } ...
> return ERR_PTR(err);
>
> The dentry 'd' was returned by ovl_start_creating_upper() with the parent
> directory lock held. The code needs to call end_creating(d) to release the
> lock via end_dirop()->inode_unlock() and release the dentry reference via
> end_dirop()->dput().
>
>
Yes, that code is rather messed up - thanks.
I've made it:
end_creating_keep(newdentry);
d = ovl_start_creating_upper(ofs, parent, qname);
if (IS_ERR_OR_NULL(d)) {
err = d ? PTR_ERR(d) : -ENOENT;
} else if (d->d_inode != newdentry->d_inode) {
err = -EIO;
} else {
dput(newdentry);
return d;
}
end_creating(d);
dput(newdentry);
return ERR_PTR(err);
Thanks,
NeilBrown
^ permalink raw reply
* Re: [PATCH v2 09/15] ovl: Simplify ovl_lookup_real_one()
From: NeilBrown @ 2026-02-23 22:21 UTC (permalink / raw)
To: Amir Goldstein
Cc: Chris Mason, Christian Brauner, Alexander Viro, David Howells,
Jan Kara, Chuck Lever, Jeff Layton, Miklos Szeredi, John Johansen,
Paul Moore, James Morris, Serge E. Hallyn, Stephen Smalley,
Darrick J. Wong, linux-kernel, netfs, linux-fsdevel, linux-nfs,
linux-unionfs, apparmor, linux-security-module, selinux
In-Reply-To: <CAOQ4uxirM8dW9rOw4SvGtfH-s0Eg9LGuFk1aZooMvEDc=2tbyA@mail.gmail.com>
On Tue, 24 Feb 2026, Amir Goldstein wrote:
> On Mon, Feb 23, 2026 at 2:20 PM Chris Mason <clm@meta.com> wrote:
> >
> > NeilBrown <neilb@ownmail.net> wrote:
> > > From: NeilBrown <neil@brown.name>
> > >
> > > The primary purpose of this patch is to remove the locking from
> > > ovl_lookup_real_one() as part of centralising all locking of directories
> > > for name operations.
> > >
> > > The locking here isn't needed. By performing consistency tests after
> > > the lookup we can be sure that the result of the lookup was valid at
> > > least for a moment, which is all the original code promised.
> > >
> > > lookup_noperm_unlocked() is used for the lookup and it will take the
> > > lock if needed only where it is needed.
> > >
> > > Also:
> > > - don't take a reference to real->d_parent. The parent is
> > > only use for a pointer comparison, and no reference is needed for
> > > that.
> > > - Several "if" statements have a "goto" followed by "else" - the
> > > else isn't needed: the following statement can directly follow
> > > the "if" as a new statement
> > > - Use a consistent pattern of setting "err" before performing a test
> > > and possibly going to "fail".
> > > - remove the "out" label (now that we don't need to dput(parent) or
> > > unlock) and simply return from fail:.
> >
> > Hi everyone,
> >
> > Amir asked me to run these through, and this commit was flagged. I recently
> > changed the prompts to include some vfs knowledge:
>
> Thanks Chris!
>
> >
> > https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/vfs.md
> >
> > And I also put in some words to make it prefer reporting problems that might
> > not be bugs, but that do violate some rule in the .md files. This might
> > be a false positive from that new shift toward blindly trusting the guides,
> > but I'll let everyone here decide:
> >
> > commit d1bfcef048896cdc9e4c57e3249b6ad344d64c02
> > Author: NeilBrown <neil@brown.name>
> >
> > ovl: Simplify ovl_lookup_real_one()
> >
> > This patch removes locking from ovl_lookup_real_one() and reorganizes the
> > control flow. The function now uses lookup_noperm_unlocked() instead of
> > lookup_noperm() and performs consistency validation after the lookup rather
> > than holding a lock during the operation.
> >
> > > diff --git a/fs/overlayfs/export.c b/fs/overlayfs/export.c
> > > index 83f80fdb15674..b448fc9424b64 100644
> > > --- a/fs/overlayfs/export.c
> > > +++ b/fs/overlayfs/export.c
> > > @@ -349,69 +349,64 @@ static struct dentry *ovl_dentry_real_at(struct dentry *dentry, int idx)
> > > return NULL;
> > > }
> > >
> > > -/*
> > > - * Lookup a child overlay dentry to get a connected overlay dentry whose real
> > > - * dentry is @real. If @real is on upper layer, we lookup a child overlay
> > > - * dentry with the same name as the real dentry. Otherwise, we need to consult
> > > - * index for lookup.
> > > +/**
> > > + * ovl_lookup_real_one - Lookup a child overlay dentry to get an overlay dentry whose real dentry is given
> > > + * @connected: parent overlay dentry
> > > + * @real: given child real dentry
> > > + * @layer: layer in which @real exists
> > > + *
> > > + *
> > > + * Lookup a child overlay dentry in @connected with the same name as the @real
> > > + * dentry. Then check that the parent of the result is the real dentry for
> > > + * @connected, and @real is the real dentry for the result.
> > > + *
> > > + * Returns:
> > > + * %-ECHILD if the parent of @real is no longer the real dentry for @connected.
> > > + * %-ESTALE if @real is no the real dentry of the found dentry.
> > ^^
> > There's a typo here: "is no the" should be "is not the".
> >
> > > + * Otherwise the found dentry is returned.
> > > */
> > > static struct dentry *ovl_lookup_real_one(struct dentry *connected,
> > > struct dentry *real,
> > > const struct ovl_layer *layer)
> > > {
> > > - struct inode *dir = d_inode(connected);
> > > - struct dentry *this, *parent = NULL;
> > > + struct dentry *this;
> > > struct name_snapshot name;
> > > int err;
> > >
> > > /*
> > > - * Lookup child overlay dentry by real name. The dir mutex protects us
> > > - * from racing with overlay rename. If the overlay dentry that is above
> > > - * real has already been moved to a parent that is not under the
> > > - * connected overlay dir, we return -ECHILD and restart the lookup of
> > > - * connected real path from the top.
> > > - */
> > > - inode_lock_nested(dir, I_MUTEX_PARENT);
> > > - err = -ECHILD;
> > > - parent = dget_parent(real);
> > > - if (ovl_dentry_real_at(connected, layer->idx) != parent)
> > > - goto fail;
> > > -
> > > - /*
> > > - * We also need to take a snapshot of real dentry name to protect us
> > > + * We need to take a snapshot of real dentry name to protect us
> > > * from racing with underlying layer rename. In this case, we don't
> > > * care about returning ESTALE, only from dereferencing a free name
> > > * pointer because we hold no lock on the real dentry.
> > > */
> > > take_dentry_name_snapshot(&name, real);
> > > - /*
> > > - * No idmap handling here: it's an internal lookup.
> > > - */
> > > - this = lookup_noperm(&name.name, connected);
> > > + this = lookup_noperm_unlocked(&name.name, connected);
> > > release_dentry_name_snapshot(&name);
> > > +
> > > + err = -ECHILD;
> > > + if (ovl_dentry_real_at(connected, layer->idx) != real->d_parent)
> > > + goto fail;
> > > +
> >
> > A subsystem pattern flags this as potentially concerning: the VFS subsystem
> > guide indicates that TOCTOU validation checking d_parent should also check
> > d_unhashed() because a dentry can be unhashed (removed from dcache by
> > concurrent operations) while its d_parent pointer remains unchanged.
> >
> > The old code held inode_lock_nested(dir, I_MUTEX_PARENT) during the entire
> > lookup and validation, which serialized with operations that could unhash the
> > dentry. The new lockless pattern creates a window where:
> >
> > 1. lookup_noperm_unlocked() completes and returns dentry `this`
> > 2. A concurrent unlink/remove operation unhashes `this`
> > 3. The d_parent validation passes (parent pointer unchanged)
> > 4. The function returns an unhashed dentry
> >
> > Other overlayfs code uses the complete pattern. For example, in
> > ovl_lock_rename_workdir() at fs/overlayfs/util.c:
> >
> > if (work->d_parent != workdir || d_unhashed(work)) {
> > ...
> > }
> >
> > Could this validation miss a race where the dentry is unhashed but d_parent
> > still matches? The subsequent checks (!this->d_inode for -ENOENT,
> > wrong real dentry for -ESTALE) might catch some cases, but is that
> > sufficient for all the scenarios where an unhashed dentry could cause
> > problems?
> >
>
> It's a very good comment and very important rule to check, since
> we have at least 3 fix commits on breaking this rule, but as this
> code is utterly confusing to most human I do not blame LLM for getting
> confused here.
>
> The lock not taken on 'dir' which is the overlayfs inode and the checked
> 'real' dentry is on the underlying fs.
>
> Therefore, the check of real->d_parent was not protected in old code as
> well as in new code - it is a mere best effort sanity check, so I think
> there is no added risk here.
>
> Neil, do you agree?
Yes, I agree.
The relevant part of Chris' prompt is:
When a dentry reference is obtained without holding the parent inode
lock (e.g., via lookup, creation, or cached reference), and the lock is
acquired later, a TOCTOU window exists
"the lock is acquired later" is significant. In this code the lock
hasn't been acquired so the rule doesn't apply.
In this code I don't think we are testing real->d_parent, we are testing
ovl_dentry_real_at(connected, layer->idx) and making sure it is
consistent.
It is true that "real" might have been renamed and that would cause a
failure too, but that isn't really interesting. It could be renamed
just after the test just as easily (as we don't hold any locks).
In general overlayfs doesn't try to handle independent changes in the
underlying filesystems beyond "don't crash".
So it was a good comment to get, but I don't think there is any need to
change the code (though I have fixed the typo).
Thanks,
NeilBrown
>
> Thanks,
> Amir.
>
^ permalink raw reply
* Re: [PATCH] lsm: move inode IS_PRIVATE checks to individual LSMs
From: Paul Moore @ 2026-02-23 22:21 UTC (permalink / raw)
To: Casey Schaufler
Cc: danieldurning.work, linux-security-module, selinux,
linux-integrity, stephen.smalley.work, jmorris, serge,
john.johansen, zohar, roberto.sassu, dmitry.kasatkin, mic,
takedakn, penguin-kernel
In-Reply-To: <9229d70d-aa7a-459f-b005-695e99888783@schaufler-ca.com>
On Fri, Feb 20, 2026 at 4:13 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 2/20/2026 11:54 AM, danieldurning.work@gmail.com wrote:
> > From: Daniel Durning <danieldurning.work@gmail.com>
> >
> > Move responsibility of bypassing S_PRIVATE inodes to the
> > individual LSMs. Originally the LSM framework would skip calling
> > the hooks on any inode that was marked S_PRIVATE. This would
> > prevent the LSMs from controlling access to any inodes marked as
> > such (ie. pidfds). We now perform the same IS_PRIVATE checks
> > within the LSMs instead. This is consistent with the general goal
> > of deferring as much as possible to the individual LSMs.
>
> Um ... ick?
>
> Sure, we generally want the LSMs to be responsible for their own
> decisions, but that doesn't look like the point to me. What appears
> to be the issue is that pidfs isn't using S_PRIVATE in a way that
> conveys the necessary information to the LSMs.
First off, consider this the annual reminder for everyone to *please*
trim their replies when discussing things on-list. Everything is
archived on lore, we're not losing anything, and it makes things *so*
much easier to read if we don't have to skim over the entire email to
make sure we haven't missed any comments.
Now, back to the S_PRIVATE issue ...
I was the one who first suggested (it may have been on the SELinux
list, or in an off-list discussion, not sure?) that moving the
S_PRIVATE check into the individual LSMs was a way to work around the
issue with pidfd/pidfs, so please don't blame Daniel for this, he has
been doing good work trying to solve a rather ugly problem.
> > This reorganization enables the LSMs to eventually implement
> > checks or labeling for some specific S_PRIVATE inodes like pidfds.
>
> We could consider these or similar changes when that eventuality occurs.
To be clear, that time is now, that is just a dependency of that which
needs to be sorted out first.
> I would strongly suggest that this is a pidfs issue, not an LSM
> infrastructure issue.
I'm not going to argue with that, and perhaps that is a good next
step: send a quick RFC patch to the VFS folks, with the LSM list CC'd,
that drops setting the S_PRIVATE flag to see if they complain too
loudly. Based on other threads, Christian is aware that we are
starting to look at better/proper handling of pidfds/pidfs so he may
be open to dropping S_PRIVATE since it doesn't really have much impact
outside of the LSM, but who knows; the VFS folks have been growing a
bit more anti-LSM as of late.
diff --git a/fs/pidfs.c b/fs/pidfs.c
index 318253344b5c..4cec73b4cbcf 100644
--- a/fs/pidfs.c
+++ b/fs/pidfs.c
@@ -921,7 +921,7 @@ static int pidfs_init_inode(struct inode *inode, void *data)
const struct pid *pid = data;
inode->i_private = data;
- inode->i_flags |= S_PRIVATE | S_ANON_INODE;
+ inode->i_flags |= S_ANON_INODE;
/* We allow to set xattrs. */
inode->i_flags &= ~S_IMMUTABLE;
inode->i_mode |= S_IRWXU;
--
paul-moore.com
^ permalink raw reply related
* Re: [PATCH v2 06/15] selinux: Use simple_start_creating() / simple_done_creating()
From: NeilBrown @ 2026-02-23 22:07 UTC (permalink / raw)
To: Paul Moore
Cc: Chris Mason, Christian Brauner, Alexander Viro, David Howells,
Jan Kara, Chuck Lever, Jeff Layton, Miklos Szeredi,
Amir Goldstein, John Johansen, James Morris, Serge E. Hallyn,
Stephen Smalley, Darrick J. Wong, linux-kernel, netfs,
linux-fsdevel, linux-nfs, linux-unionfs, apparmor,
linux-security-module, selinux
In-Reply-To: <CAHC9VhSVjLNeTdxHmwYsGX75Z4FOAP+26=PjVdFxpmEkTrPvxA@mail.gmail.com>
On Tue, 24 Feb 2026, Paul Moore wrote:
> On Mon, Feb 23, 2026 at 8:26 AM Chris Mason <clm@meta.com> wrote:
> > NeilBrown <neilb@ownmail.net> wrote:
> > > From: NeilBrown <neil@brown.name>
> > >
> > > Instead of explicitly locking the parent and performing a lookup in
> > > selinux, use simple_start_creating(), and then use
> > > simple_done_creating() to unlock.
> > >
> >
> > Hi everyone,
> >
> > Amir suggested I run these through, and this commit was flagged:
> >
> > commit bc981629767980bbaee2ca3c7348b5a648665a9d
> > Author: NeilBrown <neil@brown.name>
> >
> > selinux: Use simple_start_creating() / simple_done_creating()
> >
> > Instead of explicitly locking the parent and performing a lookup in
> > selinux, use simple_start_creating(), and then use
> > simple_done_creating() to unlock.
> >
> > This extends the region that the directory is locked for, and also
> > performs a lookup. The lock extension is of no real consequence.
> > The lookup uses simple_lookup() and so always succeeds. Thus when
> > d_make_persistent() is called the dentry will already be hashed.
> > d_make_persistent() handles this case.
> >
> > Reviewed-by: Jeff Layton <jlayton@kernel.org>
> > Acked-by: Paul Moore <paul@paul-moore.com>
> >
> > > diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
> > > index 3245cc531555b..7d4f90e5b12a0 100644
> > > --- a/security/selinux/selinuxfs.c
> > > +++ b/security/selinux/selinuxfs.c
> > > @@ -1931,15 +1931,16 @@ static const struct inode_operations swapover_dir_inode_operations = {
> > > static struct dentry *sel_make_swapover_dir(struct super_block *sb,
> > > unsigned long *ino)
> > > {
> > > - struct dentry *dentry = d_alloc_name(sb->s_root, ".swapover");
> > > + struct dentry *dentry;
> > > struct inode *inode;
> > >
> > > - if (!dentry)
> > > + inode = sel_make_inode(sb, S_IFDIR);
> > > + if (!inode)
> > > return ERR_PTR(-ENOMEM);
> > >
> > > - inode = sel_make_inode(sb, S_IFDIR);
> > > - if (!inode) {
> > > - dput(dentry);
> > > + dentry = simple_start_creating(sb->s_root, ".swapover");
> > > + if (!dentry) {
> > > + iput(inode);
> > > return ERR_PTR(-ENOMEM);
> > > }
> >
> > Can this cause a kernel crash when simple_start_creating() fails?
> >
> > The function simple_start_creating() returns ERR_PTR on failure, not
> > NULL. The check `if (!dentry)` only catches NULL values. When
> > simple_start_creating() fails and returns an ERR_PTR value like
> > ERR_PTR(-ENOMEM), this value is non-NULL and the error check is bypassed.
> >
> > Execution would continue to d_make_persistent(dentry, inode), which
> > attempts to lock dentry->d_lock, dereferencing the ERR_PTR value and
> > causing a kernel crash.
> >
> > The old code used d_alloc_name() which returns NULL on error. The new
> > code uses simple_start_creating() which returns ERR_PTR on error, but
> > the error checking pattern wasn't updated to match.
> >
> > Should the check be `if (IS_ERR(dentry))` instead, and return dentry
> > rather than ERR_PTR(-ENOMEM) to preserve the actual error code?
>
> Good catch Chris, yes, please change this Neil and feel free to
> preserve my ACK.
Thanks.
I've made it
dentry = simple_start_creating(sb->s_root, ".swapover");
if (IS_ERR(dentry)) {
iput(inode);
return dentry;
}
NeilBrown
^ permalink raw reply
* Re: [PATCH v2 01/15] VFS: note error returns is documentation for various lookup functions
From: NeilBrown @ 2026-02-23 22:04 UTC (permalink / raw)
To: Chris Mason
Cc: Christian Brauner, Alexander Viro, David Howells, Jan Kara,
Chuck Lever, Jeff Layton, Miklos Szeredi, Amir Goldstein,
John Johansen, Paul Moore, James Morris, Serge E. Hallyn,
Stephen Smalley, Darrick J. Wong, linux-kernel, netfs,
linux-fsdevel, linux-nfs, linux-unionfs, apparmor,
linux-security-module, selinux
In-Reply-To: <20260223135517.1229434-1-clm@meta.com>
On Tue, 24 Feb 2026, Chris Mason wrote:
> NeilBrown <neilb@ownmail.net> wrote:
> > From: NeilBrown <neil@brown.name>
> >
> > Darrick recently noted that try_lookup_noperm() is documented as
> > "Look up a dentry by name in the dcache, returning NULL if it does not
> > currently exist." but it can in fact return an error.
> >
> > So update the documentation for that and related function.
> >
>
> Hi everyone,
>
> I don't normally forward the typos, but since this is a documentation-y patch:
I'm certainly happy to receive them. Thanks for these and the others
I also found ....
>
> commit 0254b9b974f23889898562aa94f6428bf30eb6b5
> Author: NeilBrown <neil@brown.name>
>
> VFS: note error returns is documentation for various lookup functions
> ^^^^^ in?
>
> Darrick recently noted that try_lookup_noperm() is documented as
> "Look up a dentry by name in the dcache, returning NULL if it does not
> currently exist." but it can in fact return an error. So update the
> documentation for that and related function.
^^functions
Thanks,
NeilBrown
^ permalink raw reply
* Re: [PATCH v4 15/17] module: Introduce hash-based integrity checking
From: Thomas Weißschuh @ 2026-02-23 21:43 UTC (permalink / raw)
To: Nicolas Schier, Nathan Chancellor, Arnd Bergmann,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Paul Moore, James Morris, Serge E. Hallyn, Jonathan Corbet,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Naveen N Rao, Mimi Zohar, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, Daniel Gomez, Aaron Tomlin,
Christophe Leroy (CS GROUP), Nicolas Bouchinet, Xiu Jianfeng,
Fabian Grünbichler, Arnout Engelen, Mattia Rizzolo, kpcyrd,
Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <aZyfcDCWOBJJztQ2@levanger>
On 2026-02-23 19:41:52+0100, Nicolas Schier wrote:
> On Mon, Feb 23, 2026 at 08:53:29AM +0100, Thomas Weißschuh wrote:
> > On 2026-02-21 22:38:29+0100, Nicolas Schier wrote:
> > > On Tue, Jan 13, 2026 at 01:28:59PM +0100, Thomas Weißschuh wrote:
> > > > The current signature-based module integrity checking has some drawbacks
> > > > in combination with reproducible builds. Either the module signing key
> > > > is generated at build time, which makes the build unreproducible, or a
> > > > static signing key is used, which precludes rebuilds by third parties
> > > > and makes the whole build and packaging process much more complicated.
> > > >
> > > > The goal is to reach bit-for-bit reproducibility. Excluding certain
> > > > parts of the build output from the reproducibility analysis would be
> > > > error-prone and force each downstream consumer to introduce new tooling.
> > > >
> > > > Introduce a new mechanism to ensure only well-known modules are loaded
> > > > by embedding a merkle tree root of all modules built as part of the full
> > > > kernel build into vmlinux.
> > > >
> > > > Non-builtin modules can be validated as before through signatures.
> > > >
> > > > Normally the .ko module files depend on a fully built vmlinux to be
> > > > available for modpost validation and BTF generation. With
> > > > CONFIG_MODULE_HASHES, vmlinux now depends on the modules
> > > > to build a merkle tree. This introduces a dependency cycle which is
> > > > impossible to satisfy. Work around this by building the modules during
> > > > link-vmlinux.sh, after vmlinux is complete enough for modpost and BTF
> > > > but before the final module hashes are
> > > >
> > > > The PKCS7 format which is used for regular module signatures can not
> > > > represent Merkle proofs, so a new kind of module signature is
> > > > introduced. As this signature type is only ever used for builtin
> > > > modules, no compatibility issues can arise.
> > > >
> > > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> > > > ---
> > > > .gitignore | 1 +
> > > > Documentation/kbuild/reproducible-builds.rst | 5 +-
> > > > Makefile | 8 +-
> > > > include/asm-generic/vmlinux.lds.h | 11 +
> > > > include/linux/module_hashes.h | 25 ++
> > > > include/linux/module_signature.h | 1 +
> > > > kernel/module/Kconfig | 21 +-
> > > > kernel/module/Makefile | 1 +
> > > > kernel/module/hashes.c | 92 ++++++
> > > > kernel/module/hashes_root.c | 6 +
> > > > kernel/module/internal.h | 1 +
> > > > kernel/module/main.c | 4 +-
> > > > scripts/.gitignore | 1 +
> > > > scripts/Makefile | 3 +
> > > > scripts/Makefile.modfinal | 11 +
> > > > scripts/Makefile.modinst | 13 +
> > > > scripts/Makefile.vmlinux | 5 +
> > > > scripts/link-vmlinux.sh | 14 +-
> > > > scripts/modules-merkle-tree.c | 467 +++++++++++++++++++++++++++
> > > > security/lockdown/Kconfig | 2 +-
> > > > 20 files changed, 685 insertions(+), 7 deletions(-)
> > > >
> > > [...]
> > >
> > > > diff --git a/kernel/module/hashes_root.c b/kernel/module/hashes_root.c
> > > > new file mode 100644
> > > > index 000000000000..1abfcd3aa679
> > > > --- /dev/null
> > > > +++ b/kernel/module/hashes_root.c
> > > > @@ -0,0 +1,6 @@
> > > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > > +
> > > > +#include <linux/module_hashes.h>
> > > > +
> > > > +/* Blank dummy data. Will be overridden by link-vmlinux.sh */
> > > > +const struct module_hashes_root module_hashes_root __module_hashes_section = {};
> > > > diff --git a/kernel/module/internal.h b/kernel/module/internal.h
> > > > index e2d49122c2a1..e22837d3ac76 100644
> > > > --- a/kernel/module/internal.h
> > > > +++ b/kernel/module/internal.h
> > > > @@ -338,6 +338,7 @@ void module_mark_ro_after_init(const Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
> > > > const char *secstrings);
> > > >
> > > > int module_sig_check(struct load_info *info, const u8 *sig, size_t sig_len);
> > > > +int module_hash_check(struct load_info *info, const u8 *sig, size_t sig_len);
> > > >
> > > > #ifdef CONFIG_DEBUG_KMEMLEAK
> > > > void kmemleak_load_module(const struct module *mod, const struct load_info *info);
> > > > diff --git a/kernel/module/main.c b/kernel/module/main.c
> > > > index 2a28a0ece809..fa30b6387936 100644
> > > > --- a/kernel/module/main.c
> > > > +++ b/kernel/module/main.c
> > > > @@ -3362,8 +3362,10 @@ static int module_integrity_check(struct load_info *info, int flags)
> > > >
> > > > if (IS_ENABLED(CONFIG_MODULE_SIG) && sig_type == PKEY_ID_PKCS7) {
> > > > err = module_sig_check(info, sig, sig_len);
> > > > + } else if (IS_ENABLED(CONFIG_MODULE_HASHES) && sig_type == PKEY_ID_MERKLE) {
> > > > + err = module_hash_check(info, sig, sig_len);
> > > > } else {
> > > > - pr_err("module: not signed with expected PKCS#7 message\n");
> > > > + pr_err("module: not signed with signature mechanism\n");
> > > > err = -ENOPKG;
> > >
> > > To prevent others from running into the same issue:
> > >
> > > My first test got stuck here, as I tested with virtme-ng, which symlinks
> > > modules from build tree to /lib/modules/$(uname -r)/..., resulting in
> > >
> > > [ 15.956855] module: not signed with signature mechanism
> > > modprobe: ERROR: could not insert 'efivarfs': Package not installed
> > >
> > > As the modules_install step was missing, modules were not being signed.
> >
> > Currently the signing is deferred to installation time to keep in sync
> > with regular module signing and to keep the logic simpler by not having
> > to gracefully handle previously-signed files.
> > But this could be changed.
>
> I did not want to suggest changing the behaviour, that would make things
> more complicated to prevent needless rebuilds. I just wanted to mention
> it here to prevent others from burning time.
Understood.
> > > [...]
> > > > diff --git a/scripts/modules-merkle-tree.c b/scripts/modules-merkle-tree.c
> > > > new file mode 100644
> > > > index 000000000000..a6ec0e21213b
> > > > --- /dev/null
> > > > +++ b/scripts/modules-merkle-tree.c
> > > > @@ -0,0 +1,467 @@
> > > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > > +/*
> > > > + * Compute hashes for modules files and build a merkle tree.
> > > > + *
> > > > + * Copyright (C) 2025 Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> > > > + * Copyright (C) 2025 Thomas Weißschuh <linux@weissschuh.net>
> > > > + *
> > > > + */
> > > > +#define _GNU_SOURCE 1
> > > > +#include <arpa/inet.h>
> > > > +#include <err.h>
> > > > +#include <unistd.h>
> > > > +#include <fcntl.h>
> > > > +#include <stdarg.h>
> > > > +#include <stdio.h>
> > > > +#include <string.h>
> > > > +#include <stdbool.h>
> > > > +#include <stdlib.h>
> > > > +
> > > > +#include <sys/stat.h>
> > > > +#include <sys/mman.h>
> > > > +
> > > > +#include <openssl/evp.h>
> > > > +#include <openssl/err.h>
> > > > +
> > > > +#include "ssl-common.h"
> > > > +
> > > > +static int hash_size;
> > > > +static EVP_MD_CTX *ctx;
> > > > +
> > > > +struct module_signature {
> > > > + uint8_t algo; /* Public-key crypto algorithm [0] */
> > > > + uint8_t hash; /* Digest algorithm [0] */
> > > > + uint8_t id_type; /* Key identifier type [PKEY_ID_PKCS7] */
> > > > + uint8_t signer_len; /* Length of signer's name [0] */
> > > > + uint8_t key_id_len; /* Length of key identifier [0] */
> > > > + uint8_t __pad[3];
> > > > + uint32_t sig_len; /* Length of signature data */
> > > > +};
> > > > +
> > > > +#define PKEY_ID_MERKLE 3
> > > > +
> > > > +static const char magic_number[] = "~Module signature appended~\n";
> > >
> > > This here will be the forth definition of struct module_signature,
> > > increasing the risk of unwanted diversion. I second Petr's suggestion
> > > to reuse a _common_ definition instead.
> >
> > Ack.
> >
> > > (Here, even include/linux/module_signature.h could be included itself.)
> >
> > I'd like to avoid including internal headers from other components.
> > We could move it to an UAPI header. Various other subsystems use those
> > for not-really-UAPI but still ABI definitions.
>
> Yeah, ack.
What exactly is the 'ack' for?
* Avoiding to include internal headers?
* Moving the definition to UAPI headers?
(...)
> > > Can you verify if I get the mechanics roughly correct?
> > >
> > > * Modules are merkle tree leaves. Modules are built and logically
> > > paired by the order from modules.order; a single left-over module is
> > > paired with itself.
> > >
> > > * Hashes of paired modules are hashed again (branch node hash);
> > > hashes of pairs of branch nodes' hashes are hashed again;
> > > repeat until we reach the single merkle tree root hash
> > >
> > > * The final merkle tree root hash (and the count of tree levels) is
> > > included in vmlinux
> >
> > The merkle tree code was written by Sebastian so he will have the best
> > knowledge about it. But this is also my understanding.
>
> I'd like to see some (rough) description in Documentation or in a commit
> message at least, otherwise future me will have to ask that again.
Ack in general. I'd prefer to document it in a source code comment,
though. That feels like the best fit to me.
Thomas
^ permalink raw reply
* Re: [PATCH v4 15/17] module: Introduce hash-based integrity checking
From: Nicolas Schier @ 2026-02-23 18:41 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <0d70db8d-702b-46ec-a010-298fe6515aab@t-8ch.de>
On Mon, Feb 23, 2026 at 08:53:29AM +0100, Thomas Weißschuh wrote:
> On 2026-02-21 22:38:29+0100, Nicolas Schier wrote:
> > On Tue, Jan 13, 2026 at 01:28:59PM +0100, Thomas Weißschuh wrote:
> > > The current signature-based module integrity checking has some drawbacks
> > > in combination with reproducible builds. Either the module signing key
> > > is generated at build time, which makes the build unreproducible, or a
> > > static signing key is used, which precludes rebuilds by third parties
> > > and makes the whole build and packaging process much more complicated.
> > >
> > > The goal is to reach bit-for-bit reproducibility. Excluding certain
> > > parts of the build output from the reproducibility analysis would be
> > > error-prone and force each downstream consumer to introduce new tooling.
> > >
> > > Introduce a new mechanism to ensure only well-known modules are loaded
> > > by embedding a merkle tree root of all modules built as part of the full
> > > kernel build into vmlinux.
> > >
> > > Non-builtin modules can be validated as before through signatures.
> > >
> > > Normally the .ko module files depend on a fully built vmlinux to be
> > > available for modpost validation and BTF generation. With
> > > CONFIG_MODULE_HASHES, vmlinux now depends on the modules
> > > to build a merkle tree. This introduces a dependency cycle which is
> > > impossible to satisfy. Work around this by building the modules during
> > > link-vmlinux.sh, after vmlinux is complete enough for modpost and BTF
> > > but before the final module hashes are
> > >
> > > The PKCS7 format which is used for regular module signatures can not
> > > represent Merkle proofs, so a new kind of module signature is
> > > introduced. As this signature type is only ever used for builtin
> > > modules, no compatibility issues can arise.
> > >
> > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> > > ---
> > > .gitignore | 1 +
> > > Documentation/kbuild/reproducible-builds.rst | 5 +-
> > > Makefile | 8 +-
> > > include/asm-generic/vmlinux.lds.h | 11 +
> > > include/linux/module_hashes.h | 25 ++
> > > include/linux/module_signature.h | 1 +
> > > kernel/module/Kconfig | 21 +-
> > > kernel/module/Makefile | 1 +
> > > kernel/module/hashes.c | 92 ++++++
> > > kernel/module/hashes_root.c | 6 +
> > > kernel/module/internal.h | 1 +
> > > kernel/module/main.c | 4 +-
> > > scripts/.gitignore | 1 +
> > > scripts/Makefile | 3 +
> > > scripts/Makefile.modfinal | 11 +
> > > scripts/Makefile.modinst | 13 +
> > > scripts/Makefile.vmlinux | 5 +
> > > scripts/link-vmlinux.sh | 14 +-
> > > scripts/modules-merkle-tree.c | 467 +++++++++++++++++++++++++++
> > > security/lockdown/Kconfig | 2 +-
> > > 20 files changed, 685 insertions(+), 7 deletions(-)
> > >
> > [...]
> >
> > > diff --git a/kernel/module/hashes_root.c b/kernel/module/hashes_root.c
> > > new file mode 100644
> > > index 000000000000..1abfcd3aa679
> > > --- /dev/null
> > > +++ b/kernel/module/hashes_root.c
> > > @@ -0,0 +1,6 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +
> > > +#include <linux/module_hashes.h>
> > > +
> > > +/* Blank dummy data. Will be overridden by link-vmlinux.sh */
> > > +const struct module_hashes_root module_hashes_root __module_hashes_section = {};
> > > diff --git a/kernel/module/internal.h b/kernel/module/internal.h
> > > index e2d49122c2a1..e22837d3ac76 100644
> > > --- a/kernel/module/internal.h
> > > +++ b/kernel/module/internal.h
> > > @@ -338,6 +338,7 @@ void module_mark_ro_after_init(const Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
> > > const char *secstrings);
> > >
> > > int module_sig_check(struct load_info *info, const u8 *sig, size_t sig_len);
> > > +int module_hash_check(struct load_info *info, const u8 *sig, size_t sig_len);
> > >
> > > #ifdef CONFIG_DEBUG_KMEMLEAK
> > > void kmemleak_load_module(const struct module *mod, const struct load_info *info);
> > > diff --git a/kernel/module/main.c b/kernel/module/main.c
> > > index 2a28a0ece809..fa30b6387936 100644
> > > --- a/kernel/module/main.c
> > > +++ b/kernel/module/main.c
> > > @@ -3362,8 +3362,10 @@ static int module_integrity_check(struct load_info *info, int flags)
> > >
> > > if (IS_ENABLED(CONFIG_MODULE_SIG) && sig_type == PKEY_ID_PKCS7) {
> > > err = module_sig_check(info, sig, sig_len);
> > > + } else if (IS_ENABLED(CONFIG_MODULE_HASHES) && sig_type == PKEY_ID_MERKLE) {
> > > + err = module_hash_check(info, sig, sig_len);
> > > } else {
> > > - pr_err("module: not signed with expected PKCS#7 message\n");
> > > + pr_err("module: not signed with signature mechanism\n");
> > > err = -ENOPKG;
> >
> > To prevent others from running into the same issue:
> >
> > My first test got stuck here, as I tested with virtme-ng, which symlinks
> > modules from build tree to /lib/modules/$(uname -r)/..., resulting in
> >
> > [ 15.956855] module: not signed with signature mechanism
> > modprobe: ERROR: could not insert 'efivarfs': Package not installed
> >
> > As the modules_install step was missing, modules were not being signed.
>
> Currently the signing is deferred to installation time to keep in sync
> with regular module signing and to keep the logic simpler by not having
> to gracefully handle previously-signed files.
> But this could be changed.
I did not want to suggest changing the behaviour, that would make things
more complicated to prevent needless rebuilds. I just wanted to mention
it here to prevent others from burning time.
> > [...]
> > > diff --git a/scripts/modules-merkle-tree.c b/scripts/modules-merkle-tree.c
> > > new file mode 100644
> > > index 000000000000..a6ec0e21213b
> > > --- /dev/null
> > > +++ b/scripts/modules-merkle-tree.c
> > > @@ -0,0 +1,467 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +/*
> > > + * Compute hashes for modules files and build a merkle tree.
> > > + *
> > > + * Copyright (C) 2025 Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> > > + * Copyright (C) 2025 Thomas Weißschuh <linux@weissschuh.net>
> > > + *
> > > + */
> > > +#define _GNU_SOURCE 1
> > > +#include <arpa/inet.h>
> > > +#include <err.h>
> > > +#include <unistd.h>
> > > +#include <fcntl.h>
> > > +#include <stdarg.h>
> > > +#include <stdio.h>
> > > +#include <string.h>
> > > +#include <stdbool.h>
> > > +#include <stdlib.h>
> > > +
> > > +#include <sys/stat.h>
> > > +#include <sys/mman.h>
> > > +
> > > +#include <openssl/evp.h>
> > > +#include <openssl/err.h>
> > > +
> > > +#include "ssl-common.h"
> > > +
> > > +static int hash_size;
> > > +static EVP_MD_CTX *ctx;
> > > +
> > > +struct module_signature {
> > > + uint8_t algo; /* Public-key crypto algorithm [0] */
> > > + uint8_t hash; /* Digest algorithm [0] */
> > > + uint8_t id_type; /* Key identifier type [PKEY_ID_PKCS7] */
> > > + uint8_t signer_len; /* Length of signer's name [0] */
> > > + uint8_t key_id_len; /* Length of key identifier [0] */
> > > + uint8_t __pad[3];
> > > + uint32_t sig_len; /* Length of signature data */
> > > +};
> > > +
> > > +#define PKEY_ID_MERKLE 3
> > > +
> > > +static const char magic_number[] = "~Module signature appended~\n";
> >
> > This here will be the forth definition of struct module_signature,
> > increasing the risk of unwanted diversion. I second Petr's suggestion
> > to reuse a _common_ definition instead.
>
> Ack.
>
> > (Here, even include/linux/module_signature.h could be included itself.)
>
> I'd like to avoid including internal headers from other components.
> We could move it to an UAPI header. Various other subsystems use those
> for not-really-UAPI but still ABI definitions.
Yeah, ack.
> (...)
>
> > > +static inline char *xasprintf(const char *fmt, ...)
> > > +{
> > > + va_list ap;
> > > + char *strp;
> > > + int ret;
> > > +
> > > + va_start(ap, fmt);
> > > + ret = vasprintf(&strp, fmt, ap);
> > > + va_end(ap);
> > > + if (ret == -1)
> > > + err(1, "Memory allocation failed");
> > > +
> > > + return strp;
> > > +}
> >
> > Please consider moving these x* functions into scripts/include/xalloc.h
> > for reuse. (I am sure someone else wrote this already, but I can't find
> > it...)
>
> Petr suggested it somewhere, it is done for the next revision.
>
> > thanks for all your efforts for reproducibility!
> >
> > As I have no clue about that: Is the patent for merkle trees [1] a
> > problem when integrating that here?
>
> That should have expired a long time ago [2].
> And fs-verity is also using merkle trees.
Great, thanks.
> > Can you verify if I get the mechanics roughly correct?
> >
> > * Modules are merkle tree leaves. Modules are built and logically
> > paired by the order from modules.order; a single left-over module is
> > paired with itself.
> >
> > * Hashes of paired modules are hashed again (branch node hash);
> > hashes of pairs of branch nodes' hashes are hashed again;
> > repeat until we reach the single merkle tree root hash
> >
> > * The final merkle tree root hash (and the count of tree levels) is
> > included in vmlinux
>
> The merkle tree code was written by Sebastian so he will have the best
> knowledge about it. But this is also my understanding.
I'd like to see some (rough) description in Documentation or in a commit
message at least, otherwise future me will have to ask that again.
> > 'make && find . -name '*.ko' -exec rm {} \; && make' does not rebuild
> > the in-tree modules. Shifting the module-hashes support from
> > scripts/link-vmlinux.sh to scripts/Makefile.vmlinux might (make it
> > easier) to fix this again.
>
> I'll take a look at it.
Thanks!
Kind regards,
Nicolas
> > [1]: https://worldwide.espacenet.com/patent/search/family/022107098/publication/US4309569A?q=pn%3DUS4309569
>
> [2] https://patents.stackexchange.com/questions/17901/validity-of-patent-on-merkle-trees
>
>
> Thomas
--
Nicolas
^ permalink raw reply
* Re: [PATCH v2 06/15] selinux: Use simple_start_creating() / simple_done_creating()
From: Paul Moore @ 2026-02-23 17:31 UTC (permalink / raw)
To: Chris Mason
Cc: NeilBrown, Christian Brauner, Alexander Viro, David Howells,
Jan Kara, Chuck Lever, Jeff Layton, Miklos Szeredi,
Amir Goldstein, John Johansen, James Morris, Serge E. Hallyn,
Stephen Smalley, Darrick J. Wong, linux-kernel, netfs,
linux-fsdevel, linux-nfs, linux-unionfs, apparmor,
linux-security-module, selinux
In-Reply-To: <20260223132533.136328-1-clm@meta.com>
On Mon, Feb 23, 2026 at 8:26 AM Chris Mason <clm@meta.com> wrote:
> NeilBrown <neilb@ownmail.net> wrote:
> > From: NeilBrown <neil@brown.name>
> >
> > Instead of explicitly locking the parent and performing a lookup in
> > selinux, use simple_start_creating(), and then use
> > simple_done_creating() to unlock.
> >
>
> Hi everyone,
>
> Amir suggested I run these through, and this commit was flagged:
>
> commit bc981629767980bbaee2ca3c7348b5a648665a9d
> Author: NeilBrown <neil@brown.name>
>
> selinux: Use simple_start_creating() / simple_done_creating()
>
> Instead of explicitly locking the parent and performing a lookup in
> selinux, use simple_start_creating(), and then use
> simple_done_creating() to unlock.
>
> This extends the region that the directory is locked for, and also
> performs a lookup. The lock extension is of no real consequence.
> The lookup uses simple_lookup() and so always succeeds. Thus when
> d_make_persistent() is called the dentry will already be hashed.
> d_make_persistent() handles this case.
>
> Reviewed-by: Jeff Layton <jlayton@kernel.org>
> Acked-by: Paul Moore <paul@paul-moore.com>
>
> > diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
> > index 3245cc531555b..7d4f90e5b12a0 100644
> > --- a/security/selinux/selinuxfs.c
> > +++ b/security/selinux/selinuxfs.c
> > @@ -1931,15 +1931,16 @@ static const struct inode_operations swapover_dir_inode_operations = {
> > static struct dentry *sel_make_swapover_dir(struct super_block *sb,
> > unsigned long *ino)
> > {
> > - struct dentry *dentry = d_alloc_name(sb->s_root, ".swapover");
> > + struct dentry *dentry;
> > struct inode *inode;
> >
> > - if (!dentry)
> > + inode = sel_make_inode(sb, S_IFDIR);
> > + if (!inode)
> > return ERR_PTR(-ENOMEM);
> >
> > - inode = sel_make_inode(sb, S_IFDIR);
> > - if (!inode) {
> > - dput(dentry);
> > + dentry = simple_start_creating(sb->s_root, ".swapover");
> > + if (!dentry) {
> > + iput(inode);
> > return ERR_PTR(-ENOMEM);
> > }
>
> Can this cause a kernel crash when simple_start_creating() fails?
>
> The function simple_start_creating() returns ERR_PTR on failure, not
> NULL. The check `if (!dentry)` only catches NULL values. When
> simple_start_creating() fails and returns an ERR_PTR value like
> ERR_PTR(-ENOMEM), this value is non-NULL and the error check is bypassed.
>
> Execution would continue to d_make_persistent(dentry, inode), which
> attempts to lock dentry->d_lock, dereferencing the ERR_PTR value and
> causing a kernel crash.
>
> The old code used d_alloc_name() which returns NULL on error. The new
> code uses simple_start_creating() which returns ERR_PTR on error, but
> the error checking pattern wasn't updated to match.
>
> Should the check be `if (IS_ERR(dentry))` instead, and return dentry
> rather than ERR_PTR(-ENOMEM) to preserve the actual error code?
Good catch Chris, yes, please change this Neil and feel free to preserve my ACK.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v6] lsm: Add LSM hook security_unix_find
From: Mickaël Salaün @ 2026-02-23 16:09 UTC (permalink / raw)
To: Justin Suess
Cc: Günther Noack, brauner, demiobenour, fahimitahera, hi, horms,
ivanov.mikhail1, jannh, jmorris, john.johansen,
konstantin.meskhidze, linux-security-module, m, matthieu, netdev,
paul, samasth.norway.ananda, serge, viro
In-Reply-To: <aZmxpoy1oxSl5yGq@suesslenovo>
On Sat, Feb 21, 2026 at 08:22:46AM -0500, Justin Suess wrote:
> On Fri, Feb 20, 2026 at 04:49:34PM +0100, Günther Noack wrote:
> > Hello!
> >
> > On Thu, Feb 19, 2026 at 03:04:59PM -0500, Justin Suess wrote:
> > > diff --git a/security/security.c b/security/security.c
> > > index 67af9228c4e9..c73196b8db4b 100644
> > > --- a/security/security.c
> > > +++ b/security/security.c
> > > @@ -4731,6 +4731,26 @@ int security_mptcp_add_subflow(struct sock *sk, struct sock *ssk)
> > >
> > > #endif /* CONFIG_SECURITY_NETWORK */
> > >
> > > +#if defined(CONFIG_SECURITY_NETWORK) && defined(CONFIG_SECURITY_PATH)
> > > +/**
> > > + * security_unix_find() - Check if a named AF_UNIX socket can connect
> > > + * @path: path of the socket being connected to
> > > + * @other: peer sock
> > > + * @flags: flags associated with the socket
> > > + *
> > > + * This hook is called to check permissions before connecting to a named
> > > + * AF_UNIX socket.
> >
> > Nit: Could we please insert a sentence about locking here?
> >
> > Something like:
> >
> > The caller holds no locks on @other.
> >
> > (Originally brought up by Mickaël in
> > https://lore.kernel.org/all/20260217.lievaS8eeng8@digikod.net/)
> >
> > Thanks,
> > –Günther
> Sounds good. Would a "Link:" to the mentioned thread be appropriate in the commit
> message?
Feel free to include relevant parts of our discussion in the commit
message, which would make a Link redundant. I think a Link is useful if
the commit message doesn't contain the whole context or misses
information, which is often the case wrt discussions or long emails.
>
> I feel like the reasoning for this is subtle but important for hook
> consumers.
Indeed. That should be explained in the hook comment.
>
> Justin
>
^ permalink raw reply
* Re: [syzbot] [kernel?] INFO: task hung in restrict_one_thread_callback
From: Günther Noack @ 2026-02-23 15:16 UTC (permalink / raw)
To: Ding Yihan
Cc: Günther Noack, syzbot, Mickaël Salaün,
linux-security-module, Jann Horn, Paul Moore
In-Reply-To: <32095877A7CB47CB+bb9e1be8-59c2-46d9-b1ef-f22d2d8c386e@uniontech.com>
Hello!
On Mon, Feb 23, 2026 at 07:29:56PM +0800, Ding Yihan wrote:
> Thank you for the detailed analysis and the clear breakdown.
> Apologies for the delayed response. I spent the last couple of days
> thoroughly reading through the previous mailing list discussions. I
> was trying hard to see if there was any viable pure lockless design
> that could solve this concurrency issue while preserving the original
> architecture.
>
> However, after looking at the complexities you outlined, I completely
> agree with your conclusion: serializing the TSYNC operations is indeed
> the most robust and reasonable path forward to prevent the deadlock.
>
> Regarding the lock choice, since 'cred_guard_mutex' is explicitly
> marked as deprecated for new code in the kernel,maybe we can use its
> modern replacement: 'exec_update_lock' (using down_write_trylock /
> up_write on current->signal). This aligns with the current subsystem
> standards and was also briefly touched upon by Jann in the older
> discussions.
>
> I fully understand the requirement for the two-part patch series:
> 1. Cleaning up the cancellation logic and comments.
> 2. Introducing the serialization lock for TSYNC.
>
> I will take some time to draft and test this patch series properly.
> I also plan to discuss this with my kernel colleagues here at
> UnionTech to see if they have any additional suggestions on the
> implementation details before I submit it.
>
> I will send out the v1 patch series to the list as soon as it is
> ready. Thanks again for your guidance and the great discussion!
Thank you, Ding, this is much appreciated!
I agree, the `exec_update_lock` might be the better solution;
I also need to familiarize myself more with it to double-check.
—Günther
^ permalink raw reply
* Re: [syzbot] [kernel?] INFO: task hung in restrict_one_thread_callback
From: Günther Noack @ 2026-02-23 15:15 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: syzbot, Mickaël Salaün, Paul Moore, James Morris,
Serge E. Hallyn, linux-security-module, anna-maria, linux-kernel,
syzkaller-bugs, tglx
In-Reply-To: <aZxYv7MxxExj9fjM@localhost.localdomain>
On Mon, Feb 23, 2026 at 02:40:15PM +0100, Frederic Weisbecker wrote:
> Le Fri, Feb 20, 2026 at 03:11:21AM -0800, syzbot a écrit :
> > Call Trace:
> > <TASK>
> > context_switch kernel/sched/core.c:5295 [inline]
> > __schedule+0x1585/0x5340 kernel/sched/core.c:6907
> > __schedule_loop kernel/sched/core.c:6989 [inline]
> > schedule+0x164/0x360 kernel/sched/core.c:7004
> > schedule_timeout+0xc3/0x2c0 kernel/time/sleep_timeout.c:75
> > do_wait_for_common kernel/sched/completion.c:100 [inline]
> > __wait_for_common kernel/sched/completion.c:121 [inline]
> > wait_for_common kernel/sched/completion.c:132 [inline]
> > wait_for_completion+0x2cc/0x5e0 kernel/sched/completion.c:153
> > restrict_one_thread security/landlock/tsync.c:128 [inline]
> > restrict_one_thread_callback+0x320/0x570 security/landlock/tsync.c:162
>
> Seems to be related to landlock security module.
> Cc'ing maintainers for awareness.
Thank you! That is correct. We are already discussing it in
https://lore.kernel.org/all/00A9E53EDC82309F+7b1dfc69-95f8-4ffc-a67c-967de0e2dfee@uniontech.com/
—Günther
^ permalink raw reply
* Re: [PATCH v15 9/9] rust: page: add `from_raw()`
From: Andreas Hindborg @ 2026-02-23 15:00 UTC (permalink / raw)
To: Miguel Ojeda, Tamir Duberstein, Benno Lossin
Cc: Miguel Ojeda, Gary Guo, Björn Roy Baron, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
Rafael J. Wysocki, David Airlie, Simona Vetter, Alexander Viro,
Christian Brauner, Jan Kara, Igor Korotin, Daniel Almeida,
Lorenzo Stoakes, Liam R. Howlett, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Bjorn Helgaas, Krzysztof Wilczyński,
Boqun Feng, linux-kernel, rust-for-linux, linux-block,
linux-security-module, dri-devel, linux-fsdevel, linux-mm,
linux-pm, linux-pci
In-Reply-To: <CANiq72myc+tCEHm0WtZspZHWwsSzvesxsmUvk31=GCdUN_zVNA@mail.gmail.com>
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> writes:
> On Fri, Feb 20, 2026 at 10:52 AM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>>
>> + /// Create a `&Page` from a raw `struct page` pointer
>
> Please end sentences with a period.
Ok.
>
>> + // SAFETY: By function safety requirements, ptr is not null and is
>
> Please use Markdown in comments: `ptr`.
Ok.
>
>> + /// `ptr` must be valid for use as a reference for the duration of `'a`.
>
> Since we will likely try to starting introducing at least a subset of
> the Safety Standard soon, we should try to use standard terms.
>
> So I think this "valid for use as a reference" is not an established
> one, no? Isn't "convertible to a shared reference" the official term?
>
> https://doc.rust-lang.org/std/ptr/index.html#pointer-to-reference-conversion
>
> In fact, I see `as_ref_unchecked()` and `as_mut_unchecked()` just got
> stabilized for 1.95.0, so we should probably starting using those were
> applicable as we bump the minimum, but we should probably use already
> a similar wording as the standard library for the safety section and
> the comment:
>
> "`ptr` must be [convertible to a reference](...)."
I'll change the wording to the "convertible" one.
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v15 1/9] rust: types: Add Ownable/Owned types
From: Andreas Hindborg @ 2026-02-23 14:59 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
Rafael J. Wysocki, David Airlie, Simona Vetter, Alexander Viro,
Christian Brauner, Jan Kara, Igor Korotin, Daniel Almeida,
Lorenzo Stoakes, Liam R. Howlett, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Bjorn Helgaas, Krzysztof Wilczyński,
Boqun Feng, linux-kernel, rust-for-linux, linux-block,
linux-security-module, dri-devel, linux-fsdevel, linux-mm,
linux-pm, linux-pci, Asahi Lina, Oliver Mangold
In-Reply-To: <aZg44EmMWKK-z5KP@google.com>
Alice Ryhl <aliceryhl@google.com> writes:
> On Fri, Feb 20, 2026 at 10:51:10AM +0100, Andreas Hindborg wrote:
>> From: Asahi Lina <lina+kernel@asahilina.net>
>>
>> By analogy to `AlwaysRefCounted` and `ARef`, an `Ownable` type is a
>> (typically C FFI) type that *may* be owned by Rust, but need not be. Unlike
>> `AlwaysRefCounted`, this mechanism expects the reference to be unique
>> within Rust, and does not allow cloning.
>>
>> Conceptually, this is similar to a `KBox<T>`, except that it delegates
>> resource management to the `T` instead of using a generic allocator.
>>
>> [ om:
>> - Split code into separate file and `pub use` it from types.rs.
>> - Make from_raw() and into_raw() public.
>> - Remove OwnableMut, and make DerefMut dependent on Unpin instead.
>> - Usage example/doctest for Ownable/Owned.
>> - Fixes to documentation and commit message.
>> ]
>>
>> Link: https://lore.kernel.org/all/20250202-rust-page-v1-1-e3170d7fe55e@asahilina.net/
>> Signed-off-by: Asahi Lina <lina+kernel@asahilina.net>
>> Co-developed-by: Oliver Mangold <oliver.mangold@pm.me>
>> Signed-off-by: Oliver Mangold <oliver.mangold@pm.me>
>> Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
>> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
>> [ Andreas: Updated documentation, examples, and formatting ]
>> Reviewed-by: Gary Guo <gary@garyguo.net>
>> Co-developed-by: Andreas Hindborg <a.hindborg@kernel.org>
>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>
>> +/// let result = NonNull::new(KBox::into_raw(result))
>> +/// .expect("Raw pointer to newly allocation KBox is null, this should never happen.");
>
> KBox should probably have an into_raw_nonnull().
I can add that.
>
>> +/// let foo = Foo::new().expect("Failed to allocate a Foo. This shouldn't happen");
>> +/// assert!(*FOO_ALLOC_COUNT.lock() == 1);
>
> Use ? here.
Ok.
>
>> +/// }
>> +/// // `foo` is out of scope now, so we expect no live allocations.
>> +/// assert!(*FOO_ALLOC_COUNT.lock() == 0);
>> +/// ```
>> +pub unsafe trait Ownable {
>> + /// Releases the object.
>> + ///
>> + /// # Safety
>> + ///
>> + /// Callers must ensure that:
>> + /// - `this` points to a valid `Self`.
>> + /// - `*this` is no longer used after this call.
>> + unsafe fn release(this: NonNull<Self>);
>
> Honestly, not using it after this call may be too strong. I can imagine
> wanting a value where I have both an ARef<_> and Owned<_> reference to
> something similar to the existing Arc<_>/ListArc<_> pattern, and in that
> case the value may in fact be accessed after this call if you still have
> an ARef<_>.
I do not understand your use case.
You are not supposed to have both an `ARef` and an `Owned` at the same
time. The `Owned` is to `ARef` what `UniqueArc` is to `Arc`. It is
supposed to be unique and no `ARef` can be live while the `Owned` is
live.
A `ListArc` is "at most one per list link" and it takes a refcount on
the object by owning an `Arc`. As far as I recall, it does not provide
mutable access to anything but the list link. To me, that is a very
different situation.
>
> If you modify Owned<_> invariants and Owned::from_raw() safety
> requirements along the lines of what I say below, then this could just
> say that the caller must have permission to call this function. The
> concrete implementer can specify what that means more directly, but here
> all it means is that a prior call to Owned::from_raw() promised to give
> you permission to call it.
I don't think we need the "permission" wording. How about this:
/// A mutable reference to an owned `T`.
///
/// The [`Ownable`] is automatically freed or released when an instance of [`Owned`] is
/// dropped.
///
/// # Invariants
///
/// - Until `T::release` is called, this `Owned<T>` exclusively owns the underlying `T`.
/// - The `T` value is pinned.
pub struct Owned<T: Ownable> {...}
impl<T: Ownable> Owned<T> {
/// Creates a new instance of [`Owned`].
///
/// This function takes over ownership of the underlying object.
///
/// # Safety
///
/// Callers must ensure that:
/// - `ptr` points to a valid instance of `T`.
/// - Until `T::release` is called, the returned `Owned<T>` exclusively owns the underlying `T`.
pub unsafe fn from_raw(ptr: NonNull<T>) -> Self {...}
}
pub trait Ownable {
/// Tear down this `Ownable`.
///
/// Implementers of `Ownable` can use this function to clean up the use of `Self`. This can
/// include freeing the underlying object.
///
/// # Safety
///
/// Callers must ensure that the caller has exclusive ownership of `T`, and this ownership can
/// be transferred to the `release` method.
unsafe fn release(&mut self);
}
Note `Ownable` not being an unsafe trait.
>
>> +/// A mutable reference to an owned `T`.
>> +///
>> +/// The [`Ownable`] is automatically freed or released when an instance of [`Owned`] is
>> +/// dropped.
>> +///
>> +/// # Invariants
>> +///
>> +/// - The [`Owned<T>`] has exclusive access to the instance of `T`.
>> +/// - The instance of `T` will stay alive at least as long as the [`Owned<T>`] is alive.
>> +pub struct Owned<T: Ownable> {
>> + ptr: NonNull<T>,
>> +}
>
> I think some more direct and less fuzzy invariants would be:
>
> - This `Owned<T>` holds permissions to call `T::release()` on the value once.
> - Until `T::release()` is called, this `Owned<T>` may perform mutable access on the `T`.
I do not like the wording for mutable access. Formulating safety
requirements for `from_raw` and safety comments for that function
becomes convoluted like this. I'd rather formulate the
access capability in terms of ownership;
- Until `T::release()` is called, this `Owned<T>` exclusively owns the
underlying `T`.
How is that?
> - The `T` value is pinned.
I am unsure about the pinning terminology. If we say that `T` is pinned,
does this mean that it will never move, even if `T: Unpin`? Or is it
implied that `T` may move if it is `Unpin`?
>
>> + /// Get a pinned mutable reference to the data owned by this `Owned<T>`.
>> + pub fn as_pin_mut(&mut self) -> Pin<&mut T> {
>> + // SAFETY: The type invariants guarantee that the object is valid, and that we can safely
>> + // return a mutable reference to it.
>> + let unpinned = unsafe { self.ptr.as_mut() };
>> +
>> + // SAFETY: We never hand out unpinned mutable references to the data in
>> + // `Self`, unless the contained type is `Unpin`.
>> + unsafe { Pin::new_unchecked(unpinned) }
>
> I'd prefer if "pinned" was a type invariant, rather than make an
> argument about what kind of APIs exist.
Ok.
>
>> +impl<T: Ownable + Unpin> DerefMut for Owned<T> {
>> + fn deref_mut(&mut self) -> &mut Self::Target {
>> + // SAFETY: The type invariants guarantee that the object is valid, and that we can safely
>> + // return a mutable reference to it.
>> + unsafe { self.ptr.as_mut() }
>
> Surely this safety comment should say something about pinning.
Yes.
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v15 9/9] rust: page: add `from_raw()`
From: Andreas Hindborg @ 2026-02-23 14:59 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
Rafael J. Wysocki, David Airlie, Simona Vetter, Alexander Viro,
Christian Brauner, Jan Kara, Igor Korotin, Daniel Almeida,
Lorenzo Stoakes, Liam R. Howlett, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Bjorn Helgaas, Krzysztof Wilczyński,
Boqun Feng, linux-kernel, rust-for-linux, linux-block,
linux-security-module, dri-devel, linux-fsdevel, linux-mm,
linux-pm, linux-pci
In-Reply-To: <CAH5fLggNQD+TbA7rXVB5w+O+qHcJcYC4u0b3W+mHR2DZiUe4eQ@mail.gmail.com>
Alice Ryhl <aliceryhl@google.com> writes:
> On Fri, Feb 20, 2026 at 10:52 AM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>>
>> Add a method to `Page` that allows construction of an instance from `struct
>> page` pointer.
>>
>> Signed-off-by: Andreas Hindborg <a.hindborg@samsung.com>
>> ---
>> rust/kernel/page.rs | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/rust/kernel/page.rs b/rust/kernel/page.rs
>> index 4591b7b01c3d2..803f3e3d76b22 100644
>> --- a/rust/kernel/page.rs
>> +++ b/rust/kernel/page.rs
>> @@ -191,6 +191,17 @@ pub fn nid(&self) -> i32 {
>> unsafe { bindings::page_to_nid(self.as_ptr()) }
>> }
>>
>> + /// Create a `&Page` from a raw `struct page` pointer
>> + ///
>> + /// # Safety
>> + ///
>> + /// `ptr` must be valid for use as a reference for the duration of `'a`.
>> + pub unsafe fn from_raw<'a>(ptr: *const bindings::page) -> &'a Self {
>> + // SAFETY: By function safety requirements, ptr is not null and is
>> + // valid for use as a reference.
>> + unsafe { &*Opaque::cast_from(ptr).cast::<Self>() }
>
> If you're going to do a pointer cast, then keep it simple and just do
> &*ptr.cast().
Ok.
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v15 3/9] rust: Add missing SAFETY documentation for `ARef` example
From: Andreas Hindborg @ 2026-02-23 14:59 UTC (permalink / raw)
To: Alice Ryhl
Cc: Miguel Ojeda, Gary Guo, Björn Roy Baron, Benno Lossin,
Trevor Gross, Danilo Krummrich, Greg Kroah-Hartman, Dave Ertman,
Ira Weiny, Leon Romanovsky, Paul Moore, Serge Hallyn,
Rafael J. Wysocki, David Airlie, Simona Vetter, Alexander Viro,
Christian Brauner, Jan Kara, Igor Korotin, Daniel Almeida,
Lorenzo Stoakes, Liam R. Howlett, Viresh Kumar, Nishanth Menon,
Stephen Boyd, Bjorn Helgaas, Krzysztof Wilczyński,
Boqun Feng, linux-kernel, rust-for-linux, linux-block,
linux-security-module, dri-devel, linux-fsdevel, linux-mm,
linux-pm, linux-pci, Oliver Mangold
In-Reply-To: <CAH5fLggNjCZ3AvHnhO8O0cmd33B3zMbfq+hhNvonznTsLLtgYw@mail.gmail.com>
Alice Ryhl <aliceryhl@google.com> writes:
> On Fri, Feb 20, 2026 at 10:52 AM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>>
>> From: Oliver Mangold <oliver.mangold@pm.me>
>>
>> SAFETY comment in rustdoc example was just 'TODO'. Fixed.
>>
>> Signed-off-by: Oliver Mangold <oliver.mangold@pm.me>
>> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
>> Co-developed-by: Andreas Hindborg <a.hindborg@kernel.org>
>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>> ---
>> rust/kernel/sync/aref.rs | 10 ++++++----
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/rust/kernel/sync/aref.rs b/rust/kernel/sync/aref.rs
>> index 61caddfd89619..efe16a7fdfa5d 100644
>> --- a/rust/kernel/sync/aref.rs
>> +++ b/rust/kernel/sync/aref.rs
>> @@ -129,12 +129,14 @@ pub unsafe fn from_raw(ptr: NonNull<T>) -> Self {
>> /// # Examples
>> ///
>> /// ```
>> - /// use core::ptr::NonNull;
>> - /// use kernel::sync::aref::{ARef, RefCounted};
>> + /// # use core::ptr::NonNull;
>> + /// # use kernel::sync::aref::{ARef, RefCounted};
>> ///
>
> Either keep the imports visible or delete this empty line. And either
> way, it doesn't really fit in this commit.
I'll drop this for this commit.
Best regards,
Andreas Hindborg
^ 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