Re: [PATCH v2] mm/vma: keep the unlinked VMA off the file across unmap on mmap hook failure

Re: [PATCH v2] mm/vma: keep the unlinked VMA off the file across unmap on mmap hook failure

[Ihor Solodrai]

On 10/7/26 12:47 PM, Oleg Keri wrote:
> Since commit 2ceb21171dd9 ("mm: consistently validate VMA state after
> mmap[_prepare] hooks"), the mmap error path clears vma->vm_file only
> after unmap_region(), so free_pgtables() unlinks the never-linked VMA
> and drops i_mmap_writable. Once it goes negative, every later shared
> writable mmap of that file fails with -EPERM until reboot.
> 
> Clear vm_file across unmap_region() only, so that free_pgtables() does
> not unlink a VMA that was never linked to the file, and restore it for
> vma_close(): when the hook succeeded and the validation failed, the
> driver's close() still runs and may use vma->vm_file.
> 
> Fixes: 2ceb21171dd9 ("mm: consistently validate VMA state after mmap[_prepare] hooks")
> Signed-off-by: Oleg Keri <okerixx@gmail.com>

Tested-by: Ihor Solodrai <ihor.solodrai@linux.dev>

BPF CI caught this bug on linux-next as well:
https://github.com/kernel-patches/bpf/actions/runs/37736351874

The patch fixes it:
https://github.com/kernel-patches/bpf/actions/runs/37829434215


> ---
> v2: keep vm_file for vma_close(): with the hook succeeded and the
> validation failed the driver's close() still runs. Reported by Sashiko
> via Andrew.
> 
> Seen on next-20261006: one refused PCM mmap probe from alsa-lib left the
> device unmappable, so PipeWire could not play anything.
> 
>  mm/vma.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/mm/vma.c b/mm/vma.c
> index dfa45c64222c..531e4f53fdd7 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -2616,12 +2616,15 @@ static int __mmap_new_file_vma(struct mmap_state *map,
>  	map->vm_file = vma->vm_file;
>  
>  	if (error) {
> +		struct file *file = vma->vm_file;
>  		UNMAP_STATE(unmap, vmi, vma, vma->vm_start, vma->vm_end,
>  			    map->prev, map->next);
>  
> +		vma->vm_file = NULL;
>  		vma_iter_set(vmi, vma->vm_end);
>  		/* Undo any partial mapping done by a device driver. */
>  		unmap_region(&unmap);
> +		vma->vm_file = file;
>  		/* Only safe once unmapped. */
>  		vma_close(vma);
>  

Re: [PATCH v2] mm/vma: keep the unlinked VMA off the file across unmap on mmap hook failure

[Lorenzo Stoakes (ARM)]

-cc slopper

On Thu, Oct 08, 2026 at 02:48:07PM -0700, Ihor Solodrai wrote:
> BPF CI caught this bug on linux-next as well:
> https://github.com/kernel-patches/bpf/actions/runs/37736351874

Nice that it caught it!

Is there a way to automatically notify patch author that when it happens? Does
it bisect, etc. or just green/red?

--
Cheers, Lorenzo

Re: [PATCH v2] mm/vma: keep the unlinked VMA off the file across unmap on mmap hook failure

[Ihor Solodrai]

On 2026-10-09 4:31 a.m., Lorenzo Stoakes (ARM) wrote:
> -cc slopper
> 
> On Thu, Oct 08, 2026 at 02:48:07PM -0700, Ihor Solodrai wrote:
>> BPF CI caught this bug on linux-next as well:
>> https://github.com/kernel-patches/bpf/actions/runs/37736351874
> 
> Nice that it caught it!
> 
> Is there a way to automatically notify patch author that when it happens? Does
> it bisect, etc. or just green/red?

For linux-next it's just green/red now.

We've added it to have an "upstream merge will break bpf" signal,
because it happened regularly.

For bpf list we run on every incoming patch, so regressions are detected
quickly. Not feasible to do that for *every* upstream patch, we'd need
much more compute.

An auto-bisection is something I thought about, but never got to it.
These days with LLMs this may be easier to set up though.

> 
> --
> Cheers, Lorenzo

Re: [PATCH v2] mm/vma: keep the unlinked VMA off the file across unmap on mmap hook failure

[Lorenzo Stoakes (ARM)]

On Fri, Oct 09, 2026 at 09:38:56AM -0700, Ihor Solodrai wrote:
> On 2026-10-09 4:31 a.m., Lorenzo Stoakes (ARM) wrote:
> > -cc slopper
> >
> > On Thu, Oct 08, 2026 at 02:48:07PM -0700, Ihor Solodrai wrote:
> > > BPF CI caught this bug on linux-next as well:
> > > https://github.com/kernel-patches/bpf/actions/runs/37736351874
> >
> > Nice that it caught it!
> >
> > Is there a way to automatically notify patch author that when it happens? Does
> > it bisect, etc. or just green/red?
>
> For linux-next it's just green/red now.

That's still nice! We have something similar in mm. I think possibly
inspired by you guys :)

>
> We've added it to have an "upstream merge will break bpf" signal,
> because it happened regularly.
>
> For bpf list we run on every incoming patch, so regressions are detected
> quickly. Not feasible to do that for *every* upstream patch, we'd need
> much more compute.
>
> An auto-bisection is something I thought about, but never got to it.
> These days with LLMs this may be easier to set up though.

yeah that'd be awesome, but obviously a nice-to-have!

--
Cheers, Lorenzo