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 91F792F8EB0 for ; Mon, 3 Aug 2026 15:18:39 +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=1785770320; cv=none; b=s4wUZc7kV+2f7QxQl8kNaRlgd3sEcnH4AgtjQsaPTjsfrVZoZHXVuFSDNU7e2Ti7H/j/TQdd3iEiowKMNaPsCqrUw3J/Wjhp7ZIweQfDGl4KPriFoIk83+2CyA3UGd9SpWMU+3c3YlQx2jNye/X5/LYvuGRuwMW86UbsN9pfvfU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785770320; c=relaxed/simple; bh=KVzONgFDN0thvvP6dXO3YdvAJ0ymwfCIxZbNLqmPRuI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XHFEZPA/p6Vkzr2+nH/xt0d0pT3RrjY8Rng4iybrTZpwP7QKoNlIQZSd/6DuvKNQLhVrLM2tYgeFjki9KIbeLfrFjgd6Kh9JFAOdHHy81yfT06GVIk/Z+rd0uzdOot88bMjO/FwHJAMei1gAgg1nyHTBNEQyjDpzZMm3+Ia8Ke8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Zj8N5Lnc; 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="Zj8N5Lnc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DCE3F1F000E9; Mon, 3 Aug 2026 15:18:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785770319; bh=rnoRC8MENm6FOG7GtLgXFwQMWUgLDKOzq6eHxm1QfVw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Zj8N5LncJ9Cjbu5XMUCTq1EhJhO/AiPzFyqHNFzurkJUr47GtQ8m3HDkp/l8XHzes FGMJRMrN9FyA92yn+PFyKoqj/mrhsy/Iajaa5GNiDtTwOkiUJbwchR4AHQQWqVF3g5 en/QFdBK+yasIVGbbGNIhuA4rjEYaGmTmGtEq0KoTIYE9++darnOSgxgdJqiVQRHxo DiOeV8Q7XFw5K2iBu12P22D/8JPKW3Z6qH5986svjYvLka7KFcv6a1pKcMwvH3QmOC kc1uPhXrkHSJ3KbSByUeKoWyYAhkxPqmvrkkRB7xAv9tKVzeUSY1qW5ljgDEK0eI7N NP/d/uEJF32mw== Date: Mon, 3 Aug 2026 16:18:21 +0100 From: "Lorenzo Stoakes (ARM)" To: "Barry Song (Xiaomi)" Cc: akpm@linux-foundation.org, linux-mm@kvack.org, x86@kernel.org, linux-arm-kernel@lists.infradead.org, surenb@google.com, liam@infradead.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 Subject: Re: [RFC PATCH v1 1/2] x86/mm: use VMA lock for kernel faults on user addresses Message-ID: References: <20260802074018.73887-1-baohua@kernel.org> <20260802074018.73887-2-baohua@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260802074018.73887-2-baohua@kernel.org> On Sun, Aug 02, 2026 at 03:40:17PM +0800, Barry Song (Xiaomi) wrote: > 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; > } Hmm yeah :) Bit weird it uses user_mode(regs) and the early exit uses the just-set 'flags & FAULT_FLAG_USER' too. Some horrible duplication here too... the user_mod_regs() etc. code is just duplicated in the mmap lock path. I think you mentioned it on Suren/Dave's series but vma_start_read_unlocked() would avoid all this and could lead to a nicely red patch. > > 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; > - I'm not sure why kernel faults of userland memory were excluded initially (Suren?) Given that it's OK to take the mmap lock here and we're necessarily in process context anyway surely it's OK to take the VMA lock? It looks fine to me but want Suren's input. Also given vma_start_read_unlocked() is coming maybe that's better for a cleanup. And finally - Willy is working on a grand clean up of this stuff _I think_ so you probably should coordinate with him also? > vma = lock_vma_under_rcu(mm, address); > if (!vma) > goto lock_mmap; > -- > 2.39.3 (Apple Git-146) > -- Cheers, Lorenzo