summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/arm-cs-trace-disasm.py
diff options
context:
space:
mode:
authorOscar Salvador <osalvador@suse.de>2025-06-30 16:42:09 +0200
committerAndrew Morton <akpm@linux-foundation.org>2025-07-13 16:38:22 -0700
commit9293fb4765527c0d2375eb441d045a5a75f5210d (patch)
treea28148f43528d9dcd27bd1f4bead2d0835a5bb85 /tools/perf/scripts/python/arm-cs-trace-disasm.py
parent2ae1ab9934c785b855583e3eabd208d6f3ac91e1 (diff)
mm,hugetlb: sort out folio locking in the faulting path
Recent conversations showed that there was a misunderstanding about why we were locking the folio prior to call in hugetlb_wp(). In fact, as soon as we have the folio mapped into the pagetables, we no longer need to hold it locked, because we know that no concurrent truncation could have happened. There is only one case where the folio needs to be locked, and that is when we are handling an anonymous folio, because hugetlb_wp() will check whether it can re-use it exclusively for the process that is faulting it in. So, pass the folio locked to hugetlb_wp() when that is the case. Link: https://lkml.kernel.org/r/20250627102904.107202-3-osalvador@suse.de Link: https://lkml.kernel.org/r/20250630144212.156938-3-osalvador@suse.de Signed-off-by: Oscar Salvador <osalvador@suse.de> Suggested-by: David Hildenbrand <david@redhat.com> Acked-by: David Hildenbrand <david@redhat.com> Cc: Gavin Guo <gavinguo@igalia.com> Cc: Muchun Song <muchun.song@linux.dev> Cc: Peter Xu <peterx@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Diffstat (limited to 'tools/perf/scripts/python/arm-cs-trace-disasm.py')
0 files changed, 0 insertions, 0 deletions