Remove folio handling for secure storage access exceptions that happen via the kernel mapping. Using folio_try_get() for exceptions via the kernel mapping is racy: for example such an exception may happen on one CPU, while a different CPU frees the corresponding page. Subsequently the page can be part of a folio of different size, before the faulting CPU executes folio_try_get(). This may lead to data corruption. As of now this scenario does not seem to be possible, however with the upcoming load_unaligned_zeropad() this is possible. As a side effect PG_arch_1 is not cleared anymore for such faults via the kernel mapping. However given that this bit is over-indicating it shouldn't matter. Tested-by: Christian Borntraeger Signed-off-by: Heiko Carstens --- arch/s390/mm/fault.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c index e650cdfa2523..776549d55c94 100644 --- a/arch/s390/mm/fault.c +++ b/arch/s390/mm/fault.c @@ -440,13 +440,7 @@ void do_secure_storage_access(struct pt_regs *regs) if (is_kernel_fault(regs)) { if (is_vmalloc_addr((void *)addr)) return handle_fault_error_nolock(regs, 0); - folio = virt_to_folio((void *)addr); - if (unlikely(!folio_try_get(folio))) - return; - rc = uv_convert_from_secure(folio_to_phys(folio)); - if (!rc) - clear_bit(PG_arch_1, &folio->flags.f); - folio_put(folio); + rc = uv_convert_from_secure(__pa(addr)); /* * There are some valid fixup types for kernel * accesses to donated secure memory. zeropad is one -- 2.53.0