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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73E59C636D3 for ; Mon, 6 Feb 2023 05:10:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BBBCC6B0072; Mon, 6 Feb 2023 00:10:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B6BE46B0073; Mon, 6 Feb 2023 00:10:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5AE46B0074; Mon, 6 Feb 2023 00:10:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 969516B0072 for ; Mon, 6 Feb 2023 00:10:05 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 656A0C08DB for ; Mon, 6 Feb 2023 05:10:05 +0000 (UTC) X-FDA: 80435690370.11.AEE123A Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf14.hostedemail.com (Postfix) with ESMTP id B9FDF100008 for ; Mon, 6 Feb 2023 05:10:03 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=nX9Af+4r; spf=none (imf14.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675660203; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=x/vaXmDiISQEbay077BGity4tzOnqmD7ndpsdu1qs8A=; b=grqClplifrMTCXRGvmSy5wvOLY8OGrQPwOcPc/xYH7Yy9LA3/2eWmuKejNUf/IwGR+bqAu QSKPhF+xdtrMyeT6+6Kp1c28HR1W08mtsogi84TJpUwXxgmdoprfEWitCkN9v3uOBMoyV1 Cj6tKHIjd80URX8fP8R1xcNrLyc5EK4= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=nX9Af+4r; spf=none (imf14.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675660203; a=rsa-sha256; cv=none; b=yAaIEM2zkAycf6ra4udABRUFZ1NJtR7zsIsxA86H9Kv51CdiIS+WVx1MsUr1m4YA1fDlcD RfRLqufv1qTw7BT+Q8n1SWzdk5CQnniivB8BNi0q7erXw7uFYOOX9DixOC9qXSt+rtYOW1 Ehdh9ANYDhpo4HIW0czBrAjEi6IgQ4g= 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B9FDF100008 X-Stat-Signature: zfx7pmtzn3sq7px14eyd74b6d73h7pzf X-Rspam-User: X-HE-Tag: 1675660203-867557 X-HE-Meta: U2FsdGVkX18TCWYevhc+cpO+KX3KOu7twzoUTpndV7dzX9ZEsf2QVNTUItiaET9lG45rTYbldKwPR+o8Gjpj2hTpouzUDLKk7BvVMD++XpQiKoTslo1TG0TSLO9Zqpdo9u0A1wSbaFv39W22lBm3OZlbAwKXPe13ROCsA3ozgUgWoTZCJlusAt6XcKrEhtd5EcpbtXNW0DiNDUD8KKgZeLHsBxSXYS3jFrDtrCdZ6RW8IKVZQrpd8tnBM6LsGHZjI1z2ZkfGIdGgxlGRAQ6ayzgORHFZQ8WiSODv/UkDU8dzOED0us6WaYoF5CqNKgnujK+SX8zdEMV3OYPXh0TTXOi5hyNZJp/A3WL5xm8tvwp5PAr3Ux8mKonkzHuTL/IpoU2ls/vOJJVy26xmUVxm8I3VP7bI1HqkTP4kNaqYR3dlmp/IbK34No2ytA/5jvYE7YPL82iT/GG69kiD0pICGyOT4Wr0i81MqbDia3JEvHXBvmmhLjDEEynTlMheYWx5efTOZ2K+oInJ/abBMO2ol0IwwQ7cYtTGz/uJxJv3vFKAqAnPhuI8olM0VmZBQLcTm+ve/GtThwMEXH3zsYYPXeNcYDcPYXJ7qv8T7+J9Ws1eITAV1s6B62nvedIr6b9nDK/pfStY5Kab3T8+5BN5DealeCpsf5sfFTSF6nF26r+58FOn4QHkuJRyICece2m0P+S2CHLdWNw22l6nQv+Urb1iYaUIs8omj5N2w2ySWuEXdMW5Th41DMqooAyoCFzyl0v9GOHDOTaBBtKbHwlS/GJ4H2JhXeijCMcm1xZWDQW6RU44lTg7p4gC3OAZaAJ9CBpUbHR0KRJC0K8MCLa9uTTmq+Gz6Ybsp5xBWmaOvI49J6g/yowbzPC5h38k9sTA2TdsiQbfwS9HbMcL8/g6AEpqv1VzY8IU49uPPdir6ozGAdaeDvpWSP7dpbAPiCmyQWeeCfRe7dWR90P7Hky +oJyqyH1 gSisr0G1MlsTaXLl7MMnmQDseQrEYXcEg8aWxb/ah+x5yq42q+KFoZQ6pPxF/bIPb45zKo+3vTjqVSVL4WBPD8URAi274HTOoihmbfGSN/YGMj0ETf63SBE/jr+18Nyz8nUiowvu+p9p0xlnMYLY0uAv/XyuVztvQ6PGAe13QumdiFOwqD6ingfFsYz38Tb1Jqn2w2JNttA4wvyQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.