korg/linux
0
0
Fork 0
mirror of https://mirrors.bfsu.edu.cn/git/linux.git synced 2024-11-27 22:24:11 +08:00
Code Issues Packages Projects Releases Wiki Activity

powerpc/mm/book3s64: Use the correct storage key value when calling H_PROTECT

Browse Source 
H_PROTECT expects the flag value to include flags:
  AVPN, pp0, pp1, pp2, key0-key4, Noexec, CMO Option flags

This patch updates hpte_updatepp() to fetch the storage key value from
the linux page table and use the same in H_PROTECT hcall.

native_hpte_updatepp() is not updated because the kernel doesn't clear
the existing storage key value there. The kernel also doesn't use
hpte_updatepp() callback for updating storage keys.

This fixes the below kernel crash observed with KUAP enabled.

  BUG: Unable to handle kernel data access on write at 0xc009fffffc440000
  Faulting instruction address: 0xc0000000000b7030
  Key fault AMR: 0xfcffffffffffffff IAMR: 0xc0000077bc498100
  Found HPTE: v = 0x40070adbb6fffc05 r = 0x1ffffffffff1194
  Oops: Kernel access of bad area, sig: 11 [#1]
  LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
  ...
  CFAR: c000000000010100 DAR: c009fffffc440000 DSISR: 02200000 IRQMASK: 0
  ...
  NIP memset+0x68/0x104
  LR  pcpu_alloc+0x54c/0xb50
  Call Trace:
    pcpu_alloc+0x55c/0xb50 (unreliable)
    blk_stat_alloc_callback+0x94/0x150
    blk_mq_init_allocated_queue+0x64/0x560
    blk_mq_init_queue+0x54/0xb0
    scsi_mq_alloc_queue+0x30/0xa0
    scsi_alloc_sdev+0x1cc/0x300
    scsi_probe_and_add_lun+0xb50/0x1020
    __scsi_scan_target+0x17c/0x790
    scsi_scan_channel+0x90/0xe0
    scsi_scan_host_selected+0x148/0x1f0
    do_scan_async+0x2c/0x2a0
    async_run_entry_fn+0x78/0x220
    process_one_work+0x264/0x540
    worker_thread+0xa8/0x600
    kthread+0x190/0x1a0
    ret_from_kernel_thread+0x5c/0x6c

With KUAP enabled the kernel uses storage key 3 for all its
translations. But as shown by the debug print, in this specific case we
have the hash page table entry created with key value 0.

  Found HPTE: v = 0x40070adbb6fffc05 r = 0x1ffffffffff1194

and DSISR indicates a key fault.

This can happen due to parallel fault on the same EA by different CPUs:

  CPU 0					CPU 1
  fault on X

  H_PAGE_BUSY set
  					fault on X

  finish fault handling and
  clear H_PAGE_BUSY
  					check for H_PAGE_BUSY
  					continue with fault handling.

This implies CPU1 will end up calling hpte_updatepp for address X and
the kernel updated the hash pte entry with key 0

Fixes: d94b827e89 ("powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation")
Reported-by: Murilo Opsfelder Araujo <muriloo@linux.ibm.com>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Debugged-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210326070755.304625-1-aneesh.kumar@linux.ibm.com
This commit is contained in:
Aneesh Kumar K.V 2021-03-26 12:37:55 +05:30 committed by Michael Ellerman
parent 274cb1ca2e
commit 53f1d31708
1 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
arch/powerpc/platforms/pseries/lpar.c
View File

@ -887,7 +887,8 @@ static long pSeries_lpar_hpte_updatepp(unsigned long slot,
want_v = hpte_encode_avpn(vpn, psize, ssize);
flags = (newpp & 7) | H_AVPN;
flags = (newpp & (HPTE_R_PP | HPTE_R_N | HPTE_R_KEY_LO)) | H_AVPN;
flags |= (newpp & HPTE_R_KEY_HI) >> 48;
if (mmu_has_feature(MMU_FTR_KERNEL_RO))
/* Move pp0 into bit 8 (IBM 55) */
flags |= (newpp & HPTE_R_PP0) >> 55;