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 4CFBFC636CD for ; Mon, 6 Feb 2023 00:11:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8F12D6B0072; Sun, 5 Feb 2023 19:11:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A1406B0073; Sun, 5 Feb 2023 19:11:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 791586B0074; Sun, 5 Feb 2023 19:11:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 6C5656B0072 for ; Sun, 5 Feb 2023 19:11:03 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3647B12049B for ; Mon, 6 Feb 2023 00:11:03 +0000 (UTC) X-FDA: 80434936806.11.4E48D19 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf02.hostedemail.com (Postfix) with ESMTP id A07F480006 for ; Mon, 6 Feb 2023 00:11:00 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=wQwn+cTY; spf=none (imf02.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=1675642261; 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=rGSaCbdLvJLIXU4diqo8Az/pvlwzPHqyC8mVLdkgmVs=; b=DREfmLcF0rIPQkNNZMpCT4t7tWju+pkPJVd9KiioRirY1mW4XXSUuftXoganNoxRBfx3za CYehIFT5YfsaacvHQPZr0UD8Nn74XypcWXppgu5i78+DBuKp94DcZOH6gvJlk6Jj6D+7qh mMCXNVTylAAdqKgvNPPq3epWTdRyLCU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=wQwn+cTY; spf=none (imf02.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=1675642261; a=rsa-sha256; cv=none; b=34ZJodAw4Q9jexC0EzUFay8TlSFfrQGypBETicuJvjBCH6cJpoDGxl7U7fEczyQWy+u7QD P2lUT+oe/4trFcTX40nCCaKRfG3NdCWrP+eJBAl1NqYBjhRzgfGhc/RnL2vcy9xJjRfwLw u3BSq+v52Hn/4LQS4Csz6FE3eWbKYMU= 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=rGSaCbdLvJLIXU4diqo8Az/pvlwzPHqyC8mVLdkgmVs=; b=wQwn+cTYGhjeIQzkhRGa2nUWly qYw+9p/37SKqb+atz8pOYcdUXhEpdCm4hpif6nv5xWdmZ4IPvrilZjWRNA+Wqtf/vuG9djjBMGX4t Daee7IzYAIZh6dMwqOftfSAlIXLk6lFLaaX6VHpRGZ207Xf/lA1BV651u4V5zIA1QLMikOzYRHNmf b0usFOi4WDyAPKftj5wTS/OyxHd+7t9ljT2PfT/Upl4noMYHLabBTRNnrOqjV09ETRIliFyCIx1r2 kmVArxQgmKVg1Htm1C5fQPwobTOoR1LC+GbwKJBLA+qJck/Ede5ly6QoUBmLkL6dKtZlKHj60xTcr VUCWbhOA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pOp5x-00GJrn-6g; Mon, 06 Feb 2023 00:10:53 +0000 Date: Mon, 6 Feb 2023 00:10:53 +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: <20230205231704.909536-1-peterx@redhat.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A07F480006 X-Rspam-User: X-Stat-Signature: ooe5b3ypcgpnjc8135o9q3wjj3ihbs6h X-HE-Tag: 1675642260-429183 X-HE-Meta: U2FsdGVkX1+LTjOz/frCrJDUhadOvZ0gh42oCbNGb4Qmq28e0Ox3gAqH8u9TJKDuzKkuSz2FATugeaoXN4Wu9zH/2Ihm3dXiC/RRKO3mE8ES+cq8/gE2wStSHX9CL89ycec3sKCbGHRZZ6N/4RMu6f2ykMD9o3GipLjC94vrGdlT3k6gnySs80LKuFR1QAhmun2ZZrL25rXzNy+CF1feuJ3saD2usnWRzp6WUweIG2IYG4nhPwLDTZ4ZpJiKm9GMbAC2Gdk+y9YwJXKewoiYsJNqGHTDO8VHNxWDavtJ0M2p3CXOvweNlwUaS5LTBa3ayRZPO7BMXbWE14+4X2ATewdBp7hfkqDy4diPaGpxhJv6lbx6LgKxxWZFFWYRlHIOqMYTrY4ALMLCJVWIQkP9BHBSHjisyrs0+E/YgPRo5f2qlxjimc/rYO/ELuU9kEEIt17UQlYeHMwEBwODd60ADdVPIvj1nSqm+sGbPPJMNdss55l4y5tgDibyXdCULOdDyhCtUVJeHg7utWDH4WdBv65hgrXN+jdTSf8+xun3VVhv86al019fxz+Zum9WcAl22Yu3YdwWPGotj0QM1OveTgDmN7PJu4imnNR0I6m8oY2XFTxamxxICz7cRlJwoH798DeAhrEopSxPKXp4lvxJfdSZh2RQlOag6kLu5AmnwheyiaKeqa9G7KCy/9QGlkO2Yk5PiZyHIPkLKrmVyEWJCfBez2W/ZkeBAppKeaXxxVF4fz4tDaX0yv+V3yNiCNVb3Wtt+8W84fP517X5Jw6rYstHhGt5DHaelBZmHCQaIK+muXyCn9jlIFtyT3HbmiGJjqWFnhmbVGbxJE20mdc9uRbT5AP3380AACHIdBeb2Hpk1KyldR/xeLaGFg0yEUQUXdDx33yyCjcfAGp9vgnFfl8JjbugSwwAgHGP4zbOuKsTS5sYvW4a6CXZIB70VyZihq4rAVwRjTAkh9CN/is nMgksmQx 69DtDPofvIDHT0Wr0qwzK3q5+rjuORsCE/ycdm/Qfnxv+EE0YzcK8kkj+nFRKzsKPvoToL0aBwSixMNRaJ5cDOOe2s+WsiLuLoeToJAIn6Gl+IcGjxsCT+o0pdDIIr015dDt+E3jkKpL5ZQw0qF7xWAiFxASslK+Ib7i7Yh8MyvWGMZqOJly+yWD8uPepln2WmDhIiLP5vc0JhEU= 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 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?