On 24.04.25 23:15, Lorenzo Stoakes wrote:
There are peculiarities within the kernel where what is very clearly mm code is performed elsewhere arbitrarily. This violates separation of concerns and makes it harder to refactor code to make changes to how fundamental initialisation and operation of mm logic is performed. One such case is the creation of the VMA containing the initial stack upon execve()'ing a new process. This is currently performed in __bprm_mm_init() in fs/exec.c. Abstract this operation to create_init_stack_vma(). This allows us to limit use of vma allocation and free code to fork and mm only. We previously did the same for the step at which we relocate the initial stack VMA downwards via relocate_vma_down(), now we move the initial VMA establishment too. Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> ---
...
+/* + * Establish the stack VMA in an execve'd process, located temporarily at the + * maximum stack address provided by the architecture. + * + * We later relocate this downwards in relocate_vma_down(). + * + * This function is almost certainly NOT what you want for anything other than + * early executable initialisation. + * + * On success, returns 0 and sets *vmap to the stack VMA and *top_mem_p to the + * maximum addressable location in the stack (that is capable of storing a + * system word of data). + * + * on failure, returns an error code. + */
I was about to say, if you already write that much documentation, why not turn it into kerneldoc? :) But this function is clearly not intended to have more than one caller, so ... :)
Acked-by: David Hildenbrand <david@xxxxxxxxxx> -- Cheers, David / dhildenb