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 5486CC61DA4 for ; Mon, 6 Feb 2023 05:10:52 +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=GMAnTLfjYafVsfVl9ELcCANH9sUCfAN7RmUCzpG3ORw=; b=xf+Imxoznn4XUz Y5VCLnsLxlRknjND1f/NxgNR0wk+6WnI8k4ZLHceQQTkVU48CHDg6LiYtRUahf1LgZp4Ew7Z6UWFq SnTzvk+JY32c84XPn3e4YTjZzwI9vQjgGzPtx8LmlwJMsddeqCVsdWoHyLnoLG9poe8rWtI2tEgtg J4Ihzs7c7WTpJJiPK+xj/8w//ToaCzNSA2BQ94pQkIYzKeHqD9bsTSnjrU1Y39ZPLA8dP5YLtQZ9R m3cFpQx24qI7qXtb1wzmpsQB0H8CxM+l3Jqg7ZqmF167Niw40dWHy06zUxNrMic7QhaUy2DBfNZcO NDrvF6ALjqr/F13BJ8xg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pOtlT-007MoE-3D; Mon, 06 Feb 2023 05:10:03 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pOtlR-007Mnk-Ex for linux-arm-kernel@bombadil.infradead.org; Mon, 06 Feb 2023 05:10:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=x/vaXmDiISQEbay077BGity4tzOnqmD7ndpsdu1qs8A=; b=nX9Af+4rlwZgUZ6WeRrHLyGzDq 7MTeZhdMzCzQ80agG7XygW7yiQT7NcXxClU5K4oaHwppap+EL9b/ah6a5+UjNTAnyfK+/GlMKUF4j 6cb9mIDFnVRNqgkhwbF/1KQ8raWUVc/kxMjN0vTn8wKB/xZVOz+XcuSfcJk1yW34uwqXu9Ny+IK+W nPH7KjNi2JUxsixkNHQVocg/QlA8YKYxneiyzRAmmbxJKOn/3ZlYbIPLyPhaFtPtY+/7KaVcyw2RZ okpCyxtfa31XrApkHzNOk3fBt6SpytUFP0QAv9oW6+QXnnoH1sBlRORpIMowCfiEMtg1VRVQ0+SCm 1t5RuBUA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pOtlO-00GUEA-00; Mon, 06 Feb 2023 05:09:58 +0000 Date: Mon, 6 Feb 2023 05:09:57 +0000 From: Matthew Wilcox To: Peter Xu Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org Subject: Re: [PATCH 0/3] mm/arch: Fix a few collide definition on private use of VM_FAULT_* Message-ID: References: <20230205231704.909536-1-peterx@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: linux-arm-kernel@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-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, Feb 05, 2023 at 10:18:30PM -0500, Peter Xu wrote: > On Mon, Feb 06, 2023 at 02:51:18AM +0000, Matthew Wilcox wrote: > > That wasn't what I meant. I meant putting VM_FAULT_BADMAP and > > VM_FAULT_SIGSEGV in mm_types.h. Not having "Here is a range of reserved > > arch private ones". > > VM_FAULT_SIGSEGV is there already; I assume you meant adding them all > directly into vm_fault_reason. > > Then I don't think it's a good idea.. > > Currently vm_fault_reason is a clear interface for handle_mm_fault() for > not only arch pffault handlers but also soft faults like GUP. > > If handle_mm_fault() doesn't return VM_FAULT_BADMAP at all, I don't think > we should have it as public API at all. When arch1 people reading the > VM_FAULT_ documents, it shouldn't care about some fault reason that only > happens with arch2. Gup shouldn't care about it either. > > Logically a new page fault handler should handle all the retval of > vm_fault_reason afaiu. That shouldn't include e.g. VM_FAULT_BADMAP either. Hmm, right. Looking specifically at how s390 uses VM_FAULT_BADMAP, it just seems to be a badly structured fault.c. Seems to me that do_fault_error() should take an extra si_code argument, and instead of returning VM_FAULT_BADACCESS / VM_FAULT_BADMAP from various functions, those functions should call do_fault_error() directly, passing it VM_FAULT_SIGSEGV and the appropriate si_code. But this is all on the s390 people to fix; I don't want to break their arch by trying it myself. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel