Re: [PATCH v3 01/40] mm/vma: fix mmap_prepare file handling, remove file_doesnt_need_get

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Thu, Sep 24, 2026 at 12:28:39PM -0400, Gregory Price wrote:
> On Thu, Sep 17, 2026 at 05:22:10PM +0100, Lorenzo Stoakes (ARM) wrote:
> > +static void put_map(struct mmap_state *map)
> > +{
> ...
> > +	if (map->vm_file && !map_same_file(map))
> > +		fput(map->vm_file);
> ...
> > diff --git a/mm/vma.h b/mm/vma.h
> > index e97bd2dfa786..f15faa83f3d6 100644
> > --- a/mm/vma.h
> > +++ b/mm/vma.h
> > @@ -394,8 +394,10 @@ static inline void compat_set_vma_from_desc(struct vm_area_struct *vma,
> >
> > +	if (desc->vm_file != vma->vm_file) {
> > +		fput(vma->vm_file);
>
>
> Sashiko pointed out that this could be null if the vma is "anonymized".

Sashiko is wrong :) I wish I could mark responses like that so it didn't
regenerate them on each respin.

(I always run sashiko output received for each series through a frontier
LLM anyway + fix stuff that is real, see the changelog for series for those
things that were valid)

You can't reach this code without a vma->vm_file.

>
> Previously we'd discussed that anonymizing a file folio is more of a
> wart than a feature, and IIRC you intended to remove that (i think?)
> when you removed zero-file mapping "anonymization" so some of this VMA
> stuff could be detangled.

The anonymising as existed before clears vma->vm_ops not vma->vm_file.

The new _actual_ anonymisation for MAP_PRIVATE-/dev/zero clears
vma->vm_file but only on the raw mmap_prepare non-compat path, stacked
MAP_PRIVATE-/dev/zero is not supported as a means of getting anonymous
memory (and would be a really strange thing to do anyway).

(In general stacked file systems only operate on regular files anyway).

>
> If this is an intermediate state, do we still need to manage this NULL
> scenario, and when we drop the anonymization mechanism we add a WARN()
> that says someone is being naughty?

Nope not at all.

No code path can get here with NULL vm_file and it's already the case that
a driver setting the wrong thing NULL could trigger a NULL pointer deref
anyway.

Nothing in-tree does anything like this and out of tree drivers can trigger
stuff if they want but it's not for us to worry about (they already can do
that locally :P) :)

>
> ~Gregory

--
Cheers, Lorenzo