From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 180F7C636CD for ; Sun, 5 Feb 2023 05:11:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=jwc6OUZnusjD9Eus9mzSfeHS9JiX4G9yCEw94zMT1XM=; b=huEf1VA7sv92LU V7JzL4zs6eutDb41EEbJm+uOerYtCZjMls8gQqlOrGnyy/p8EAMpD/uBSv9+kn+TaSGFgOVMZt+yu HYnzHL7pBb+raAhB+AmljreYfjX4Xfbc6wweiLJfgeAF0+F6H24fM4J4ztqZ6A2ex+uPkScoz8tC0 MAQoYrFW7EJ10tPoxCaL7CkbgoXK1da8UZx5uLx5OIEcoiXCJ1oByW4geq/RLbOdNRmQGrWgbLaZ0 /mDYSimpfcG+u8XdpVPz+yJBJBFQPL88AObncbrbxIaOhnFnPcdV9gdpklfo53bWzqOZSP4rHwiKr N1fOeHVlPcs2YiwRS/BA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pOXIa-005zva-PA; Sun, 05 Feb 2023 05:10:44 +0000 Received: from zeniv.linux.org.uk ([2a03:a000:7:0:5054:ff:fe1c:15ff]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pOXIW-005zuZ-NU for linux-riscv@lists.infradead.org; Sun, 05 Feb 2023 05:10:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; 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; bh=Tr6hHp8aMuyix7W8MPsJcy4qd0T+bfV4ku4SlFkeikM=; b=IPFSEa3/kiVAIcszhJNII+WRya neT68DS6Txm3V+3RoFqVcUT8ACqt2krppBrR0nE0MhgP5v5mx5J+FkCtxLK4NuL44MCdybBXJ3tiE BCK8F3NrQgjudmCQN5DOg8ilOhP8rpQA4KGJCr/zYnDwePVNc7hXeYxhSu01Hl/Whg14RPN+t+Qjn FFeEglPsiR3VQu2OUXAVKINJi5E1JXxnZ627BUZs2iReC5LcTJ5xUmA3LYosBCGyMtMSiIolQQlFF qmHMDBAt2OmyN2m/y5BLyEfjGG8PEi8Syc5yKEtFHYC8gaQDfjK0zoT96DVm80gtbJv84vXLTwm54 +Fpb4OAg==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1pOXID-006IcI-2c; Sun, 05 Feb 2023 05:10:21 +0000 Date: Sun, 5 Feb 2023 05:10:21 +0000 From: Al Viro To: Peter Xu Cc: Linus Torvalds , linux-arch@vger.kernel.org, linux-alpha@vger.kernel.org, linux-ia64@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-m68k@lists.linux-m68k.org, Michal Simek , Dinh Nguyen , openrisc@lists.librecores.org, linux-parisc@vger.kernel.org, linux-riscv@lists.infradead.org, sparclinux@vger.kernel.org Subject: Re: [RFC][PATCHSET] VM_FAULT_RETRY fixes Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230204_211040_789100_7F69A4A6 X-CRM114-Status: GOOD ( 24.11 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Sat, Feb 04, 2023 at 12:26:39AM +0000, Al Viro wrote: > On Thu, Feb 02, 2023 at 05:56:22PM -0500, Peter Xu wrote: > > > IMHO it'll be merely impossible to merge things across most (if not to say, > > all) archs. It will need to be start from one or at least a few that still > > shares a major common base - I would still rely on x86 as a start - then we > > try to use the helper in as much archs as possible. > > > > Even on x86, I do also see challenges so I'm not sure whether a common > > enough routine can be abstracted indeed. But I believe there's a way to do > > this because obviously we still see tons of duplicated logics falling > > around. It may definitely need time to think out where's the best spot to > > start, and how to gradually move towards covering more archs starting from > > one. > > FWIW, after going through everything from alpha to loongarch (in alphabetic > order, skipping the itanic) the following seems to be suitable for all of > them: > > generic_fault(address, flags, vm_flags, regs) [snip] After looking through other architectures: that needs changes. AFAICS, the right approach would be to add a pointer to (uninitialized) kernel_siginfo. And let it pass the signal number, etc. through that. That way all "we want to raise a signal" return values fold together. *IF* the page fault wants to do something extra on SIGSEGV, but not on SIGBUS (we have several such), it can key that upon info.si_signo. Speaking of SIGSEGV, there's a fun situation with VM_FAULT_SIGSEGV: 1) Only x86 and ppc generate VM_FAULT_SIGSEGV in handle_mm_fault() without hitting WARN_ON_ONCE(). And neither actually returns it to page fault handler - the conditions that would've led to that return value (pkey stuff) are checked in the page fault handler and handle_mm_fault() is not called in such cases. 2) on alpha, hexagon, itanic, loongarch, microblaze, mips, nios2, openrisc, sparc, um and xtensa #PF handler would end up with SEGV_ACCERR if it saw VM_FAULT_SIGNAL. 3) on arm, arm64, arc, m68k, powerpc, s390, sh and x86 - SEGV_MAPERR (except that neither x86 nor powerpc #PF ever see it) 4) on csky and riscv it would end up with BUG() 5) on parisc it's complicated^Wbroken - it tries to decide which one to use after having unlocked mmap and looking at vma in process. As it is, VM_FAULT_SIGSEGV had ended up as "we need to report some error to get_user_pages() and similar callers in cases when page fault handler would've detected pkey problem and refused to call handle_mm_fault()", with several places where it's "we had been called with bogus arguments; printk and return something to indicate the things had gone wrong". It used to have other uses, but this is what it had become now - grep and you'll see. AFAICS, all checks for it in page fault handlers are pretty much dead code... _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv