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 5C990C636CC for ; Mon, 6 Feb 2023 00:54:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8F9C36B0072; Sun, 5 Feb 2023 19:54:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A9526B0073; Sun, 5 Feb 2023 19:54:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 771646B0074; Sun, 5 Feb 2023 19:54:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 666486B0072 for ; Sun, 5 Feb 2023 19:54:42 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 259D8C075E for ; Mon, 6 Feb 2023 00:54:42 +0000 (UTC) X-FDA: 80435046804.23.7876EAC Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 6B4BA40004 for ; Mon, 6 Feb 2023 00:54:39 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=G9JFiVxP; spf=pass (imf11.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675644880; 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=RtOrxUe6MXUilzi3ALeyX9aNN6+6Dp+de8fvauQCp/I=; b=tuQm4K70rAtSGOXDiSmT/KvNRVo7w5TZW/lRMAfPkuIEVokwGLKQeXbDn6ZrfvGnJ7jWDm yK2OzDNxKNSNKi0iI7ErX5wBz90uf5ryTiYQzqcUE605JurNn/7PWf3v4dYdo+TxAg/2AK v4PsEOFJTnLzklTYM8nsTW36vBB2JmA= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=G9JFiVxP; spf=pass (imf11.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675644880; a=rsa-sha256; cv=none; b=r1NLM+cZcD/NTlr8vkbQs6XWrJ0mVnPpUUTZE5tSzPkO2H0SLBgMPUyXrQ/n0tEKvcAsXm aXCGNbAr/34McuORduX7W8deeEXaNAlIQKo7pQS6JntrHsihdpvcFCGO0V0DXp02qIhszt V+D6uZTNYb0Bvy445Lf6yK+n4abDe9Q= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675644878; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RtOrxUe6MXUilzi3ALeyX9aNN6+6Dp+de8fvauQCp/I=; b=G9JFiVxPs5q/s63txvl2f4hTfUAGushOMKHV6tcRKGDnjsS7BJqtvpe4McIzCkJR9mIoMo 9jSmlg7LjvKwGferUc1CeMh/QMLBbmkHD4zx3Jf0jGLbIdjYzqp40Qde0CAvCzRMhPgFqa AV8h4UJoixfBqGa7+DmYHGrpTdUhOjQ= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-313-cAX4tiLxOlmpHHVH3IoJ5A-1; Sun, 05 Feb 2023 19:54:37 -0500 X-MC-Unique: cAX4tiLxOlmpHHVH3IoJ5A-1 Received: by mail-qv1-f70.google.com with SMTP id pv16-20020ad45490000000b0056bf828babfso469925qvb.23 for ; Sun, 05 Feb 2023 16:54:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RtOrxUe6MXUilzi3ALeyX9aNN6+6Dp+de8fvauQCp/I=; b=dTQZxJ1ur+hqOcdB018Qp3Wf1Pis1rn6erSLY1ZXbX2bUobX2LoNjsyd+YfT66KduM eQ/6zfQguop3sAGqproPzjWiHyyIN19FpbMCHmPsKuQJFOKnlXwai2tS/1OlcfbBj75Z /qkTn7IT9qNb94PXvPdL0U8XfD7vODRlBjrA9veEMVDt3tP7Q5FRMC9eY2OR1bLzPW0k SSjXq4c3B1GFsxv01u14mqxBBadBCinaJ+a315BPrbAxGcfJ9sSktuOeTP0DX6yeNQaY +fLTpD6OJSaqon4BVzClAdDIV2kW2EdPxNU2BU1OzO9rjpcap/LEVKnB1M4VaHyzD1OJ 98FA== X-Gm-Message-State: AO0yUKXzANhIIV+TWqjhoJyXA0XEItMW9/2ZQ/9fEahCRk26TMkYKYe2 8/y2vbBNLJ81ExyKBsJxM4b5Qjj6hEjcKdTCt8qhL3qWgN9FK0ic6fmGDtDQWXzJWhcl0gb9VzY 1Kd4Q/bhbmVs= X-Received: by 2002:ac8:70c6:0:b0:3b8:6d44:ca7e with SMTP id g6-20020ac870c6000000b003b86d44ca7emr30245546qtp.4.1675644877148; Sun, 05 Feb 2023 16:54:37 -0800 (PST) X-Google-Smtp-Source: AK7set/bBn9Wk9zrv600E6sElTcu40EYMTtlJ9J9a7mc/Qqbw8vjmF+ThB3qUAXhFvwAv8oykMT1bA== X-Received: by 2002:ac8:70c6:0:b0:3b8:6d44:ca7e with SMTP id g6-20020ac870c6000000b003b86d44ca7emr30245533qtp.4.1675644876816; Sun, 05 Feb 2023 16:54:36 -0800 (PST) Received: from x1n (bras-base-aurron9127w-grc-56-70-30-145-63.dsl.bell.ca. [70.30.145.63]) by smtp.gmail.com with ESMTPSA id pe4-20020a05620a850400b0071ada51ab48sm6441832qkn.37.2023.02.05.16.54.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Feb 2023 16:54:36 -0800 (PST) Date: Sun, 5 Feb 2023 19:54:35 -0500 From: Peter Xu To: Matthew Wilcox 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 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Stat-Signature: y7fduwp1x7ng1a34sufqkfsqdk65iikw X-Rspam-User: X-Rspamd-Queue-Id: 6B4BA40004 X-Rspamd-Server: rspam06 X-HE-Tag: 1675644879-418897 X-HE-Meta: U2FsdGVkX1+JyvihmabzH+gSs+IDxGAZXrYStV0G2kTZw66pxNv/mlr8zI4VPX73XEeXzVqkrPVl+uJGVyC+NEijYnTlx8/nRZ0gxHRwY8ZZjqN+tziSU1AXn3y95x+OOr0ZT6LiZrH7creiG9o8PFvwlB2Z6XJ7uKtS0kQ4jFcMN5x0IIJQleE7WUfGVY0Vn1KmIG3G/FJCkKuqX3GI2hmlcF5RZZVwaPcCnjc/UEvg7HXvU3RJoAP2+sCzz4+UTKjRep1ztGEcAa2N/LJKM48DRPkRYbbpgxxxirzRjnk951/TsoGUTEeBOio2rzvdTp+Pb2zERLZwXaZvcKNpaWe4/wUvV7dsYVzdHd/Hg6mAA5A3NplSCy1O8gWvtRtlVIOWUXVZ6ufBxEBhpPJ/kRoo4tmRbozUf4HNRnUaaLft7TnQvnMk3ahoYc4Gtw3/wgwB3tpG8TgfCK5VcWM6bJIVon9ecGao4cDq1yK1ShfvRPE+/6Qa6ilTIzn3vJZJgUwFZmRHV4TV/A3s8MQJ5/4Jq7enCspYCwRCJmnxZavXSOBcTkC6yJIk3FTsvLgwL0pJwfCQVoRxBxSsjNk9jng+9ssRX+1W1tcjd7UBsKz0zLCpni+vwsysm/3s9YG9UCe+T37R/vMaoStpdqPHujdFNNufU59bpCx63aNKcvV+PNk+NxjPed0rfIe0J6F02cnaIelq7nKa5d6QTOF/vSLJ7RCl3xzLCMJQUUruODq6MbwEwC53+OwILIDRgAWS563e91/aLyjH+Ovxrxa6DrTm3Cxg19CKjOevUSYH4S3oZfXp52ucnUwaBun3waqgoWHagRa6DooMbZVpu3CNlR64BDH5MLJ6TzagMsdrieBxBONk4/ryx80118xe47/wAhMQM+0ozZKSXIB9a54MNxhCelfeTZ9dK9ofzZtyqxRcE1Gk25wRSEcGzGHtr3ZEH3utsh57Kn5Wd/NwjDK ArgfpIQ1 x3kzJVuEiqQK8oqJ60c8nyJBpSR+PoDazYVSDXACxHSvB9KCxVxB3D06AbvGEzFBJyP6iYycH6mhpZjceg4WPZZqvX0SJC1lGFUhqGlecQt6gkKaHUfufBrMF19mo+Spn9csJ/8uq/YpizCksGeH2IG8AskvT5wEVvUUTtHy6Dpgz2r4WVTC1sGDvjzKDGY9XVuB9+fm8SNcXN8KnZjZP1B+ZVFlUQz+WqHx8DKGEQXq3URCdPaasVRZ+29IEdPaNudTL66tCkXtxP/+h3wjutrxM5YYXU0kYt+84WS14hXei+dnv9qFq10qHO9KO3TKNA0EsxmgObubktXbqdWpfhos2ziQErhcxem437H434Hj4gSkwkiI61bN00GKe9JpscA6fI3D4rP7UOS06B4S/sso5Nn2ximvQYOUvl6SEJO+UlhQ= 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 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 noticed only the minority uses that, especially there's s390 which takes 5 entries. I didn't had my mind straight on which's the best to go, then I removed them and posted this simpler version, with comment on each to fix the issues, more in a sense of raising the problem first. I agree it isn't a problem at all, not until 32 bits all used up. But that seems to slightly encourage more archs from using the new private entries which I wanted to avoid. If to take a closer look, we may not really need that much private entries. With s390, what I read is: - VM_FAULT_BADMAP could be replaced directly with VM_FAULT_SIGSEGV? - VM_FAULT_PFAULT could be replaced directly with VM_FAULT_BADCONTEXT? Then if I'm not wrong we can already reduce 5->3 private entries. I didn't directly change that because I am not 100% confident and I can't test them myself. It'll be great if arch people can have a look at either s390 and arm to see whether there's chance of simplifcations first. So the patchset is more of raising the collision issue first, meanwhile great to attract attention for arch people to refactor upon it. I can also try to reduce the private entries and introduce PRIVATE entries accordingly as you suggested, but I'll need more help on reviews and tests than this one. Thanks, -- Peter Xu