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.
>
> --
> Regards
> Yafang
