[PATCH] fork: zero vmap stack using clear_pages() instead of memset()

[PATCH] fork: zero vmap stack using clear_pages() instead of memset()

[Linus Walleij]

After the introduction of clear_pages() we exploit the
fact that the process vm_area is allocated in contiguous
pages to just clear them all in one swift operation.

Suggested-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/linux-mm/dpnwsp7dl4535rd7qmszanw6u5an2p74uxfex4dh53frpb7pu3@2bnjjavjrepe/
Suggested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Link: https://lore.kernel.org/20240311164638.2015063-7-pasha.tatashin@soleen.com
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
 kernel/fork.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index e832da9d15a4..88d78ccef245 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -345,7 +345,7 @@ static int alloc_thread_stack_node(struct task_struct *tsk, int node)
 		stack = kasan_reset_tag(vm_area->addr);
 
 		/* Clear stale pointers from reused stack. */
-		memset(stack, 0, THREAD_SIZE);
+		clear_pages(vm_area->addr, vm_area->nr_pages);
 
 		tsk->stack_vm_area = vm_area;
 		tsk->stack = stack;

---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260224-mm-fork-clear-pages-ae7c52d12a93

Best regards,
-- 
Linus Walleij <linusw@kernel.org>

Re: [PATCH] fork: zero vmap stack using clear_pages() instead of memset()

[David Hildenbrand (Arm)]

On 2/24/26 11:26, Linus Walleij wrote:
> After the introduction of clear_pages() we exploit the
> fact that the process vm_area is allocated in contiguous
> pages to just clear them all in one swift operation.

The pages are virtually contiguous (vmalloc IIUC), not necessarily
physically contiguous. For clear_pages() that should work.

> 
> Suggested-by: Mateusz Guzik <mjguzik@gmail.com>
> Link: https://lore.kernel.org/linux-mm/dpnwsp7dl4535rd7qmszanw6u5an2p74uxfex4dh53frpb7pu3@2bnjjavjrepe/
> Suggested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> Link: https://lore.kernel.org/20240311164638.2015063-7-pasha.tatashin@soleen.com
> Signed-off-by: Linus Walleij <linusw@kernel.org>
> ---
>  kernel/fork.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/fork.c b/kernel/fork.c
> index e832da9d15a4..88d78ccef245 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -345,7 +345,7 @@ static int alloc_thread_stack_node(struct task_struct *tsk, int node)
>  		stack = kasan_reset_tag(vm_area->addr);
>  
>  		/* Clear stale pointers from reused stack. */
> -		memset(stack, 0, THREAD_SIZE);
> +		clear_pages(vm_area->addr, vm_area->nr_pages);

LGTM.

Do we have any idea about performance impact etc?

-- 
Cheers,

David

Re: [PATCH] fork: zero vmap stack using clear_pages() instead of memset()

[Linus Walleij]

On Tue, Feb 24, 2026 at 2:21 PM David Hildenbrand (Arm)
<david@kernel.org> wrote:
> On 2/24/26 11:26, Linus Walleij wrote:

> > After the introduction of clear_pages() we exploit the
> > fact that the process vm_area is allocated in contiguous
> > pages to just clear them all in one swift operation.
>
> The pages are virtually contiguous (vmalloc IIUC), not necessarily
> physically contiguous. For clear_pages() that should work.

Yeah that's what I meant with contiguous, sorry.

> >               /* Clear stale pointers from reused stack. */
> > -             memset(stack, 0, THREAD_SIZE);
> > +             clear_pages(vm_area->addr, vm_area->nr_pages);
>
> LGTM.
>
> Do we have any idea about performance impact etc?

I have a pending patch for implementing clear_pages() for arm64,
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=b4/aarch64-clear-pages
which is in a performance test loop, once I get baseline data from that
I can test something fork-intensive (hackbench, I guess) with this patch on top.

So making that patch made me remember this one code site...

If someone has a good fork performance test running on x86
and can give this a spin, it'd be great!

Yours,
Linus Walleij

Re: [PATCH] fork: zero vmap stack using clear_pages() instead of memset()

[David Hildenbrand (Arm)]

On 2/24/26 14:53, Linus Walleij wrote:
> On Tue, Feb 24, 2026 at 2:21 PM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
>> On 2/24/26 11:26, Linus Walleij wrote:
> 
>>> After the introduction of clear_pages() we exploit the
>>> fact that the process vm_area is allocated in contiguous
>>> pages to just clear them all in one swift operation.
>>
>> The pages are virtually contiguous (vmalloc IIUC), not necessarily
>> physically contiguous. For clear_pages() that should work.
> 
> Yeah that's what I meant with contiguous, sorry.
> 
>>>               /* Clear stale pointers from reused stack. */
>>> -             memset(stack, 0, THREAD_SIZE);
>>> +             clear_pages(vm_area->addr, vm_area->nr_pages);
>>
>> LGTM.
>>
>> Do we have any idea about performance impact etc?
> 
> I have a pending patch for implementing clear_pages() for arm64,
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=b4/aarch64-clear-pages
> which is in a performance test loop, once I get baseline data from that
> I can test something fork-intensive (hackbench, I guess) with this patch on top.
> 
> So making that patch made me remember this one code site...

I'll note that clear_pages() documents: "When running under preemptible
models this is not a problem. Under cooperatively scheduled models,
however, the caller is expected to limit @npages to no more than
PROCESS_PAGES_NON_PREEMPT_BATCH."

We discussed during review that we should probably move that batching
logic into clear_pages() at some point.

PROCESS_PAGES_NON_PREEMPT_BATCH defaults to 1. I'd assume that handling
3 pages here doesn't make a difference, just pointing it out.

CCing Ankur.

> 
> If someone has a good fork performance test running on x86
> and can give this a spin, it'd be great!

That would be nice :)


-- 
Cheers,

David