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 75065377559 for ; Tue, 4 Aug 2026 14:46:29 +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=1785854790; cv=none; b=OYhTCHfoHmlpDdfMywTiu0ZORI0lws6cfkI1ln19Ub6xFXv012r/t+u4kPodalocvLF08bxqDohSuj+bGCVYUUh+2QDZE5pDNpmztg5sF/1w3oU/h1ZHnaJuW/qRzuvG4X5BG7xz2v73Dz5raLPyeT32CC+CdC0c2t4GqeEgUa0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785854790; c=relaxed/simple; bh=yMUpmwhyUGbN4y7Th44mQhp5xdp0tKJRcazwxyBT+r4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tVi1wIsWGE/B77j3DaqK1cHx0u74zDta6/gAbrZlxinpxTCbtOWfDuft3EWAOBMAnX1rHFaUg3NjeVlErbxKvz8uOJTnjHLgbAlmV4mlYG0qv6wOK8grPu5D1gAmLiseMGT7NCewU3dODvhZndKc7oXLhaTb6SUfuOERLF6ml9U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RkxaN2ik; 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="RkxaN2ik" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2510B1F000E9; Tue, 4 Aug 2026 14:46:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785854789; bh=uUvC+y0j8JFjtE+XMJ9UQGtCiCNbH3kOeZKEuG06DWw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=RkxaN2ik9P4rS1+/q3KgKb/2D2Eh7uomzp+QNGTLlcFGiVoRdD2vuChwYpMjwFQp5 ECUUHTxHFDlqwTii01KYRocgyxJj35A2kS9tX/ei31yWKYaIN9L9YFhsn2ZlSdxdyB gu0aWTswPsa/XnAveSiWQSG8fjaOZEZV1PuVweKw3vJk8stnyIOtCX8KUpkc7OCrsx n5diT9WhcnlnZyAygOsDSKKw9mkehqfM6GW24BR59cBzv+d7NN+rcYhlTya9qTqOqf dxbLbJyZSgtJtNT8G+GckekF/SFjztBDfoEeCQENfohv6Y+9YdnN1HvSiqsu4FzBxO kMbSJgWnIjbXQ== Date: Tue, 4 Aug 2026 15:46:11 +0100 From: "Lorenzo Stoakes (ARM)" To: Barry Song 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Aug 04, 2026 at 06:37:31AM +0800, Barry Song wrote: > On Mon, Aug 3, 2026 at 11:18 PM Lorenzo Stoakes (ARM) wrote: > > > > 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. > > vma_start_read_unlocked() could completely avoid falling back to > mmap_lock for binder. For page faults, however, there are still > paths that must retry under mmap_lock, such as > __vmf_anon_prepare() and swapcache_is_device_private(). > So we may not end up with something as clean as binder, but I > think we can still achieve a cleaner design than what we have > today. > Right, and also fault retrying (though Hongru's series is looking at giving at least 1 more try under VMA lock there). Let's maybe wait for that to settle first and see how that looks :) > > > > > > > > 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? > > I have no problem waiting for Matthew's work. It is the right > thing to refactor the duplicated code across architectures for > the VMA lock page fault path. Seems sensible thanks! > > Thanks > Barry -- Cheers, Lorenzo