Re: [GIT PULL] tracing: Fixes for 7.0

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, 5 Mar 2026 at 09:00, David Hildenbrand (Arm) <david@kernel.org> wrote:
>
> QEMU traditionally sets MADV_DONTFORK on guest RAM. One reason is to
> speed up fork(), because it doesn't need all the guest RAM in fork'ed
> child processes.

Yes, I think the MADV_DONTFORK thing makes sense on its own - more so
than MADV_DOFORK does.

Because it's a very valid thing for user space to do exactly for that
"speed up fork()" case.

It's similar to how we also export a MADV_WIPEONFORK - for a different
use-case, where we don't want the copying behavior (typically because
we want the child to re-create its own set of data: I thin the main
reason tends to be for things like reseeding random number generation
after fork etc).

So it's just MADV_DOFORK I don't particularly like, because it had
pre-existing kernel semantics (the VM_DONTCOPY bit predates the MADV_*
bits by many many years).

Not copying on fork is always safe. But copying something that the
kernel has said "don't copy" just sounds *wrong*.

> > But I get the feeling that maybe we should at least limit MADV_DOFORK
> > only to the case where the *source* of the DONTFORK was the user, not
> > some kernel mapping.
>
> ... that makes sense. Forbid toggling it on something that has
> VM_SPECIAL set, maybe.

Yeah, I think VM_SPECIAL would be a better match than just checking
VM_IO.  At least it would also catch things like that VM_DONTEXPAND,
and PFN mappings.

So just changing the existing VM_IO test to cover all the VM_SPECIAL
bits would be a simple improvement.

Maybe I should just do that and see if anybody even notices (and
revert and re-think if somebody does)

                 Linus