On Fri, Sep 12, 2025 at 1:44 AM Lorenzo Stoakes
<lorenzo.stoakes@xxxxxxxxxx> wrote:
>
> On Thu, Sep 11, 2025 at 01:30:52PM -0400, Liam R. Howlett wrote:
> > * Yafang Shao <laoar.shao@xxxxxxxxx> [250909 22:46]:
> > > The vma->vm_mm might be NULL and it can be accessed outside of RCU. Thus,
> > > we can mark it as trusted_or_null. With this change, BPF helpers can safely
> > > access vma->vm_mm to retrieve the associated mm_struct from the VMA.
> > > Then we can make policy decision from the VMA.
> >
> > I don't agree with any of that statement.
> >
> > How are you getting a vma outside an rcu lock safely?
>
> I'm guessing he means that kernel code might access it outside of RCU?
>
> vma->vm_mm can be NULL for 'special' mappings, no not that special, not the
> other special, the VDSO special, yeah that one.
>
> get_vma_name() in fs/proc/task_mmu.c does:
>
> if (!vma->vm_mm) {
> *name = "[vdso]";
> return;
> }
>
> Not sure you'd ever find a way to bump into that in THP code paths though ofc.
>
> I was reassured in the last version of the series that the MM is definitely safe
> to access safe to access
>
> E.g. https://lore.kernel.org/linux-mm/299e12dc-259b-45c2-8662-2f3863479939@lucifer.local/
> https://lore.kernel.org/linux-mm/5fb8bd8d-cdd9-42e0-b62d-eb5a517a35c2@lucifer.local/
>
> And it _seems_ BPF can already access VMA's.
>
> I think everything's under RCU, and there's automatically an RCU lock applied
> for anything BPF-ish.
This is true for non-sleepable BPF programs. However, for sleepable
BPF programs, only SRCU protection is held.
>
> So my A-b was all baed on this kind of hand waving...
>
> >
> > vmas are RCU type safe so I don't think you can make the statement of
> > null or trusted. You can get a vma that has moved to another mm if you
> > are not careful.
> >
> > What am I missing? Surely there is more context to add to this commit
> > message.
>
> Suspect it's the BPF-magic that's the confusing bit...
Absolutely. BPF has a lot of magic under the hood ;-)
--
Regards
Yafang
