Re: [PATCH] tracing: Fix WARN_ON in tracing_buffers_mmap_close

Re: [PATCH] tracing: Fix WARN_ON in tracing_buffers_mmap_close

[Steven Rostedt]

On Fri, 27 Feb 2026 10:20:38 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Fri, 27 Feb 2026 11:22:22 +0000
> Vincent Donnefort <vdonnefort@google.com> wrote:
> 
> > > Ah right, Syzkaller is using madvise(MADVISE_DOFORK) which resets VM_DONTCOPY.    
> > 
> > As we are applying restrictive rules for this mapping, I believe setting VM_IO
> > might be a better fix.  
> 
> Agreed.
> 

Adding MM folks so we do this right.

Dear MM folks,

Here's the issue. When the ftrace ring buffer is memory mapped to user
space, we do not want anything "special" done to it. One of those things we
did not want done was to have it copied on fork. To do that, we added
VM_DONTCOPY, but we didn't know that an madvise() could disable that. It
looks like VM_IO will prevent that from happening.

But looking at the various flags, I see there's a VM_SPECIAL. I'm wondering
if that is what we should use?

The effected code is here:

   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/trace/ring_buffer.c#n7172

What's your thoughts?

Thanks,

-- Steve

Re: [PATCH] tracing: Fix WARN_ON in tracing_buffers_mmap_close

[Lorenzo Stoakes]

+cc David.

On Fri, Feb 27, 2026 at 03:56:01PM -0500, Steven Rostedt wrote:
> On Fri, 27 Feb 2026 10:20:38 -0500
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > On Fri, 27 Feb 2026 11:22:22 +0000
> > Vincent Donnefort <vdonnefort@google.com> wrote:
> >
> > > > Ah right, Syzkaller is using madvise(MADVISE_DOFORK) which resets VM_DONTCOPY.
> > >
> > > As we are applying restrictive rules for this mapping, I believe setting VM_IO
> > > might be a better fix.
> >
> > Agreed.
> >
>
> Adding MM folks so we do this right.
>
> Dear MM folks,
>
> Here's the issue. When the ftrace ring buffer is memory mapped to user
> space, we do not want anything "special" done to it. One of those things we
> did not want done was to have it copied on fork. To do that, we added
> VM_DONTCOPY, but we didn't know that an madvise() could disable that. It
> looks like VM_IO will prevent that from happening.
>
> But looking at the various flags, I see there's a VM_SPECIAL. I'm wondering
> if that is what we should use?

VM_SPECIAL is not a VMA flag, it's a bitmask of all the flags which cause us not
to permit things like splitting/merging of VMAs (because we can't safely do
them), i.e. that are one or more of:

        VM_IO - Memory-mapped I/O range.

    VM_PFNMAP - A mapping without struct folio's/page's backing them, e.g. perhaps a
                raw kernel mapping.

  VM_MIXEDMAP - A combination of page/folio-backed memory and/or PFN-backed memory.

VM_DONTEXPAND - Disallow expansion of memory in mremap().

You already set VM_DONTEXPAND so you get these semantics already.

Setting VM_IO just to trigger a failure case in madvise() feels like a hack? I
guess it'd do the trick though, but you're not going to be able to reclaim that
memory, and you might get some unexpected behaviour in code paths that assume
VM_IO means it's memory-mapped I/O... (for instance GUP will stop working, if
you need that).

I'd take a step back and wonder why you are wanting to not allow copying on
fork? Is this kernel-allocated memory? In which case you should set VM_MIXEDMAP
or VM_PFNMAP as appropriate... If not and it has a folio etc. then it seems like
strange semantics.

Are you really bothered also by users doing strange things? Maybe the solution
is to tolerate a fork-copy even if it's broken? I presume somethings straight up
breaks right now?

Without more context that I don't really have much time to acquire it's hard to
know what to advise.

>
> The effected code is here:
>
>    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/trace/ring_buffer.c#n7172
>
> What's your thoughts?
>
> Thanks,
>
> -- Steve

Cheers, Lorenzo