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 02233CDE017 for ; Thu, 26 Sep 2024 15:52:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7F9986B008C; Thu, 26 Sep 2024 11:52:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A93A6B0095; Thu, 26 Sep 2024 11:52:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 697CD6B0098; Thu, 26 Sep 2024 11:52:47 -0400 (EDT) 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 4CBF66B008C for ; Thu, 26 Sep 2024 11:52:47 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EA4611619A2 for ; Thu, 26 Sep 2024 15:52:46 +0000 (UTC) X-FDA: 82607332332.24.CD1697B Received: from out-185.mta0.migadu.com (out-185.mta0.migadu.com [91.218.175.185]) by imf04.hostedemail.com (Postfix) with ESMTP id 2B5364000B for ; Thu, 26 Sep 2024 15:52:43 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=rkdfqjfe; spf=pass (imf04.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.185 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727365843; 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=z7G9ApLodriz/3joeN5VC8yGsIyla+zmSVIF3RzVqW4=; b=VDeqEhspqvjqkUJyN8GhdE1ZjpICypvslu/M9oink4SBPE0/AnNnhOJhUlAfjBubwi4bIm rwg4mKkEjyN6wVGSNnJgeQVhozlsK2b+wRDdAJEYbcuUtXTHYfjzSEWqat70rxoa5S0Tml uyBfIdOqWu9at9SPXn7JqkxfO//uc0U= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727365843; a=rsa-sha256; cv=none; b=WSnGbxJu9uHpgL7drMCBj9QoFv0oUABiMOg+OTu1zRJNYwWVSgCsZkNrdPPYnKkk/ncE1d 0D0S0FZG2KrEbth2oYbTzJCepGOPPDSkFTIwagPVgjzmaEDlpWIJrlNhyDWlIkGkSWXjZA Geme2gJjdKkzgG4ZSIvzZw3jl9wGLA8= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=rkdfqjfe; spf=pass (imf04.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.185 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Thu, 26 Sep 2024 08:52:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1727365961; 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=z7G9ApLodriz/3joeN5VC8yGsIyla+zmSVIF3RzVqW4=; b=rkdfqjfeLCjUwQkPZdp8SArzUM460wX8K2Vo4qtCeHBCFhILxoZJ9IlzIU8rLdiAn/0xd5 /XTqIUPXHEhYZVCjCStxxhIr7+AVVfPkdMCjrl/VLQyU/bNSKnQ+xLb6xVRXiat2aH6v0a Uj1eNkSRLpopJkRxbNMYuGCCZHaLVFg= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Lorenzo Stoakes Cc: 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 , Christian Brauner , pedro.falcato@gmail.com Subject: Re: [PATCH v3] mm/madvise: unrestrict process_madvise() for current process Message-ID: References: <20240926151019.82902-1-lorenzo.stoakes@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240926151019.82902-1-lorenzo.stoakes@oracle.com> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 2B5364000B X-Stat-Signature: cru1mtfyx86gogqfdocnfnscfx514pmo X-HE-Tag: 1727365963-231064 X-HE-Meta: U2FsdGVkX19ZPEBtkY19WNM1ONuB4vGBY4p3+iv3UeQi6NrvIwCVWP6L844CZHeWaK1s0Fld7uQz9DiQzezJHkZDdcJBgUFyAOluZLZAPAlcnKnHex5Evl3A3N5KpW1ztY3zgG2n7UE4dBm2zJaMHUPNTL2wKqpvC++D+dnp81OWSnAl2wgImwqAZ5L+7FbAvfeCkzJdbgFFnDsckCnNKkJOfBb8vfK/RTslLu8nzS6v7ZmSt+TBM1sl5u11eG0LgaZsxkoskHFrjFkk+d5KCUigFpQ4r6bTshH43/VX7Cme0PKVnvVis8p7Mp4nCTvhXbP9u3S/RNRNf04hEX5dVNztoPsovgouA+aHB6ZGaCgQz7b8OzgVV35Kfb9CXck8kDCVEfnt8Mp0/OQnBvJtZ8yC1PAzOhfTxa5vkSn11iZgPmlUqQUi8PKAXvlIOPm8hrBSN3+pjidQ0s1bp7dIkpA/BSmiElFsIa+xBR0f4FxgtfFcQ0xux/vDnx4LV84SAbjtsUxxTKclDeBpxgsRlvpHP4ABaqzz5ajzLuxsmeghoMocPBbELhkF0nfE/Hs30kxLOtiziG3z/d0GxiUahofjEVDT8vnhSWwUnBQdaB+80PMO4zWygs4395yYPYS8TaDgzCpfQblIAyLSJEpqhmtiyIjp1p/gv8kBN3FSz17wubAG3Al4/B1cq2IMjhuRARfiDN235Kmjgb7/MA1lS+ny6g8uUwZyntVX/JzAsJc1IUW9500OIUahP3kB4reNDkDTLCVrPbfnuUxbGIpT1Vk7XOPtGogF4pUPi0RfeMEBlUmr7Ghutui2ev8jhRtBZb2d5YDn7nwrR8vmaXuqb65N1s2pQ+cQ/AtMFGi4yg5HnnYLdfeeglyqQRFtkOTkq0N6x3bCUIH5C3HsE92biM+oDm0QkDk4RcNKVsohv7icQ8IQ3GeFfb7DjrxFFkRqyBp1kZFT8jDDPBaXIgw vg8z01ng 8qZA3abTTpVrfurpOXvsxOUFBiILFgMxOhuuHI/asHYkgUvbVcf3WOz9xYUssF99hqQoB6iPp/IX7T9bQMnoHsauC+3jJHgenDPbZM1k0nKQ12VMNjEBh87V/+sKE1SvT2Q2452G+kj2yX8VtUqhtVyniJ+snKsBnM0wQo8ZZAL1JpfpWMIxI9Mt8O2fSyK8CcIKvg5uLk84SVBFrypcRyQzmfPiRFjOwz9SChTIwTYXf4Tj1DumfoFCGRF/v+Fo/DKmph0a1zy5uhRWf60v6xGcCW3d6+R+pH8xZ 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: List-Subscribe: List-Unsubscribe: On Thu, Sep 26, 2024 at 04:10:19PM GMT, Lorenzo Stoakes wrote: > The process_madvise() call was introduced in commit ecb8ac8b1f14 > ("mm/madvise: introduce process_madvise() syscall: an external memory > hinting API") as a means of performing madvise() operations on another > process. > > However, as it provides the means by which to perform multiple madvise() > operations in a batch via an iovec, it is useful to utilise the same > interface for performing operations on the current process rather than a > remote one. > > Commit 22af8caff7d1 ("mm/madvise: process_madvise() drop capability check > if same mm") removed the need for a caller invoking process_madvise() on > its own pidfd to possess the CAP_SYS_NICE capability, however this leaves > the restrictions on operation in place. > > Resolve this by only applying the restriction on operations when accessing > a remote process. > > Moving forward we plan to implement a simpler means of specifying this > condition other than needing to establish a self pidfd, perhaps in the form > of a sentinel pidfd. > > Also take the opportunity to refactor the system call implementation > abstracting the vectorised operation. > > Signed-off-by: Lorenzo Stoakes Acked-by: Shakeel Butt > --- > v3: > * Avoid introducing PR_MADV_SELF and defer a non-pidfd version until later. Seems like a good plan to decouple this patch from PR_MADV_SELF vs PIDFD_SELF decision. I am hoping to see the follow up patch as well. thanks, Shakeel