From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 88EED38F620 for ; Sun, 2 Aug 2026 07:40:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785656436; cv=none; b=oiQYcSLnSQU7QtA9WOgz+3las0QdSjSVuotYlePDZrYSnRKKGSv+XsRrlgiluyPsG6+ML+7p5E6FYujtf5ZhYSjtHd3jlH6piVjx9l1tanYwawZZT9vng0EfUc31K984zF6usZotgi1vM7okRFM3+A/Nku0nUwnpkTgAWFjzQas= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785656436; c=relaxed/simple; bh=j3l5JlIJisbjHGZ1l8i2Sk3XO7tPoAp/kJKE2+2yA8M=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=DufgUmnQA1wuyi0BbLAuwEJ260nkjVwRhnC/4SnHwVWbz5LTaeSkYBSz5EQkJuTClkb+yTWH1AR9KhkDhSYQsPequ5j5/nCBwgypP6b32E197jZym4kjnWPX7HJIk1b7ufXwXI/topxn6sxoWjY5rDa17Gw7RG/UhR2yfPbK1v4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZlkYsLpl; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZlkYsLpl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8E4A1F00ACA; Sun, 2 Aug 2026 07:40:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785656435; bh=5LbYy5ro5NDFE3DG1YbB/j5IpRtLd57Aeh6qzOqIXCU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=ZlkYsLplRph3ACb5Y0qShIVauT+VeZYT7DAbyEWRuhNCXupiQXKQeGe48Rp1BoU6o ykH+8hNRMTh3IOq4fgDP11Taaedt3v6TjdFpDBnso8tmFbWPf72X7Dxxz8H9n869lI +o7o4gH44rsEYbf3t0hLdy3zAYU5NrpZ9ts9yUAo6FY+2xzcL24dqG2D+1XtPaA+dr A/Ar28oyD7OKALChWX2DBVAWVLtv4G83BYcrutcRRwl2Tun5geNoLv9MbF01cNbQH0 k4mNwEi99GsQEEmwZoveFbRu00OqMa32HK19GG7MCJHW4L/hQP/o9zozMKLK3BZYcl 8u+jNC2kvyE9g== From: "Barry Song (Xiaomi)" To: akpm@linux-foundation.org, linux-mm@kvack.org Cc: x86@kernel.org, linux-arm-kernel@lists.infradead.org, surenb@google.com, liam@infradead.org, ljs@kernel.org, vbabka@kernel.org, shakeel.butt@linux.dev, david@kernel.org, linux-kernel@vger.kernel.org, zhanghongru@xiaomi.com, willy@infradead.org, zhangbo56@xiaomi.com, "Barry Song (Xiaomi)" Subject: [RFC PATCH v1 1/2] x86/mm: use VMA lock for kernel faults on user addresses Date: Sun, 2 Aug 2026 15:40:17 +0800 Message-Id: <20260802074018.73887-2-baohua@kernel.org> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: <20260802074018.73887-1-baohua@kernel.org> References: <20260802074018.73887-1-baohua@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Use the VMA lock for kernel faults on user addresses. This also makes the existing code below meaningful: /* Quick path to respond to signals */ if (fault_signal_pending(fault, regs)) { if (!user_mode(regs)) kernelmode_fixup_or_oops(regs, error_code, address, SIGBUS, BUS_ADRERR, ARCH_DEFAULT_PKEY); return; } Right now, the code above is dead because !user_mode always takes the mmap_lock path. Co-developed-by: Bo Zhang Signed-off-by: Bo Zhang Signed-off-by: Barry Song (Xiaomi) --- arch/x86/mm/fault.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index 45b99c3b1442..c22b74e0eeaf 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -1328,9 +1328,6 @@ void do_user_addr_fault(struct pt_regs *regs, } #endif - if (!(flags & FAULT_FLAG_USER)) - goto lock_mmap; - vma = lock_vma_under_rcu(mm, address); if (!vma) goto lock_mmap; -- 2.39.3 (Apple Git-146)