linux-kernel - Re: [PATCH RFC v3 12/13] mm: add SLAB_TYPESAFE_BY_RCU to files

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEf4BzaapUJVEwGxcmE7BBUZj2C9rrh5J3nQ8TV978mntZKu1g@mail.gmail.com>
Date: Tue, 13 Aug 2024 11:15:47 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: Mateusz Guzik <mjguzik@...il.com>, Andrii Nakryiko <andrii@...nel.org>, 
	linux-trace-kernel@...r.kernel.org, peterz@...radead.org, oleg@...hat.com, 
	rostedt@...dmis.org, mhiramat@...nel.org, bpf@...r.kernel.org, 
	linux-kernel@...r.kernel.org, jolsa@...nel.org, paulmck@...nel.org, 
	willy@...radead.org, akpm@...ux-foundation.org, linux-mm@...ck.org
Subject: Re: [PATCH RFC v3 12/13] mm: add SLAB_TYPESAFE_BY_RCU to files_cache

On Tue, Aug 13, 2024 at 7:49 AM Suren Baghdasaryan <surenb@...gle.com> wrote:
>
> On Mon, Aug 12, 2024 at 11:07 PM Mateusz Guzik <mjguzik@...il.com> wrote:
> >
> > On Mon, Aug 12, 2024 at 09:29:16PM -0700, Andrii Nakryiko wrote:
> > > Add RCU protection for file struct's backing memory by adding
> > > SLAB_TYPESAFE_BY_RCU flag to files_cachep. This will allow to locklessly
> > > access struct file's fields under RCU lock protection without having to
> > > take much more expensive and contended locks.
> > >
> > > This is going to be used for lockless uprobe look up in the next patch.
> > >
> > > Suggested-by: Matthew Wilcox <willy@...radead.org>
> > > Signed-off-by: Andrii Nakryiko <andrii@...nel.org>
> > > ---
> > >  kernel/fork.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/kernel/fork.c b/kernel/fork.c
> > > index 76ebafb956a6..91ecc32a491c 100644
> > > --- a/kernel/fork.c
> > > +++ b/kernel/fork.c
> > > @@ -3157,8 +3157,8 @@ void __init proc_caches_init(void)
> > >                       NULL);
> > >       files_cachep = kmem_cache_create("files_cache",
> > >                       sizeof(struct files_struct), 0,
> > > -                     SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT,
> > > -                     NULL);
> > > +                     SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_TYPESAFE_BY_RCU|
> > > +                     SLAB_ACCOUNT, NULL);
> > >       fs_cachep = kmem_cache_create("fs_cache",
> > >                       sizeof(struct fs_struct), 0,
> > >                       SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_ACCOUNT,
> >
> > Did you mean to add it to the cache backing 'struct file' allocations?

Yep, thanks for catching this!

> >
> > That cache is created in fs/file_table.c and already has the flag:
> >         filp_cachep = kmem_cache_create("filp", sizeof(struct file), 0,
> >                                 SLAB_TYPESAFE_BY_RCU | SLAB_HWCACHE_ALIGN |
> >                                 SLAB_PANIC | SLAB_ACCOUNT, NULL);
>
> Oh, I completely missed the SLAB_TYPESAFE_BY_RCU for this cache, and
> here I was telling Andrii that it's RCU unsafe to access
> vma->vm_file... Mea culpa.
>

Well, my bad for not double-checking and going just by the name.
filp_cachep vs files_cachep is easy to mix up.

> >
> > The cache you are modifying in this patch contains the fd array et al
> > and is of no consequence to "uprobes: add speculative lockless VMA to
> > inode resolution".
> >
> > iow this patch needs to be dropped
>
> I believe you are correct.
>

I'm happy that we already have SLAB_TYPESAFE_BY_RCU on filp_cachep,
I'll just drop this patch.