diff options
| author | Heiko Carstens <hca@linux.ibm.com> | 2026-07-20 10:58:27 +0200 |
|---|---|---|
| committer | Vasily Gorbik <gor@linux.ibm.com> | 2026-07-30 00:29:10 +0200 |
| commit | aab0734094cef631d611e404c389d89f0b869f5d (patch) | |
| tree | c605a9ab85ec3619c73ad3311dffd8605db0f7b0 /tools/perf/scripts/python/bin/stackcollapse-record | |
| parent | ffa796cc1f45903b55801d5bd437060ea012a12d (diff) | |
KVM: s390: pv: Use VM_SPARSE area for guest variable storage area
The guest variable storage area is allocated with vmalloc and then
donated to the ultravisor. Any kernel access to that area will result
in a secure storage access exception (aka fault).
This is a problem if such a memory area is read via /proc/kcore. This
causes an exception via vread_iter() and results in an unexpected short
read. Avoid this by allocating a custom VM_SPARSE area. If such an area
is read, vread_iter() returns zeroes for the entire area.
Note that the function which frees the area does not update ptes. This
is intentional to allow for deferred / lazy pte updates and TLB flushing
like the generic vfree() code is doing that. See vunmap_pte_range().
This assumes that s390 will gain full support for lazy_mmu_mode_enable()
and lazy_mmu_mode_disable() in the future, since as of now the used
ptep_get_and_clear() in vunmap_pte_range() does indeed invalidate and
flush every single pte entry, but only for s390.
Tested-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-record')
0 files changed, 0 insertions, 0 deletions
