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 C03B5CCF9EB for ; Wed, 25 Sep 2024 18:14:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1C1706B00BA; Wed, 25 Sep 2024 14:14:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 14A646B00BC; Wed, 25 Sep 2024 14:14:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDE386B00BD; Wed, 25 Sep 2024 14:14:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CB1456B00BA for ; Wed, 25 Sep 2024 14:14:58 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4D0F380FF1 for ; Wed, 25 Sep 2024 18:14:58 +0000 (UTC) X-FDA: 82604061876.02.97BD7C9 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) by imf03.hostedemail.com (Postfix) with ESMTP id 6F75E2000B for ; Wed, 25 Sep 2024 18:14:56 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=MOnlWaN+; spf=pass (imf03.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.128.44 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727288060; 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=Qs/OaRoXH7r4WJREprSEKPkU6ufEx25AKBj03vNjsoo=; b=26ZFKCM2Z4aQe9qrdZmSXrFJciz+FPJNs+Z3G7s/zDRMjYllN6VdcQuaD3cRdVhk8zQBN7 nF9OzKAdXZzk2HU2KlAQz1Rs6AoDgBp4jU8l4gFJTz1rEbam9c6DeMfE0ZDynCIwaSSWK3 52PYwL+k1rPAnhz9LdJuQpi+6mqEAzE= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=MOnlWaN+; spf=pass (imf03.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.128.44 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727288060; a=rsa-sha256; cv=none; b=URq8sYMRyrYzwORXvg04PaYVQnR3Fa8WqrauUhOOD+K6yDHQWEnjEK+oRPY3KDaKoCVGkn 2sLjfcV6NnaQ3c17zwJ/hjNdfErQL+5iDgdPSMTXArvslRdCg3gxnpmxeftwxm6OGPo3RO nq0xoF9GTzEAuduujb8b4b9QA/gxf0E= Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-42cacabd2e0so666635e9.3 for ; Wed, 25 Sep 2024 11:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727288095; x=1727892895; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Qs/OaRoXH7r4WJREprSEKPkU6ufEx25AKBj03vNjsoo=; b=MOnlWaN+lh/26D7Pf63ERmvkAMTnnj23qvTuAWkUuqnuPrK7Vsdzsxds3dnps7vonr U2+4VaiscSCm1aHR/TRDZStxZ+dpKPoKTZ8Q30U0ct/evVVd/+OG9vRyZ+dzOOE8E0tw Taqcn6+5sDQkjkA4aIJCBg/Ju02Yy54nWoD++LNwQf95bNZfsFdHMAw7PdsAC5Zeguk0 MN+vm+zbh4tpDhHC0n97yoHgz2O1+jWbv+GLnZPVm0vXP+aQju0bmXw+t9CFb3jYzY0k TEtjW5nRPJrqODRsJIijVB1kELqRPVW3swz1ZKC+GVfJbn0utUDy/5DQu+DWr8Rn7SFi lJUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727288095; x=1727892895; 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=Qs/OaRoXH7r4WJREprSEKPkU6ufEx25AKBj03vNjsoo=; b=kTjH7RYrzTv507XMCALe5ffT+Hq1yJTJer7yWmVuNF1sPh/FO4gYY/PGS+y0fkhRji SYLkyY4Ux49xKlxalBM/FEk3RgAqBr5BgkqTLk37Svsyc58OBU8ehEHN43XpWGCpPm5I MjHakRptJiQ9ebdKIUAvsRDac868kzTyg8NeAoNHeK44VhtJ+5LvhYkYNAo5jv1cOWfz eUCVnnBGNS2pQlnBlQEHcCwI4ubhKj+AvhPngcOHwlDcMuGdimm2h9oVmDIu1Ii/XMdC ulzLxYkixTrpFdpmfpKotU490W/Cu4eLvObK8K3I6AB8gx8ccH+cQOvLC7h64Bjgfpaa SIHg== X-Forwarded-Encrypted: i=1; AJvYcCVDOwFVJq9uZ88dD5SclYCtoXNPfmFF9dTJTt3pkV9k3BnDyHcrTvUVgCPm1IcWc7M2PcntluioMw==@kvack.org X-Gm-Message-State: AOJu0YydnllP9L9/13j6FqCPQcTpDVXEzP+7cBpMHdG4N2FTZ4mGuyAa oCWpzIobbkjnhBTE+jIpioWGlYzabB0eA1AXdNq6pNhzOGamYaHO X-Google-Smtp-Source: AGHT+IGw172XRvIlpNhc591coaXRGWw/ar0SMJ/7qKN79L95cpb2J1AIEZ4lhoV7s3kLF9nP8R8OAA== X-Received: by 2002:a05:600c:4928:b0:42c:bbd5:af70 with SMTP id 5b1f17b1804b1-42e9624523fmr24491225e9.30.1727288094608; Wed, 25 Sep 2024 11:14:54 -0700 (PDT) Received: from PC-PEDRO-ARCH ([2001:818:e92f:6400:a118:25f3:b27f:9f34]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37cbc2cf144sm4569012f8f.57.2024.09.25.11.14.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Sep 2024 11:14:54 -0700 (PDT) Date: Wed, 25 Sep 2024 19:14:51 +0100 From: Pedro Falcato To: Lorenzo Stoakes Cc: Shakeel Butt , Andrew Morton , Vlastimil Babka , "Liam R . Howlett" , Suren Baghdasaryan , Arnd Bergmann , linux-api@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Minchan Kim , Richard Henderson , Ivan Kokshaysky , Matt Turner , linux-alpha@vger.kernel.org, Thomas Bogendoerfer , linux-mips@vger.kernel.org, "James E . J . Bottomley" , Helge Deller , linux-parisc@vger.kernel.org, Chris Zankel , Max Filippov , christian@brauner.io Subject: Re: [PATCH v2 1/2] mm/madvise: introduce PR_MADV_SELF flag to process_madvise() Message-ID: References: <1ecf2692b3bcdd693ad61d510ce0437abb43a1bd.1727176176.git.lorenzo.stoakes@oracle.com> <4740dfc7-71da-4eb4-b071-35116288571f@lucifer.local> <7f40a8f6-c2f1-45f2-b9ff-88e169a33906@lucifer.local> <6b449c32-0954-4db1-9df5-23b766dc2d9a@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6b449c32-0954-4db1-9df5-23b766dc2d9a@lucifer.local> X-Rspam-User: X-Stat-Signature: syb7geqmb9mkh5igmdx4za1tzmeqy6fd X-Rspamd-Queue-Id: 6F75E2000B X-Rspamd-Server: rspam11 X-HE-Tag: 1727288096-567390 X-HE-Meta: U2FsdGVkX1/vmGt7GHel59Oy5dGGBw14P0VTzYjs1qLG3A7XTpnuwL+r9WYUb4FrjUVR1UpVlRXc6BwC6OAijUZ+gYEmji8LrpQTUMPVJkha93hga1IuqDjF2k3mRGpfRKPVuHSMnhbCFsonrKXjkI3U5Qri/ZHHbiKvd3DO8JzSNpX30NFUIXfdjTdcwFaMv77hYOFRLNdjp40wBI+A3BQFD4s9dRHlxPK/F6ldiWeoaFA2BOeBmnxF8kXzSwPFByQ25Gi+rEGwHYIpswytdWSjqG8cLSzG31828U5lKetMGgcM/B5YCAcjGITKExvVZaIapRyVSn6wGwypXxaR4VrXK8IW1XXTsFf5b2jbL/YBiafGDaTBBGswW0CeUUHwOY4Qdd2ZaAd7UHFnMVqrijgXrZwYPlAfN2oMZk4vJ+wNYDOHi2IFH3higRSgu38PUwzNyH66P3u2o0arcUtPRINLZ9fzXuoXlYf6F/AcTG1jArdPADYrjT0cKyMzaffJkBl59FpWKDTtk6qv1kqIif9V1kcVClwRo0G1JUJGPDZ2BDCjyTrFm2KT+iyZm5wNJA9FsIDuJPdM83IHQAvbrYtCXrpvM2gPZupvYwe9GsN/vclaOYDKZwQNSCJihnAEu4s5MAXJEp2w/7Qd/7oLRzFOyS+S4NveY4qs1iQkb7S2KWBOTShrM1dx/kGGCEidEY4gYSkj3tBjdY/Ya3dYXUIqPLYyQZdD3xAQIhTn+T9XJAAIfaCdySl9Zo7ove371UNTixZdWFKZcYH+Mh1VsLDtHyJzybeBSn/L3dsas7xHkH6A7T33gSTNZx5YwHIJwuEzpEj0/06VXGDyUCJP5P9bYbyUM4gzvqRBcialPs3gi+2HAF4WyHhs0U4xhUIq0pCOqqm/31kwF0WloJkalk2zT4rGBKcTW2KnjY9dXyyLNyWBh8Et2K6LRK0DBdrKoiKpYDvEeMBLVlFK5YS n/8uuJz0 44VQ8dQpMcPSKWVCKNLgB+rPYc4/hKRRKenqgG5jnwtt+7bM6+Mc+Q5TaQx4xEbKz8BoddUuhJJZwbCnurGE4Dn/mmE4BjTysYUSrvII0oiqnzva1vKDJuv9QRtkfhoD5R04QPC/JwWV0ObTzxLs1kXG0tP1hlJz2SVeadJ1Y8TBkytTwZRk+omR444EKGm5N1nrVKwCzd1CDOYLjgV5DSGx2tzmduYTGv5qQCBDr0KUJR+WwIDjcsR8mYYwThf5RE/daaIwQYQMZ/pwbFgNnRaXLSKzk0cGorLytPNFwz9mjTXuVJ2BCkQFuzsBOb4ULQPQoz+hT5CDNF8l1nUAmbXAjb7s5ECFTEGpYgtkm8+EouMI6x3dC6lEn0Q5yYGAj1jOpHLfLyiXvfhbCPjLNWoS41ODv2lEEWN5mnAS7N9n8seu7XboFV2FBftzlyQv1yaHzmPwDTvP7XE5/xtHgBvbegpwXFayyoLa71T9T5dbzeStpG6dJuE6sVKG04jqV3HSimCPpTT0pANc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.007463, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Sep 25, 2024 at 06:04:59PM GMT, Lorenzo Stoakes wrote: > On Wed, Sep 25, 2024 at 09:19:17AM GMT, Shakeel Butt wrote: > > I have no idea what makes you think I am blocking the feature that you > > repond in a weird tone but let me be upfront what I am asking: Let's > > collectively decide which is the better option (in terms of > > maintainability and extensibility) and move forward. > > I'm not sure what you mean by 'weird tone'... perhaps a miscommunication? > > To summarise in my view - a suggestion was made to, rather than provide the > proposed flag - a pidfd sentinel should be introduced. > > Simply introducing a sentinel that represents 'the current process' without > changing interfaces that accept a pidfd would be broken - so implementing > this implies that _all_ pidfd interfaces are updated, as well as tests. > While I suggested PIDFD_SELF, I never meant that we should change every interface, but rather adopt a sound, consistent strategy for pidfd interfaces and stick with it for the foreseeable future. In this case, we'd adapt process_madvise, then possibly later pidfd_send_signal, etc. There are plenty of pidfd interfaces that don't make sense with a PIDFD_SELF. Various other interfaces will probably never want to adopt it at all (select _can't_, other fs syscalls such as read/write/poll/whatever would require awful handholding from various kernel subsystems, while in that sense we would definitely require a proper struct file/inode/whatever for each pseudo-fd, which is not exactly what we want). > I suggest doing so is, of course, entirely out of the scope of this > change. Therefore if we were to require that here - it would block the > feature while I go work on that. > > I think this is pretty clear right? And I also suggest that doing so is > likely to take quite some time, and may not even have a positive outcome. > > So it's not a case of 'shall we take approach A or approach B?' but rather > 'should we take approach A or entirely implement a new feature B, then once > that is done, use it'. > > So as to your 'collectively decide what is the better option' - in my > previous response I argued that the best approach between 'use an > unimplemented suggested entirely new feature of pidfd' vs. 'implement a > flag that would in no way block the prior approach' - a flag works better. I just don't think it's a new feature, just an established, future-proof way of doing things :) Your patch should remain mostly similar apart from switching the flag check into an fd check. > > > > By big undertaking, do you mean other syscalls that take pidfd > > (pidfd_getfd, pidfd_send_signal & process_mrelease) to handle PIDFD_SELF > > or something else? > > I mean if you add a pidfd sentinel that represents 'the current process' it > may get passed to any interface that accepts a pidfd, so all of them have > to handle it _somehow_. > > Also you'll want to update tests accordingly and clearly need to get > community buy-in for that feature. > > You may want to just add a bunch of: > > if (pidfd == SENTINEL) > return -EINVAL; It should already be there in the form of an -EBADF. > > So it's not impossible my instincts are off and we can get away with simply > doing that. > > On the other hand, would that be confusing? Wouldn't we need to update > documentation, manpages, etc. to say explicitly 'hey this sentinel is just > not supported'? This is a fair point, but we could also just... not :) which I don't feel is too wrong, since the fd works kind of like a flag here. -- Pedro