aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/event_analyzing_sample.py
diff options
context:
space:
mode:
authorThomas Hellström <[email protected]>2023-12-09 16:18:42 +0100
committerRodrigo Vivi <[email protected]>2023-12-21 11:45:28 -0500
commit06951c2ee72df2f53b71e7cf2b504d4fa6bba453 (patch)
tree49c9376542d6e5381c0446776e74bf051b0518dd /tools/perf/scripts/python/event_analyzing_sample.py
parente84d716dd461928b3db344748cd7f87395a2ce74 (diff)
drm/xe: Use NULL PTEs as scratch PTEs
Currently scratch PTEs are write-enabled and points to a single scratch page. This has the side effect that buggy applications with out-of-bounds memory accesses may not notice the bad access since what's written may be read back. Instead use NULL PTEs as scratch PTEs. These always return 0 when reading, and writing has no effect. As a slight benefit, we can also use huge NULL PTEs. One drawback pointed out is that debugging may be hampered since previously when inspecting the content of the scratch page, it might be possible to detect writes to out-of-bound addresses and possibly also from where the out-of-bounds address originated. However since the scratch page-table structure is kept, it will be easy to add back the single RW-enabled scratch page under a debug define if needed. Also update the kerneldoc accordingly and move the function to create the scratch page-tables from xe_pt.c to xe_pt.h since it is accessing vm structure internals and this also makes it possible to make it static. v2: - Don't try to encode scratch PTEs larger than 1GiB. - Move xe_pt_create_scratch(), Update kerneldoc. v3: - Rebase. Cc: Brian Welty <[email protected]> Cc: Matt Roper <[email protected]> Signed-off-by: Thomas Hellström <[email protected]> Acked-by: Lucas De Marchi <[email protected]> #for general direction. Reviewed-by: Brian Welty <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/event_analyzing_sample.py')
0 files changed, 0 insertions, 0 deletions