diff options
author | Lorenzo Stoakes <[email protected]> | 2024-11-01 18:46:27 +0000 |
---|---|---|
committer | Andrew Morton <[email protected]> | 2024-11-11 13:09:43 -0800 |
commit | ad2bc8812fc17c8536d5e37aa0754463b76b66a4 (patch) | |
tree | 29489d9e18d1f819414d4902d4dd0957f8841b4a /tools/perf/scripts/python/gecko.py | |
parent | 93c1e57adeb0aa7d3feedeb82ac19845cbe540de (diff) |
mm: remove unnecessary page_table_lock on stack expansion
Ever since commit 8d7071af8907 ("mm: always expand the stack with the mmap
write lock held") we have been expanding the stack with the mmap write
lock held.
This is true in all code paths:
get_arg_page()
-> expand_downwards()
setup_arg_pages()
-> expand_stack_locked()
-> expand_downwards() / expand_upwards()
lock_mm_and_find_vma()
-> expand_stack_locked()
-> expand_downwards() / expand_upwards()
create_elf_tables()
-> find_extend_vma_locked()
-> expand_stack_locked()
expand_stack()
-> vma_expand_down()
-> expand_downwards()
expand_stack()
-> vma_expand_up()
-> expand_upwards()
Each of which acquire the mmap write lock before doing so. Despite this,
we maintain code that acquires a page table lock in the expand_upwards()
and expand_downwards() code, stating that we hold a shared mmap lock and
thus this is necessary.
It is not, we do not have to worry about concurrent VMA expansions so we
can simply drop this, and update comments accordingly.
We do not even need be concerned with racing page faults, as
vma_start_write() is invoked in both cases.
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Lorenzo Stoakes <[email protected]>
Acked-by: Linus Torvalds <[email protected]>
Reviewed-by: Jann Horn <[email protected]>
Acked-by: Vlastimil Babka <[email protected]>
Reviewed-by: Liam R. Howlett <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/gecko.py')
0 files changed, 0 insertions, 0 deletions