summaryrefslogtreecommitdiff
path: root/scripts/gdb/linux/stackdepot.py
diff options
context:
space:
mode:
authorCarlos Llamas <cmllamas@google.com>2023-05-02 23:12:18 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2023-05-13 14:30:16 +0300
commitc0fd2101781ef761b636769b2f445351f71c3626 (patch)
tree093d23560158ab82210ba65e57f9232902ff2c6e /scripts/gdb/linux/stackdepot.py
parentb15655b12ddca7ade09807f790bafb6fab61b50a (diff)
downloadlinux-c0fd2101781ef761b636769b2f445351f71c3626.tar.xz
Revert "android: binder: stop saving a pointer to the VMA"
This reverts commit a43cfc87caaf46710c8027a8c23b8a55f1078f19. This patch fixed an issue reported by syzkaller in [1]. However, this turned out to be only a band-aid in binder. The root cause, as bisected by syzkaller, was fixed by commit 5789151e48ac ("mm/mmap: undo ->mmap() when mas_preallocate() fails"). We no longer need the patch for binder. Reverting such patch allows us to have a lockless access to alloc->vma in specific cases where the mmap_lock is not required. This approach avoids the contention that caused a performance regression. [1] https://lore.kernel.org/all/0000000000004a0dbe05e1d749e0@google.com [cmllamas: resolved conflicts with rework of alloc->mm and removal of binder_alloc_set_vma() also fixed comment section] Fixes: a43cfc87caaf ("android: binder: stop saving a pointer to the VMA") Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: stable@vger.kernel.org Signed-off-by: Carlos Llamas <cmllamas@google.com> Link: https://lore.kernel.org/r/20230502201220.1756319-2-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'scripts/gdb/linux/stackdepot.py')
0 files changed, 0 insertions, 0 deletions