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

[Ankur Arora <ankur.a.arora@oracle.com>]

David Hildenbrand (Arm) <david@kernel.org> writes:

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

Yeah. However, clear_pages() can be architecturally overriden.

I don't see any use for a non-batched implementation. So, maybe
the arch version should become __clear_pages() and clear_pages()
can always do the appropriate batching.

--
ankur