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 A6B75C636CD for ; Mon, 6 Feb 2023 02:52:31 +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=0ZHvR35THJ3bMBTcam1mJM7llSIAgZo9+hrHO1RNTyM=; b=MqfpBvE0GKooQO JZGWYtWf6i3C/E4pQ9HmhEFcezPTQ7yXjXKlJYZNmHoPgZ9PmM5XSUATJJZ/2Jg+ORlqTRMrqfNsd 2Q8MV9I28aOCOBk5aB4DlRT1m3ZU8Fw9mkQ1DRb6sQ1LtZ9FwToMZ42Sgtz7EKeuGvwBPotqH5So7 Jb5+L8n9QU3jVlT5mAvWm5Sp0a6FlWtlSA9gxy9OxhraNK4VXRmv3hzYRji/D3ujkFc5h6ZUJQ0zJ 5N2plwbYaezeoXZ+/23j1NPIW2fktPLhaGBj+Oa/CcigIVaMNI0Xvc6DonuB4L9rSlJCqoCRDFXCN 3ZntIlGedfLyK28fkNjQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pOrbJ-007DZQ-Iy; Mon, 06 Feb 2023 02:51:25 +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 1pOrbH-007DZE-Pv for linux-arm-kernel@bombadil.infradead.org; Mon, 06 Feb 2023 02:51:23 +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=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-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 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". _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel