v4:
- Add two more cleanup patches based on Sashiko feedback, however I
  don't consider them as bug fixes. This is more cosmetics:
  - Use handle_fault_error() in do_secure_storage_access()
  - Use goto statement in do_secure_storage_access()

v3:
- Fix two more pre-existing bugs reported by Sashiko
- Add Christian's Tested-by tag to four of the six patches

v2:
- Explicitely PAGE_ALIGN size in uv_alloc_stor_var() [Sashiko]
- Document that lazy PTE update / TLB flushing is intended [Sashiko]

v1:
Support for DCACHE_WORD_ACCESS was recently removed [1] since it caused
problems with the incomplete handling of secure storage access
exceptions. It looked like fixing the exception handler would be a larger
effort; therefore support for DCACHE_WORD_ACCESS was removed as a work
around.

Address the potential problems that exist with secure storage access
exceptions and add support for DCACHE_WORD_ACCESS again.

In particular address the following problems:

- Reading the guest variable storage area via the /proc/kcore interface
  results in short reads. Address this by using a VM_SPARSE area for the
  guest variable storage area. VM_SPARSE areas will be handled like
  memory holes (zeros will be read).

- Fix handling of secure storage access exceptions in vmalloc area.

- Remove folio handling for secure storage access exceptions to avoid
  potential data corruption.

[1] 37540b8c287f ("s390: Revert support for DCACHE_WORD_ACCESS")

Heiko Carstens (8):
  KVM: s390: pv: Use VM_SPARSE area for guest variable storage area
  s390/mm: Add missing mm check to do_secure_storage_access()
  s390/mm: Use lock_mm_and_find_vma() in do_secure_storage_access()
  s390/mm: Fix handling of vmalloc area in do_secure_storage_access()
  s390/mm: Remove folio handling for kernel faults in do_secure_storage_access()
  s390/mm: Use handle_fault_error() in do_secure_storage_access()
  s390/mm: Use goto statement in do_secure_storage_access()
  s390: Add support for DCACHE_WORD_ACCESS (again)

 arch/s390/Kconfig                      |  1 +
 arch/s390/include/asm/asm-extable.h    |  4 ++
 arch/s390/include/asm/uv.h             |  2 +
 arch/s390/include/asm/word-at-a-time.h | 22 +++++++++
 arch/s390/kernel/uv.c                  | 65 ++++++++++++++++++++++++++
 arch/s390/kvm/pv.c                     |  6 +--
 arch/s390/mm/extable.c                 | 18 +++++++
 arch/s390/mm/fault.c                   | 35 ++++++--------
 8 files changed, 128 insertions(+), 25 deletions(-)

-- 
2.53.0

Am 20.07.26 um 10:58 schrieb Heiko Carstens:
> v4:
> - Add two more cleanup patches based on Sashiko feedback, however I
>    don't consider them as bug fixes. This is more cosmetics:
>    - Use handle_fault_error() in do_secure_storage_access()
>    - Use goto statement in do_secure_storage_access()
Shall we run the kmemleak fix (for the initial memblock) and maybe additional
kmemleak changes for the other secure memory arady  on top of your patch set
or shall I run them independently?

On Mon, Jul 20, 2026 at 11:03:01AM +0200, Christian Borntraeger wrote:
> Am 20.07.26 um 10:58 schrieb Heiko Carstens:
> > v4:
> > - Add two more cleanup patches based on Sashiko feedback, however I
> >    don't consider them as bug fixes. This is more cosmetics:
> >    - Use handle_fault_error() in do_secure_storage_access()
> >    - Use goto statement in do_secure_storage_access()
> Shall we run the kmemleak fix (for the initial memblock) and maybe additional
> kmemleak changes for the other secure memory arady  on top of your patch set
> or shall I run them independently?

Please handle that independently of this series.

After reading through all the Sashiko reports, at least (Sashiko) AI review is
now complete. All current findings are either false positives, describe
intended behavior, or are addressed with later patches in this series.

Now waiting for human review :)