Why does fs/exec.c subtract sizeof(void*) from the bottom of the stack?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

When a new process is started up, __bprm_mm_init gets called, and sets the pointer to the bottom of the stack here:

https://github.com/torvalds/linux/blob/5ff0b9e1a1da58b584aa4b8ea234be20b5a1164b/fs/exec.c#L281

Or, if you don’t have an MMU, it’s simply https://github.com/torvalds/linux/blob/5ff0b9e1a1da58b584aa4b8ea234be20b5a1164b/fs/exec.c#L344.

I can’t figure the reasoning behind subtracting sizeof(void*) from the end. Is there other code that uses this information to its advantage? So far I’ve verified that stacks end up with sizeof(void*) null bytes at the end, by getting the stack location from /proc/pid/maps, and dd’ing from /proc/pid/mem. Is this some kind of canary for somewhere else? My grepping so far has also been unsuccessful — I’ve read through any matches I can find, as well as any references to bprm->p. Lastly, I’ve tried using git blame to see the introduction of the line, and ended up at the transition to using git for the kernel. Does anyone know why this code subtracts, instead of using the full space available?

Kind Regards,
Stan Schwertly
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies





[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux