Re: [GIT PULL] tracing: Fixes for 7.0

["Lorenzo Stoakes (Oracle)" <ljs@kernel.org>]

On Thu, Mar 05, 2026 at 07:59:14PM +0100, David Hildenbrand (Arm) wrote:
> 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.

Yes, I agree. It's odd that we explicitly gate on VM_IO there, it's unusual.

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

Some of the madvise() operations explicitly work with PFN mappings, but it
really makes no sense to fiddle with them in this case.

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


Feel free to add:

Reviewed-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>

To a patch that simply does something like:

diff --git a/mm/madvise.c b/mm/madvise.c
index c0370d9b4e23..dbb69400786d 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -1389,7 +1389,7 @@ static int madvise_vma_behavior(struct madvise_behavior *madv_behavior)
 		new_flags |= VM_DONTCOPY;
 		break;
 	case MADV_DOFORK:
-		if (new_flags & VM_IO)
+		if (new_flags & VM_SPECIAL)
 			return -EINVAL;
 		new_flags &= ~VM_DONTCOPY;
 		break;
--
2.53.0

That makes me wonder about whether we want to permit VM_DONTFORK for
MADV_DONTFORK, it's kinda a weird usecase but anyway this is the safer
change for now as I think it's pretty obviously sane.

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

I would eat my hat, board a flying pig and note the sound of several trees
falling when there's nobody around if anybody complained :)

>
> --
> Cheers,
>
> David

Cheers, Lorenzo