summaryrefslogtreecommitdiff
path: root/rust
diff options
context:
space:
mode:
authorClaudio Imbrenda <imbrenda@linux.ibm.com>2026-06-02 16:23:53 +0200
committerClaudio Imbrenda <imbrenda@linux.ibm.com>2026-06-02 16:46:41 +0200
commit42546fc642e929de07459ff839a9f43a653ffb4e (patch)
treee2df2c1100da5cf4dc6800e8b855b3da4b66013b /rust
parent9a1dfbbd3506c4f7159feab5ef27434e80256fa5 (diff)
KVM: s390: Lock pte when making page secure
Make sure _kvm_s390_pv_make_secure() takes the pte lock for the given address when attempting to make the page secure. One of the steps in making the page secure is freezing the folio using folio_ref_freeze(), which temporarily sets the reference count to 0. Any attempt to get such a folio while frozen will fail and cause a warning to be printed. Other users of folio_ref_freeze() make sure that the page is not mapped while it's being frozen, thus preventing gup functions from being able to access it. For _kvm_s390_pv_make_secure(), this is not possible, because the page needs to be mapped in order for the import to succeed. By taking the pte lock, gup functions will be blocked until the import operation is done, thus avoiding the race. In theory this does not completely solve the issue: if a page is mapped through multiple mappings, locking one pte does not protect from calling gup on it through the other mapping. In practice this does not happen and it is a decent stopgap solution until a more correct solution is available. Fixes: e38c884df921 ("KVM: s390: Switch to new gmap") Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Message-ID: <20260602142356.169458-8-imbrenda@linux.ibm.com>
Diffstat (limited to 'rust')
0 files changed, 0 insertions, 0 deletions