summaryrefslogtreecommitdiff
path: root/arch/m68k/mm
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2023-06-19 21:34:15 +0300
committerLinus Torvalds <torvalds@linux-foundation.org>2023-06-25 00:13:55 +0300
commitf313c51d26aa87e69633c9b46efb37a930faca71 (patch)
tree8ac66781cc4d52e784a4b0ff9b46b008c4c928cd /arch/m68k/mm
parentf440fa1ac955e2898893f9301568435eb5cdfc4b (diff)
downloadlinux-f313c51d26aa87e69633c9b46efb37a930faca71.tar.xz
execve: expand new process stack manually ahead of time
This is a small step towards a model where GUP itself would not expand the stack, and any user that needs GUP to not look up existing mappings, but actually expand on them, would have to do so manually before-hand, and with the mm lock held for writing. It turns out that execve() already did almost exactly that, except it didn't take the mm lock at all (it's single-threaded so no locking technically needed, but it could cause lockdep errors). And it only did it for the CONFIG_STACK_GROWSUP case, since in that case GUP has obviously never expanded the stack downwards. So just make that CONFIG_STACK_GROWSUP case do the right thing with locking, and enable it generally. This will eventually help GUP, and in the meantime avoids a special case and the lockdep issue. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'arch/m68k/mm')
0 files changed, 0 insertions, 0 deletions