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 811B3CE79A4 for ; Mon, 25 Sep 2023 22:11:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 06A5C8D0041; Mon, 25 Sep 2023 18:11:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 01A8E8D000A; Mon, 25 Sep 2023 18:11:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E27F28D0041; Mon, 25 Sep 2023 18:11:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D1C998D000A for ; Mon, 25 Sep 2023 18:11:17 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B13B7160D07 for ; Mon, 25 Sep 2023 22:11:17 +0000 (UTC) X-FDA: 81276516594.16.D9891FE Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf26.hostedemail.com (Postfix) with ESMTP id 151F2140016 for ; Mon, 25 Sep 2023 22:11:15 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Y2Qe941j; dmarc=none; spf=none (imf26.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=1695679876; a=rsa-sha256; cv=none; b=Mg2HoTkvKK9wgmf7P001mnGl4I7RVv+dg1BXaW27UaLW3EgLUnpJVAHaorHTIbgCY85Dkh xr3U0A3zp0FVff3NyI6L4zhDaAEqfNGoFgpftGKMeNBiMybNHqA38CZ8nN1NitHMVhjQgl bFPeYQDNL9IdFZPt+gUoEuG2jRX1Lrc= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Y2Qe941j; dmarc=none; spf=none (imf26.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=1695679876; 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=m41YmgAlvlgZpwnL0qQM2KGCyZY6OCsIZ8O/irEMgBQ=; b=yPEddDBcKTHdW+yHVPzSk4tu5J2gsoVj0B4CupcnrWxHqSelbFn6Jnn3q9+DbbM5+w4Rno Xy02JLFMoY5sv0wENqzU80W+LAcs0pMh8d5/sLmYS/BLQj2EOZNBrJr+K+8bXha+nVaPNP +R0cVUlDXNEdgI+6QZFC1zeP1P8BsAw= 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=m41YmgAlvlgZpwnL0qQM2KGCyZY6OCsIZ8O/irEMgBQ=; b=Y2Qe941jWJAfvz+rqON69Ejd3S nLm4c1FZo4i8LCQsjNv2joK9WKgWwsq5Gg3U8NWj3v1LEfIuIMXx2NVn93U6x5AtV50vCV7g9is20 5KjEQMpQ30BlC8eq1aCEivbzfAqNkI6YI/CEPvINIWcPylWmmUaqBo6pK0ACjVDxHGmx2o0ayiFl8 h49RqPmSICN+0uaOmOWiBzHiYO6OdrLZbc7RdcIPOd/oovJexnkm/zzpQcZN+Ou1Vq3hyJ69gFjS/ 1o50v9U7S9XRu8t8lQVjctB4xmlfWsu3u7NSgt/WYxdhnyYUhSfrGtv4zoE2YQAvFfKhQvw5HZ+R2 SVEtLn8w==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qktmy-003xxD-Dd; Mon, 25 Sep 2023 22:10:48 +0000 Date: Mon, 25 Sep 2023 23:10:48 +0100 From: Matthew Wilcox To: Hugh Dickins Cc: Andrew Morton , Andi Kleen , Christoph Lameter , Mike Kravetz , David Hildenbrand , Suren Baghdasaryan , Yang Shi , Sidhartha Kumar , Vishal Moola , Kefeng Wang , Greg Kroah-Hartman , Tejun Heo , Mel Gorman , Michal Hocko , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 02/12] kernfs: drop shared NUMA mempolicy hooks Message-ID: References: <2d872cef-7787-a7ca-10e-9d45a64c80b4@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 151F2140016 X-Stat-Signature: uu7ay8a15ecuzxr7sogaz5cps6xukgae X-HE-Tag: 1695679875-144661 X-HE-Meta: U2FsdGVkX19TWxlkkdmCbswIlwgl9ZCEzf0gsFpXCugYdJCdngtWpyxNxfcdYmv3VfPUFBrFCi1xv5uXYs/lVbxuQzgvhbpgHYE3IyKJW+q1d8QYOYDaJgQHUTPRKkaeDXOJe2UUIqRhHV93AIAN5URJDAy9io8M2aghh20o3YwllbQl9GsaFYkV55IFakRra96FB/Gq3AVJlFU2UJS7dwfukjeRLL9Ub17oOBimWgwJnTG2Icd6g3YoKuPSbAVe89/HR0LZaQEv8kJ5ZaB5Uz+DjvE+g4qA3HnXpizRXFoYjvaTUtm3AWW/LNP8y3TYfNiEvHNb/sbER360j/w1KNDeOCvnZrDZS8IbNC2GOiq+cqwbTh/m5Msn7G3AQPhgEm754yG4zK8VqfAmx7iPzJAZ8yfp4WB4E75LhIek0zMszhWF3FIfRl1DHAekx1SMBhYXM+hoXKqV/w9Qw8RYe8+8iGhLDwKAWkFaWj2lA5QE0Dg+FyTdS+A5QHMftAHahzWqfOnxhuBrQ6qrCZPRO3ULyL6CnYCKO22E121pPqS4MTUMm0zuFZTYO+peyBmnlRHOKmmPPfLEnkJVTDyXDBI0oaxpFGYpzOCapdYFhS3qxnwuvvNj4g+ZXpoctKLox5g/dV7HB1+hZdeMb/SWXpsOpI6TMM2Ey8fe1bWCvtsN9DwK4el9wW4rePojBDpdt+RZKGFYSO28/2aoXKOKJYx3mj6VOqvJaeuUaAmROan5tHIwpxFy3UGznpyjFObGIzBCq1+A087yDXYoFjwzYUpuGtgSY8I/F4QYOJlTuNVC4beEyXrmOKZ59pZ09mqfnr5r/yOASx7+qpJBGmv0wdTaklq94N4VBOFRkKyHyE/42kS2yRqt/cqypoaz8nwlEmO8C7F9AgS9e6eJHIPLZjJNOon+ysVzkpPuL+lEiPawXn+zAD8RoDzZCaGXPh7LOxouHYHafl/v9DTRJC5 K12Vy/+a J/a4tp2UYd7Ylt34ikbVv77bFIQJuzJ4yUGr8TVPmO+Cwpx3ckbVOd1zSOAK6Dx6cU7P4Sr2xwRwcF0Wp97/MPL2cr0KI/5HOBzurLvrfKJS3ZiNFoqwKrUpTco2Xwz0fKmslJoktO/rPCvgqQi0bjimGnlHUGvuITnIC5eIWL/JVdyPni0svHeglqoKuBROgNB8hVMpOK436KTwjY0Zc7nL8maSNhU7P694itUu51Tfoq3U9sMm5m6QH+6tjYLZzSSJ/QxmWAs6nG8SbdBUmTdGobwLnLcSwDbEq 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, Sep 25, 2023 at 01:22:27AM -0700, Hugh Dickins wrote: > It seems strange that kernfs should be an outlier with a set_policy and > get_policy in its kernfs_vm_ops. Ah, it dates back to v2.6.30's commit > 095160aee954 ("sysfs: fix some bin_vm_ops errors"), when I had crashed > on powerpc's pci_mmap_legacy_page_range() fallback to shmem_zero_setup(). > > Well, that was commendably thorough, to give sysfs-bin a set_policy and > get_policy, just to avoid the way it was coded resulting in EINVAL from > mmap when CONFIG_NUMA; but somehow feels a bit over-the-top to me now. > > It's easier to say that nobody should expect to manage a shmem object's > shared NUMA mempolicy via some kernfs backdoor to that object: delete > that code (and there's no longer an EINVAL from mmap in the NUMA case). > > This then leaves set_policy/get_policy as implemented only by shmem - > though importantly also by SysV SHM, which has to interface with shmem > which implements them, and with SHM_HUGETLB which does not. > > Signed-off-by: Hugh Dickins Reviewed-by: Matthew Wilcox (Oracle)