From: Dan Carpenter <dan.carpenter@linaro.org>
To: oe-kbuild@lists.linux.dev, Heiko Carstens <hca@linux.ibm.com>
Cc: lkp@intel.com, oe-kbuild-all@lists.linux.dev,
linux-kernel@vger.kernel.org, Vasily Gorbik <gor@linux.ibm.com>
Subject: arch/s390/mm/fault.c:566 do_secure_storage_access() warn: inconsistent returns '&mm->mmap_lock'.
Date: Fri, 25 Oct 2024 10:35:47 +0300 [thread overview]
Message-ID: <5e4a2c40-9fc4-439a-8166-3a694e705d8e@stanley.mountain> (raw)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: c2ee9f594da826bea183ed14f2cc029c719bf4da
commit: 7c194d84a9ce662426b2ecb59da54bb80c6b1d91 s390/mm,fault: remove VM_FAULT_BADMAP and VM_FAULT_BADACCESS
config: s390-randconfig-r072-20241024 (https://download.01.org/0day-ci/archive/20241025/202410250552.XsMLl1sx-lkp@intel.com/config)
compiler: s390-linux-gcc (GCC) 14.1.0
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
| Closes: https://lore.kernel.org/r/202410250552.XsMLl1sx-lkp@intel.com/
smatch warnings:
arch/s390/mm/fault.c:566 do_secure_storage_access() warn: inconsistent returns '&mm->mmap_lock'.
vim +566 arch/s390/mm/fault.c
084ea4d611a3d0 Vasily Gorbik 2020-01-21 498 void do_secure_storage_access(struct pt_regs *regs)
084ea4d611a3d0 Vasily Gorbik 2020-01-21 499 {
5be05c35e72f74 Heiko Carstens 2023-10-12 500 union teid teid = { .val = regs->int_parm_long };
9641613f48bbf8 Heiko Carstens 2023-10-12 501 unsigned long addr = get_fault_address(regs);
084ea4d611a3d0 Vasily Gorbik 2020-01-21 502 struct vm_area_struct *vma;
084ea4d611a3d0 Vasily Gorbik 2020-01-21 503 struct mm_struct *mm;
084ea4d611a3d0 Vasily Gorbik 2020-01-21 504 struct page *page;
b108f7f0a29b24 Claudio Imbrenda 2022-06-28 505 struct gmap *gmap;
084ea4d611a3d0 Vasily Gorbik 2020-01-21 506 int rc;
084ea4d611a3d0 Vasily Gorbik 2020-01-21 507
85b18d7b5e7ffe Janosch Frank 2021-01-12 508 /*
3aad8c04429779 Heiko Carstens 2023-10-12 509 * Bit 61 indicates if the address is valid, if it is not the
3aad8c04429779 Heiko Carstens 2023-10-12 510 * kernel should be stopped or SIGSEGV should be sent to the
3aad8c04429779 Heiko Carstens 2023-10-12 511 * process. Bit 61 is not reliable without the misc UV feature,
3aad8c04429779 Heiko Carstens 2023-10-12 512 * therefore this needs to be checked too.
85b18d7b5e7ffe Janosch Frank 2021-01-12 513 */
5be05c35e72f74 Heiko Carstens 2023-10-12 514 if (uv_has_feature(BIT_UV_FEAT_MISC) && !teid.b61) {
85b18d7b5e7ffe Janosch Frank 2021-01-12 515 /*
85b18d7b5e7ffe Janosch Frank 2021-01-12 516 * When this happens, userspace did something that it
85b18d7b5e7ffe Janosch Frank 2021-01-12 517 * was not supposed to do, e.g. branching into secure
85b18d7b5e7ffe Janosch Frank 2021-01-12 518 * memory. Trigger a segmentation fault.
85b18d7b5e7ffe Janosch Frank 2021-01-12 519 */
85b18d7b5e7ffe Janosch Frank 2021-01-12 520 if (user_mode(regs)) {
85b18d7b5e7ffe Janosch Frank 2021-01-12 521 send_sig(SIGSEGV, current, 0);
85b18d7b5e7ffe Janosch Frank 2021-01-12 522 return;
85b18d7b5e7ffe Janosch Frank 2021-01-12 523 }
85b18d7b5e7ffe Janosch Frank 2021-01-12 524 /*
3aad8c04429779 Heiko Carstens 2023-10-12 525 * The kernel should never run into this case and
3aad8c04429779 Heiko Carstens 2023-10-12 526 * there is no way out of this situation.
85b18d7b5e7ffe Janosch Frank 2021-01-12 527 */
85b18d7b5e7ffe Janosch Frank 2021-01-12 528 panic("Unexpected PGM 0x3d with TEID bit 61=0");
85b18d7b5e7ffe Janosch Frank 2021-01-12 529 }
084ea4d611a3d0 Vasily Gorbik 2020-01-21 530 switch (get_fault_type(regs)) {
b108f7f0a29b24 Claudio Imbrenda 2022-06-28 531 case GMAP_FAULT:
b108f7f0a29b24 Claudio Imbrenda 2022-06-28 532 mm = current->mm;
b108f7f0a29b24 Claudio Imbrenda 2022-06-28 533 gmap = (struct gmap *)S390_lowcore.gmap;
b108f7f0a29b24 Claudio Imbrenda 2022-06-28 534 mmap_read_lock(mm);
b108f7f0a29b24 Claudio Imbrenda 2022-06-28 535 addr = __gmap_translate(gmap, addr);
b108f7f0a29b24 Claudio Imbrenda 2022-06-28 536 mmap_read_unlock(mm);
7c194d84a9ce66 Heiko Carstens 2023-10-12 537 if (IS_ERR_VALUE(addr))
7c194d84a9ce66 Heiko Carstens 2023-10-12 538 return handle_fault_error_nolock(regs, SEGV_MAPERR);
b108f7f0a29b24 Claudio Imbrenda 2022-06-28 539 fallthrough;
084ea4d611a3d0 Vasily Gorbik 2020-01-21 540 case USER_FAULT:
084ea4d611a3d0 Vasily Gorbik 2020-01-21 541 mm = current->mm;
d8ed45c5dcd455 Michel Lespinasse 2020-06-08 542 mmap_read_lock(mm);
084ea4d611a3d0 Vasily Gorbik 2020-01-21 543 vma = find_vma(mm, addr);
7c194d84a9ce66 Heiko Carstens 2023-10-12 544 if (!vma)
7c194d84a9ce66 Heiko Carstens 2023-10-12 545 return handle_fault_error(regs, SEGV_MAPERR);
mmap_read_unlock() before returning?
084ea4d611a3d0 Vasily Gorbik 2020-01-21 546 page = follow_page(vma, addr, FOLL_WRITE | FOLL_GET);
084ea4d611a3d0 Vasily Gorbik 2020-01-21 547 if (IS_ERR_OR_NULL(page)) {
d8ed45c5dcd455 Michel Lespinasse 2020-06-08 548 mmap_read_unlock(mm);
084ea4d611a3d0 Vasily Gorbik 2020-01-21 549 break;
084ea4d611a3d0 Vasily Gorbik 2020-01-21 550 }
084ea4d611a3d0 Vasily Gorbik 2020-01-21 551 if (arch_make_page_accessible(page))
084ea4d611a3d0 Vasily Gorbik 2020-01-21 552 send_sig(SIGSEGV, current, 0);
084ea4d611a3d0 Vasily Gorbik 2020-01-21 553 put_page(page);
d8ed45c5dcd455 Michel Lespinasse 2020-06-08 554 mmap_read_unlock(mm);
084ea4d611a3d0 Vasily Gorbik 2020-01-21 555 break;
084ea4d611a3d0 Vasily Gorbik 2020-01-21 556 case KERNEL_FAULT:
084ea4d611a3d0 Vasily Gorbik 2020-01-21 557 page = phys_to_page(addr);
cd1adf1b63a112 Linus Torvalds 2021-09-07 558 if (unlikely(!try_get_page(page)))
084ea4d611a3d0 Vasily Gorbik 2020-01-21 559 break;
084ea4d611a3d0 Vasily Gorbik 2020-01-21 560 rc = arch_make_page_accessible(page);
084ea4d611a3d0 Vasily Gorbik 2020-01-21 561 put_page(page);
084ea4d611a3d0 Vasily Gorbik 2020-01-21 562 if (rc)
084ea4d611a3d0 Vasily Gorbik 2020-01-21 563 BUG();
084ea4d611a3d0 Vasily Gorbik 2020-01-21 564 break;
084ea4d611a3d0 Vasily Gorbik 2020-01-21 565 default:
ae626f686351d2 Heiko Carstens 2023-10-12 @566 unreachable();
084ea4d611a3d0 Vasily Gorbik 2020-01-21 567 }
084ea4d611a3d0 Vasily Gorbik 2020-01-21 568 }
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next reply other threads:[~2024-10-25 7:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-25 7:35 Dan Carpenter [this message]
2024-10-25 10:05 ` Heiko Carstens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5e4a2c40-9fc4-439a-8166-3a694e705d8e@stanley.mountain \
--to=dan.carpenter@linaro.org \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=oe-kbuild@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®