Re: [PATCH v6 mm-new 04/10] bpf: mark vma->vm_mm as trusted

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Aug 31, 2025 at 11:16:27AM +0800, Yafang Shao wrote:
> On Fri, Aug 29, 2025 at 6:49 PM Lorenzo Stoakes
> <lorenzo.stoakes@xxxxxxxxxx> wrote:
> >
> > On Fri, Aug 29, 2025 at 11:05:01AM +0800, Yafang Shao wrote:
> > > On Thu, Aug 28, 2025 at 7:11 PM Lorenzo Stoakes
> > > <lorenzo.stoakes@xxxxxxxxxx> wrote:
> > > >
> > > > On Thu, Aug 28, 2025 at 02:12:12PM +0800, Yafang Shao wrote:
> > > > > On Wed, Aug 27, 2025 at 11:46 PM Lorenzo Stoakes
> > > > > <lorenzo.stoakes@xxxxxxxxxx> wrote:
> > > > > >
> > > > > > On Tue, Aug 26, 2025 at 03:19:42PM +0800, Yafang Shao wrote:
> > > > > > > Every VMA must have an associated mm_struct, and it is safe to access
> > > > > >
> > > > > > Err this isn't true? Pretty sure special VMAs don't have that set.
> > > > >
> > > > > I’m not aware of any VMA that doesn’t belong to an mm_struct. If there
> > > > > is such a case, it would be helpful if you could point it out. In any
> > > > > case, I’ll remove the VMA-related code in the next version since it’s
> > > > > unnecessary.
> > > >
> > > > If you lok at get_vma_name() in fs/proc/task_mmu.c you'll see:
> > > >
> > > >         if (!vma->vm_mm) {
> > > >                 *name = "[vdso]";
> > > >                 return;
> > > >         }
> > > >
> > > > So a VDSO will have this condition.
> > > >
> > > > I did a quick drgn()/printk() test and didn't see any, but maybe my system - but
> > > > in any case this appears to be a valid situation that can arise, presumably
> > > > because it's a VMA somehow shared with multiple mm's or something truly god
> > > > awful like that :)
> > >
> > > Thanks for clarifying that.
> >
> > No problem! These weird edge cases are... weird and hugely confusing. I should
> > document some of this somewhere, as it's at the moment more 'oh yeah I
> > remember...' then having to dig through to figure it out.
> >
> > The "/dev/zero file-backed but actually anon if MAP_PRIVATE'd" is another fun
> > unique case.
>
> It would be immensely helpful if you could document these cases. We
> truly appreciate your contribution and the time you've invested in
> this.

Sure I will add to my TODOs :) I agree it's not great that we have these odd
edge cases and do not document them clearly enough.

Will get to it :)

>
> --
> Regards
> Yafang

Thanks, Lorenzo




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux