From nobody Fri Sep 25 03:17:52 2026 Received: from canpmsgout10.his.huawei.com (canpmsgout10.his.huawei.com [113.46.200.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8C0EE390231; Thu, 17 Sep 2026 02:31:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.225 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789612298; cv=none; b=OvTh1zB1muWgScpRuvidzI6nIjDJrPdiCnGeHsQOWDM3l/ximIQoERsyuYm5HOqonyNBXV2rI5068fHf/ISgkihkNEGJQ7aL/VGoB4Th3sfctnQ5ZtyOM7oxDWPUsXcminANW3gLShgR/XozsZrgkzfL/Iqa8brAH1ienWQea+Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789612298; c=relaxed/simple; bh=7rLta0uhvpHXdArFpa2nFMHkiAsyF9MYMzqzil31VOc=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Wc2NjkuxHZQcPvfUi4Szt+AIDP3W1oVXZsUYhixAQ3W+zkklNwbt0RPynGy88ii6JxiTf0if/p1QYrLxyh3isP++1S1tSlc/DbDN7aFh1yYEthMscm3N+5m9837UkAUZaEfHvmLFsZg0XJoyFte6FAC3xE1LVkIuStbE2aubBh4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=Wbc9QZ4Q; arc=none smtp.client-ip=113.46.200.225 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="Wbc9QZ4Q" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=aXF6YrgcgA4YTuuysGFgLRiru7/qN9xHp9WtTJJgMfI=; b=Wbc9QZ4QA1NKRWSOppyIC28YevU232aoPazyaoqpNrEPW6ujwe8OWriWm/RU7pRCUHhCnAnYY +LQLo3bBpoDeRUjrKH1N4ttXPq4TYflEDNU8FMzUYs0FKvNXAY1xHXEyiw7KxF3NGbMOp1X4jr2 oLmFqaeAwMWMxsJmR5cZMJ0= Received: from mail.maildlp.com (unknown [172.19.162.92]) by canpmsgout10.his.huawei.com (SkyGuard) with ESMTPS id 4hlfbw6kzVz1K96s; Thu, 17 Sep 2026 10:20:12 +0800 (CST) Received: from kwepemk300012.china.huawei.com (unknown [7.202.194.175]) by mail.maildlp.com (Postfix) with ESMTPS id 3AD3540565; Thu, 17 Sep 2026 10:31:12 +0800 (CST) Received: from DESKTOP-A37P9LK.huawei.com (10.67.109.17) by kwepemk300012.china.huawei.com (7.202.194.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Thu, 17 Sep 2026 10:31:11 +0800 From: Xie Yuanbin To: , , , , , , , , , , , , CC: , , , , , , , Xie Yuanbin Subject: [PATCH v2 5.10.y/5.15.y 1/3] ARM: fix hash_name() fault Date: Thu, 17 Sep 2026 10:30:54 +0800 Message-ID: <20260917023056.2280-2-xieyuanbin1@huawei.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260917023056.2280-1-xieyuanbin1@huawei.com> References: <20260917023056.2280-1-xieyuanbin1@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemk300012.china.huawei.com (7.202.194.175) Content-Type: text/plain; charset="utf-8" From: "Russell King (Oracle)" [ Upstream commit 7733bc7d299d682f2723dc38fc7f370b9bf973e9 ] Zizhi Wo reports: "During the execution of hash_name()->load_unaligned_zeropad(), a potential memory access beyond the PAGE boundary may occur. For example, when the filename length is near the PAGE_SIZE boundary. This triggers a page fault, which leads to a call to do_page_fault()->mmap_read_trylock(). If we can't acquire the lock, we have to fall back to the mmap_read_lock() path, which calls might_sleep(). This breaks RCU semantics because path lookup occurs under an RCU read-side critical section." This is seen with CONFIG_DEBUG_ATOMIC_SLEEP=3Dy and CONFIG_KFENCE=3Dy. Kernel addresses (with the exception of the vectors/kuser helper page) do not have VMAs associated with them. If the vectors/kuser helper page faults, then there are two possibilities: 1. if the fault happened while in kernel mode, then we're basically dead, because the CPU won't be able to vector through this page to handle the fault. 2. if the fault happened while in user mode, that means the page was protected from user access, and we want to fault anyway. Thus, we can handle kernel addresses from any context entirely separately without going anywhere near the mmap lock. This gives us an entirely non-sleeping path for all kernel mode kernel address faults. As we handle the kernel address faults before interrupts are enabled, this change has the side effect of improving the branch predictor hardening, but does not completely solve the issue. [ Xie Yuanbin: At the upstream, the following patches are a patch set: 1. commit dea20281ac8822661576 ("ARM: group is_permission_fault() with is_translation_fault()") 2. commit 40b466db1dffb41f0529 ("ARM: allow __do_kernel_fault() to report execution of memory faults") 3. commit 7733bc7d299d682f2723 ("ARM: fix hash_name() fault") 4. commit fd2dee1c6e2256f726ba ("ARM: fix branch predictor hardening") patch 1. and 2. is unneeded for 5.10.y and 5.15.y . This patch backports patch 3. and simply adapts to the context differences. ] Reported-by: Zizhi Wo Reported-by: Xie Yuanbin Link: https://lore.kernel.org/r/20251126090505.3057219-1-wozizhi@huaweiclou= d.com Reviewed-by: Xie Yuanbin Tested-by: Xie Yuanbin Signed-off-by: Russell King (Oracle) Signed-off-by: Xie Yuanbin --- arch/arm/mm/fault.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c index c16d6a293b97..094137cd29c8 100644 --- a/arch/arm/mm/fault.c +++ b/arch/arm/mm/fault.c @@ -247,6 +247,35 @@ __do_page_fault(struct mm_struct *mm, unsigned long ad= dr, unsigned int fsr, return fault; } =20 +static int __kprobes +do_kernel_address_page_fault(struct mm_struct *mm, unsigned long addr, + unsigned int fsr, struct pt_regs *regs) +{ + if (user_mode(regs)) { + /* + * Fault from user mode for a kernel space address. User mode + * should not be faulting in kernel space, which includes the + * vector/khelper page. Send a SIGSEGV. + */ + __do_user_fault(addr, fsr, SIGSEGV, SEGV_MAPERR, regs); + } else { + /* + * Fault from kernel mode. Enable interrupts if they were + * enabled in the parent context. Section (upper page table) + * translation faults are handled via do_translation_fault(), + * so we will only get here for a non-present kernel space + * PTE or PTE permission fault. This may happen in exceptional + * circumstances and need the fixup tables to be walked. + */ + if (interrupts_enabled(regs)) + local_irq_enable(); + + __do_kernel_fault(mm, addr, fsr, regs); + } + + return 0; +} + static int __kprobes do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs) { @@ -261,6 +290,12 @@ do_page_fault(unsigned long addr, unsigned int fsr, st= ruct pt_regs *regs) =20 tsk =3D current; mm =3D tsk->mm; + /* + * Handle kernel addresses faults separately, which avoids touching + * the mmap lock from contexts that are not able to sleep. + */ + if (addr >=3D TASK_SIZE) + return do_kernel_address_page_fault(mm, addr, fsr, regs); =20 /* Enable interrupts if they were enabled in the parent context. */ if (interrupts_enabled(regs)) --=20 2.55.0 From nobody Fri Sep 25 03:17:52 2026 Received: from canpmsgout10.his.huawei.com (canpmsgout10.his.huawei.com [113.46.200.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F97638F226; Thu, 17 Sep 2026 02:31:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.225 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789612306; cv=none; b=t+Q4YpuHAW96VdYeYT0m9h7vEnY0wa8ifsugJuhOU6t4G5JGZMVQlihDoslBG4rqUFx9A76jqgWymbAYlS/8kilGw4Q58Vp7PYxGygfcSvams0iCCwkEp6rX0YPZRqHEt47NjKQEzEzOhdhGW4ttzqzEpFl/Zsi9tif7kwSYzXs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789612306; c=relaxed/simple; bh=g5uspe4k24cDIHhEJaUH39Njh0mKjVuVvLoqSVLj94Y=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=aMEI4Usx05vcUz3hBj/t7ZXdw8xy/W/fyFYmV+cMV3jwq96O6ARJZ2eFhzH59DFjW8DSKMmqqtTBQNy3849rX9L6MRe5n4jhblY06QEgLqvvyB5y3sbBs5E87D3kgACR/reWi4FCY75bQjDlGBWElDXXt1VO6gtqbPUhHgxmmI4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=gQj6xI51; arc=none smtp.client-ip=113.46.200.225 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="gQj6xI51" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=A+cVGKFbmlUpUZheELnmpV7HV5ulQT0c0H3v3uXBPBk=; b=gQj6xI51RmZoGLNEYJ7vMhwOHnAgTqkM+sQNWWUD87zAFB13If8HZHg9WIhG0z1gIUzG/tYKC jrhwRExI0jL5sO+kPA4aLXe1FZX7758J7otrcGwmyfy1JBwDzoWDUPPgVKtBhttWp8cfxk8vef5 /bYuzE8wCPXEytwCR1LSQ70= Received: from mail.maildlp.com (unknown [172.19.163.127]) by canpmsgout10.his.huawei.com (SkyGuard) with ESMTPS id 4hlfc06fJkz1K99r; Thu, 17 Sep 2026 10:20:16 +0800 (CST) Received: from kwepemk300012.china.huawei.com (unknown [7.202.194.175]) by mail.maildlp.com (Postfix) with ESMTPS id 3204A402AB; Thu, 17 Sep 2026 10:31:16 +0800 (CST) Received: from DESKTOP-A37P9LK.huawei.com (10.67.109.17) by kwepemk300012.china.huawei.com (7.202.194.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Thu, 17 Sep 2026 10:31:15 +0800 From: Xie Yuanbin To: , , , , , , , , , , , , CC: , , , , , , , Xie Yuanbin Subject: [PATCH v2 5.10.y/5.15.y 2/3] ARM: fix branch predictor hardening Date: Thu, 17 Sep 2026 10:30:55 +0800 Message-ID: <20260917023056.2280-3-xieyuanbin1@huawei.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260917023056.2280-1-xieyuanbin1@huawei.com> References: <20260917023056.2280-1-xieyuanbin1@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemk300012.china.huawei.com (7.202.194.175) Content-Type: text/plain; charset="utf-8" From: "Russell King (Oracle)" [ Upstream commit fd2dee1c6e2256f726ba33fd3083a7be0efc80d3 ] __do_user_fault() may be called with indeterminent interrupt enable state, which means we may be preemptive at this point. This causes problems when calling harden_branch_predictor(). For example, when called from a data abort, do_alignment_fault()->do_bad_area(). Move harden_branch_predictor() out of __do_user_fault() and into the calling contexts. Moving it into do_kernel_address_page_fault(), we can be sure that interrupts will be disabled here. Converting do_translation_fault() to use do_kernel_address_page_fault() rather than do_bad_area() means that we keep branch predictor handling for translation faults. Interrupts will also be disabled at this call site. do_sect_fault() needs special handling, so detect user mode accesses to kernel-addresses, and add an explicit call to branch predictor hardening. Finally, add branch predictor hardening to do_alignment() for the faulting case (user mode accessing kernel addresses) before interrupts are enabled. This should cover all cases where harden_branch_predictor() is called, ensuring that it is always has interrupts disabled, also ensuring that it is called early in each call path. [ Xie Yuanbin: At the upstream, the following patches are a patch set: 1. commit dea20281ac8822661576 ("ARM: group is_permission_fault() with is_translation_fault()") 2. commit 40b466db1dffb41f0529 ("ARM: allow __do_kernel_fault() to report execution of memory faults") 3. commit 7733bc7d299d682f2723 ("ARM: fix hash_name() fault") 4. commit fd2dee1c6e2256f726ba ("ARM: fix branch predictor hardening") patch 1. and 2. is unneeded for 5.10.y and 5.15.y . This patch backports patch 4. and simply adapts to the context differences. ] Reviewed-by: Xie Yuanbin Tested-by: Xie Yuanbin Signed-off-by: Russell King (Oracle) Signed-off-by: Xie Yuanbin --- arch/arm/mm/alignment.c | 4 ++++ arch/arm/mm/fault.c | 39 ++++++++++++++++++++++++++------------- 2 files changed, 30 insertions(+), 13 deletions(-) diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c index bcefe3f51744..758504a28c13 100644 --- a/arch/arm/mm/alignment.c +++ b/arch/arm/mm/alignment.c @@ -23,6 +23,7 @@ #include #include #include +#include #include =20 #include "fault.h" @@ -809,6 +810,9 @@ do_alignment(unsigned long addr, unsigned int fsr, stru= ct pt_regs *regs) int thumb2_32b =3D 0; int fault; =20 + if (addr >=3D TASK_SIZE && user_mode(regs)) + harden_branch_predictor(); + if (interrupts_enabled(regs)) local_irq_enable(); =20 diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c index 094137cd29c8..4afb076383a8 100644 --- a/arch/arm/mm/fault.c +++ b/arch/arm/mm/fault.c @@ -145,9 +145,6 @@ __do_user_fault(unsigned long addr, unsigned int fsr, u= nsigned int sig, { struct task_struct *tsk =3D current; =20 - if (addr > TASK_SIZE) - harden_branch_predictor(); - #ifdef CONFIG_DEBUG_USER if (((user_debug & UDBG_SEGV) && (sig =3D=3D SIGSEGV)) || ((user_debug & UDBG_BUS) && (sig =3D=3D SIGBUS))) { @@ -255,8 +252,10 @@ do_kernel_address_page_fault(struct mm_struct *mm, uns= igned long addr, /* * Fault from user mode for a kernel space address. User mode * should not be faulting in kernel space, which includes the - * vector/khelper page. Send a SIGSEGV. + * vector/khelper page. Handle the branch predictor hardening + * while interrupts are still disabled, then send a SIGSEGV. */ + harden_branch_predictor(); __do_user_fault(addr, fsr, SIGSEGV, SEGV_MAPERR, regs); } else { /* @@ -421,16 +420,20 @@ do_page_fault(unsigned long addr, unsigned int fsr, s= truct pt_regs *regs) * We enter here because the first level page table doesn't contain * a valid entry for the address. * - * If the address is in kernel space (>=3D TASK_SIZE), then we are - * probably faulting in the vmalloc() area. + * If this is a user address (addr < TASK_SIZE), we handle this as a + * normal page fault. This leaves the remainder of the function to handle + * kernel address translation faults. * - * If the init_task's first level page tables contains the relevant - * entry, we copy the it to this task. If not, we send the process - * a signal, fixup the exception, or oops the kernel. + * Since user mode is not permitted to access kernel addresses, pass these + * directly to do_kernel_address_page_fault() to handle. * - * NOTE! We MUST NOT take any locks for this case. We may be in an - * interrupt or a critical region, and should only copy the information - * from the master page table, nothing more. + * Otherwise, we're probably faulting in the vmalloc() area, so try to fix + * that up. Note that we must not take any locks or enable interrupts in + * this case. + * + * If vmalloc() fixup fails, that means the non-leaf page tables did not + * contain an entry for this address, so handle this via + * do_kernel_address_page_fault(). */ #ifdef CONFIG_MMU static int __kprobes @@ -496,7 +499,8 @@ do_translation_fault(unsigned long addr, unsigned int f= sr, return 0; =20 bad_area: - do_bad_area(addr, fsr, regs); + do_kernel_address_page_fault(current->mm, addr, fsr, regs); + return 0; } #else /* CONFIG_MMU */ @@ -516,7 +520,16 @@ do_translation_fault(unsigned long addr, unsigned int = fsr, static int do_sect_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs) { + /* + * If this is a kernel address, but from user mode, then userspace + * is trying bad stuff. Invoke the branch predictor handling. + * Interrupts are disabled here. + */ + if (addr >=3D TASK_SIZE && user_mode(regs)) + harden_branch_predictor(); + do_bad_area(addr, fsr, regs); + return 0; } #endif /* CONFIG_ARM_LPAE */ --=20 2.55.0 From nobody Fri Sep 25 03:17:52 2026 Received: from canpmsgout06.his.huawei.com (canpmsgout06.his.huawei.com [113.46.200.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 555353955F7; Thu, 17 Sep 2026 02:31:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.221 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789612308; cv=none; b=j+qjrrchX3Z6rhnBCG2pZSrxAAaWNzqtI/dXa+ELmtxoduInWI622/Hgoznh4Ie/pDyTqXQHF7yyc1iDrfAUPCzkHGBc/RpMZcexf77HWai7MxBuYanFTANj1vKaFfhmcXIGa+bawZpVmYIbNEYk0+YKSDhfkKQ81M8LdT5m1DM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789612308; c=relaxed/simple; bh=12hCdacFQ9bFjFDdZs/2tWWhXbLVh4nO1BO1Z9+vCXI=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=EaZXBGd5n71neNKflHqs5gAF/G84uO4pGbbQ6/3i5AXMAJaC8GfhcB3OX5dwpcwhH02LKXJgIAYWVarlfrcAttLw9mWgCvqqBmV990mklqg3dNdPLuqsqFU6fDxAuvSQiPn89gszpWJa0wtmoy4yGlKLmAP89nVbK0/t54g9TNA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=Lw4b3BNU; arc=none smtp.client-ip=113.46.200.221 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="Lw4b3BNU" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=PSrGRkSIHQGbxbe4Ft5AX7hBVqF+BpQDdBUjrKmwX5s=; b=Lw4b3BNUoNrvWcO4mMH//REihHJ177IA8d81vu5Sj3j1X2WixptbbQHCrj8+zeGCnaj+d5O1y emeT4FORq7VkEvtIlYXmCuLRs8lJ0svgQMD3vRg8jj/zcCfibaweOAbIr4//1WOfOdoSha7Mn0c bD97coYSyTqsL8J8Ei6IY3A= Received: from mail.maildlp.com (unknown [172.19.162.197]) by canpmsgout06.his.huawei.com (SkyGuard) with ESMTPS id 4hlfc62V9ZzRhQs; Thu, 17 Sep 2026 10:20:22 +0800 (CST) Received: from kwepemk300012.china.huawei.com (unknown [7.202.194.175]) by mail.maildlp.com (Postfix) with ESMTPS id 00E964057D; Thu, 17 Sep 2026 10:31:19 +0800 (CST) Received: from DESKTOP-A37P9LK.huawei.com (10.67.109.17) by kwepemk300012.china.huawei.com (7.202.194.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.45; Thu, 17 Sep 2026 10:31:18 +0800 From: Xie Yuanbin To: , , , , , , , , , , , , CC: , , , , , , , Yadi.hu , Xie Yuanbin Subject: [PATCH v2 5.10.y/5.15.y 3/3] ARM: ensure interrupts are enabled in __do_user_fault() Date: Thu, 17 Sep 2026 10:30:56 +0800 Message-ID: <20260917023056.2280-4-xieyuanbin1@huawei.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260917023056.2280-1-xieyuanbin1@huawei.com> References: <20260917023056.2280-1-xieyuanbin1@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemk300012.china.huawei.com (7.202.194.175) Content-Type: text/plain; charset="utf-8" From: "Russell King (Oracle)" [ Upstream commit 59e4f3b45b96a24fc9b7a89e5f8a2168b30f95af ] __do_user_fault() may be called from fault handling paths where the interrupts are enabled or disabled. E.g. do_page_fault() calls this with interrupts enabled, whereas do_sect_fault()->do_bad_area() will call this with interrupts disabled. Since this is a userspace fault, we know that interrupts were enabled in the parent context, so call local_irq_enable() here to give a consistent interrupt state. This is necessary for force_sig_info() when PREEMPT_RT is enabled. Reported-by: Yadi.hu Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: Russell King (Oracle) Signed-off-by: Xie Yuanbin --- arch/arm/mm/fault.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c index 4afb076383a8..8b31d7704626 100644 --- a/arch/arm/mm/fault.c +++ b/arch/arm/mm/fault.c @@ -137,7 +137,8 @@ __do_kernel_fault(struct mm_struct *mm, unsigned long a= ddr, unsigned int fsr, =20 /* * Something tried to access memory that isn't in our memory map.. - * User mode accesses just cause a SIGSEGV + * User mode accesses just cause a SIGSEGV. Ensure interrupts are enabled + * for preempt RT. */ static void __do_user_fault(unsigned long addr, unsigned int fsr, unsigned int sig, @@ -145,6 +146,8 @@ __do_user_fault(unsigned long addr, unsigned int fsr, u= nsigned int sig, { struct task_struct *tsk =3D current; =20 + local_irq_enable(); + #ifdef CONFIG_DEBUG_USER if (((user_debug & UDBG_SEGV) && (sig =3D=3D SIGSEGV)) || ((user_debug & UDBG_BUS) && (sig =3D=3D SIGBUS))) { @@ -254,6 +257,7 @@ do_kernel_address_page_fault(struct mm_struct *mm, unsi= gned long addr, * should not be faulting in kernel space, which includes the * vector/khelper page. Handle the branch predictor hardening * while interrupts are still disabled, then send a SIGSEGV. + * Note that __do_user_fault() will enable interrupts. */ harden_branch_predictor(); __do_user_fault(addr, fsr, SIGSEGV, SEGV_MAPERR, regs); --=20 2.55.0