+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 <[email protected]> wrote:
>
> > On Fri, 27 Feb 2026 11:22:22 +0000
> > Vincent Donnefort <[email protected]> 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
