From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) (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 7419A3DC4A9 for ; Tue, 7 Jul 2026 15:34:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.32.30.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783438483; cv=none; b=YGg8gDBDrDEzPMmUdrSxq2x54YKofkzPkfwpW2hpTsMHxMM5iqk7AZSB9ZjkUPDxP8hBfrXaFzsGGT7wUB3gRrvrOYu73hDsh2p6ggvwuqHjp4T4mgtyREl/tB8B5aAx+qnR88alfKuyNimRxSw94T7vCGjzaNVfSz1Ce9jO92k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783438483; c=relaxed/simple; bh=AgJUftRrlTSLHv1lbGL/mvXR8X3B4U2thvStApaDgyM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TAzuVJlyaOVSwhin+GTRx8K2MKzI4i8ExrHFe9uAAjSDha8TadyjSGvlz4wgNSUNgn3eOcpzB9JVQQkijkIJj/RIiELfbrgC6FQP8ccVAlEPGUg4+udXAujgehUzzaeG7oGt9/VOk8r3hRN2UatmXObH8HGi1Hi+Dz/rl9lz8Z0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk; spf=none smtp.mailfrom=armlinux.org.uk; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b=cbP0GUWT; arc=none smtp.client-ip=78.32.30.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="cbP0GUWT" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cW1i2nsSqGec664NhqCRjOb/CVuLPA/uupdfC4+Q4iM=; b=cbP0GUWTecrX6+QzFTOuGrg/ML sP1WAqoiMgHkO/UfOpf1RP6G7STdApB9Sqa5Q2j5+DumZDSKVgTAHcEvdVLNdQfUyfOPeikXydS4F aIO83IvQVFHcJHa9wVDa8zDuDbfoAAVU4soZ9ZlICSDvwByhTuou2aMTR7N82NsFXrMHpV2RZ7UDQ vPjfLEmWKL60siohRItl40x5InPPmgvilMzheygahePYah/p4EhCuuJm3OvSVckq8YtdzTbUCFB9c QtrdnqQdkd91USgiGA6nbDOJkX932vct6mpiGJvuDrbZSOZOKlGUJwjR7rElglPKtTjxPr1qBu2fk cGFXXK9w==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:47092) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wh7oW-0000000013B-3tY9; Tue, 07 Jul 2026 16:34:25 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.98.2) (envelope-from ) id 1wh7oT-000000006oU-389I; Tue, 07 Jul 2026 16:34:21 +0100 Date: Tue, 7 Jul 2026 16:34:21 +0100 From: Russell King To: Lorenzo Stoakes Cc: Xie Yuanbin , akpm@linux-foundation.org, david@kernel.org, liam@infradead.org, liaohua4@huawei.com, lilinjie8@huawei.com, linusw@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@suse.com, rppt@kernel.org, sunnanyong@huawei.com, surenb@google.com, vbabka@kernel.org, xiqi2@huawei.com Subject: Re: [PATCH v3 1/2] ARM: mm: fix use-after-free in __do_user_fault() under CONFIG_DEBUG_USER Message-ID: References: <20260707131409.79043-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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: "Russell King,,," On Tue, Jul 07, 2026 at 02:20:19PM +0100, Lorenzo Stoakes wrote: > On Tue, Jul 07, 2026 at 09:14:09PM +0800, Xie Yuanbin wrote: > > On Tue, 7 Jul 2026 12:57:45 +0100, Russell King wrote: > > > No. This information is useful debug for kernel oops. > > > > For kernel oops, I think it should be `!user_mode(regs)`, Qi Xi's reply: > > > > On Tue, 7 Jul 2026 19:48:12 +0800, Qi Xi wrote: > > > For do_DataAbort() fallback: > > > > > > if (user_mode(regs)) { > > > if (addr < TASK_SIZE) { > > > mmap_read_lock(current->mm); > > > show_pte(KERN_ALERT, current->mm, addr); > > > mmap_read_unlock(current->mm); > > > } > > > } else { > > > show_pte(KERN_ALERT, current->mm, addr); > > > } > > > > changes nothing to kernel oops. It only skip show_pte() for user-mode > > faults, and the fault addr is a kernel address, which means a user > > program is trying to access a kernel address. > > I think it is reasonable to skip show_pte() in this case? > > Well the whole reason you're faulting here might be because a userland process > did that right? The page tables should tell you (presumably on ARM32 :) > > And I hate to repeat myself, maybe you didn't read the whole thread but... just > use mmap_write_lock(), this isn't necessary? > > What is this trying to achieve? > > You're not in a hotpath, why are you bothering to conditionally take/not take > the lock? Unconditionally taking the lock could lead to a deadlock. Consider the case where the mmap lock is held, and we get an unrecognised abort from the kernel. If we try to take the mmap lock again, we'll deadlock, which will result in very little debug information being output - and the system locks up. The only thing that would save such a case would be if the user had decided to use a hardware watchdog, or is physically present to press the reset button. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!