Re: [GIT PULL] tracing: Fixes for 7.0

["David Hildenbrand (Arm)" <david@kernel.org>]

On 3/5/26 18:17, Linus Torvalds wrote:
> 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.

CCing Lorenzo.

> 
> 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.

Ack.

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

Agreed. We could think about letting it sit a bit in -next before moving
it to mainline.

-- 
Cheers,

David