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 99060C636CC for ; Mon, 6 Feb 2023 02:51:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D0EEE6B0072; Sun, 5 Feb 2023 21:51:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CBD666B0073; Sun, 5 Feb 2023 21:51:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BABE06B0074; Sun, 5 Feb 2023 21:51:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id ADFCE6B0072 for ; Sun, 5 Feb 2023 21:51:28 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6F0C1409DB for ; Mon, 6 Feb 2023 02:51:28 +0000 (UTC) X-FDA: 80435341056.30.94B97EE Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf19.hostedemail.com (Postfix) with ESMTP id 822D11A0008 for ; Mon, 6 Feb 2023 02:51:26 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=aYT+QrxD; dmarc=none; spf=none (imf19.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675651886; 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=a68BFUw2BpHHhbBBpKoKjQxP6DmREgGnYtbae7m3l1Q=; b=ud5OXhNHKj1ZkhOkGMOf8IHcgxyjGOvIfifwHt7WflQESIQQAevdDY2kkI8XtEkMjKozun as5lxBtE/myXGJ8Vn2Y9Q3YIstZaaP1nyinscKYdckqHNuFBqdnJc8OW2lxbT5oskme2s5 1oJIV3lUIk4PeIE5AzdcEWcKchpA0iI= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=aYT+QrxD; dmarc=none; spf=none (imf19.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675651886; a=rsa-sha256; cv=none; b=KkNh2aKwfACSQY+RIXT6Q9Co7S7xJEXsUyzevzZ9KY9i5HVodSrR+AoriHoVVe2wTCiN/o d7fymR/u6pipBj1UJYXw9GZJ+yyWLB5CX00eJUtg8DUU1I9aX+6v+UMNnThMSzBKtBhkRr dqp3aWIijjc0IQcMdQXyBr9JmRjqHDo= 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=a68BFUw2BpHHhbBBpKoKjQxP6DmREgGnYtbae7m3l1Q=; b=aYT+QrxDV/CJmRjX3L9wcJRC5m CZlCqoXCfhO/WEJsGuKY1Z9qXzdXkMZ3Xua+ucsm1J14JHSdLYjToJbnmkCK4mONdNLiLdxXLm0ci qqPox4IGi7FK7DKbSb2j2GLLwxpoh5M+Hc99CNpXotONm6MCOj/RziZRIcXaDWf8qr77OD2zm0diF 0y/g3Guz8DA09pVrGCQ61UsKYxNWJ+zPNggySjJz/vWgmOVwUQTpL57PWzMLwNrtE4lhOBIU9NGs+ TBXzcoW3ezmVKVlFqEqfWqj5yiOqTOQk4nxLG6Zm0cr4qA0cFi0k9AUhoqmvMo9OMsE/Pj2iOSF2C 1egmrvew==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pOrbC-00GPQT-HK; Mon, 06 Feb 2023 02:51:18 +0000 Date: Mon, 6 Feb 2023 02:51:18 +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-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 822D11A0008 X-Stat-Signature: bj4k3ydrajdfse4inabtpq5npfz69rta X-HE-Tag: 1675651886-722834 X-HE-Meta: U2FsdGVkX18PZI65R6rshQcb0mm1cekKzpGxfjacOgGIypLkOwjTN7Ahj9eZCCOCIsb3znz+draochFAUk5tNLEYLhp1f91S7elZ5lxHVhfl5ijQFOC3YOr+NdITWm+aG1zCWSXbRcZyiePzDe/QWF3AVXSckhOWrqIQ4wTvAZFI0GJ1wsiUnJBDFCj6hcF3OeX13QRZGNuyXXmX1b2zECeCT+0zjIyWJHvo9i5S6Q9cJ0jCduVAxAbzFFjpsm3SF9FF4UVs1t3fZQQugaUwXONPsA1St2jVPZ59zBDhuUMOBmyzu4/EEi+Nj1P+UUnuDQrE93E1GtWuHbA38UuiaiTdOQLDnqZN6pf0scG3m+0Dtf6fR5snM3WbUTgxba+LWXLTuOTM7uZRM52zitXcb2DZWzO504VJqgHJLKM23E/Ub5ejzMmYQTDktQYsxJ3My4ynocxMeVs5lkron3phuEb+VDVubVwlT4wWc4HfGP1xwVMLFYl03pOMPC54Bmf4Ok3HLZuMTrteuPcVScmpPoJlC2jKPRWSaj4bg8DIh2RMs0FSc9apc2EAaIzhmknUVeC9rAYcQskHR5Ei55lNxt34tIn0gj8a+ZzMF9s3mmnwk/D5DzU18fw+f72zq0E3IAtl3t+Ytq34R4U0tnwK8FfjLyWkfBIiVVDSwuJbnYbv7Zs7Y9xp3Vjk/V6qW0IlDYx420CLnHLdQiPBVLdP2EvFQNfWc133gmF212qm7hF76RyANTNVI+t0lPSlVjVwulya8yWTmqOa7c7AGjCtEJWiquy0aLMAkWIG17FP3s3tTUY/hId5zOdkNgRpEDYJV7G3X6WA/Cs1AjDWyuRJF15hy4m6JW926qqyLW76Z9GMe0/AVOFA5pdzVzL2yJ2xYzKTYV1vp4QKAbFVWiLWIh60hC2C37Ph5de1kNmfgPXJQpT8NZuCCYNXR3kdxgVNEcv8IpDNxBZE2Aot76J lN9xwQci qIz1KNbH1bz79tKsKnUYjhiXpmhCcZR4ILmIzPTsDFlzUvpfbYRQbtV24LbGuKDwuxYBAOoPGg0721hbhvbcuRs4vbTHMxAV2MizMQmd6uPObgC7+mXFyREBClAPsbqkVRZcXjphu685UwElajxexRRxHP0bk92qY5MAqBi4Hlwts/8+iixw1NmnkolLAJ4nc8ybjMEgyMJ7YzJs= 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 07:54:35PM -0500, Peter Xu wrote: > On Mon, Feb 06, 2023 at 12:10:53AM +0000, Matthew Wilcox wrote: > > On Sun, Feb 05, 2023 at 06:17:01PM -0500, Peter Xu wrote: > > > I noticed a few collision usage on VM_FAULT_* definition in the page fault > > > path on arm/arm64/s390 where the VM_FAULT_* can overlap with the generic > > > definition of vm_fault_reason. > > > > > > The major overlapped part being VM_FAULT_HINDEX_MASK which is used only by > > > the hugetlb hwpoisoning. > > > > > > I'm not sure whether any of them can have a real impact, but that does not > > > look like to be expected. I didn't copy stable, if anyone thinks it should > > > please shoot. Nor did I test them in any form - I just changed the > > > allocations from top bits and added a comment for each of them. > > > > This seems like a bad way to do it. Why not just put these VM_FAULT_* > > definitions in linux/mm_types.h? Then we'll see them when adding new > > VM_FAULT codes. Sure, they won't be used by every architecture, but > > so what? > > My initial version actually contains a few VM_FAULT_PRIVATE_N there, but I 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".