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 06AD7C2D0CD for ; Wed, 21 May 2025 18:26:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E50C6B0096; Wed, 21 May 2025 14:26:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 89BBB6B0098; Wed, 21 May 2025 14:26:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 784E46B009A; Wed, 21 May 2025 14:26:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 546D36B0096 for ; Wed, 21 May 2025 14:26:17 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D9387C101F for ; Wed, 21 May 2025 18:26:16 +0000 (UTC) X-FDA: 83467744752.07.82D4862 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf23.hostedemail.com (Postfix) with ESMTP id F07DA140012 for ; Wed, 21 May 2025 18:26:14 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RK1Q4NAD; spf=pass (imf23.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=usamaarif642@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=1747851975; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=137GJ4GfHv//QtR0F1GuTLgJgEBX5CAPbUrQx+K92Jc=; b=wCUss9AzSv+RaLtb+0iLb+9RsBvFc08QkC+f53YsisEVHKf8/RDxCi8FXVXdsaz4cjXzYu Um1CMG+yHcJ89x3NKmPDmWks2pneQRAQRI7lam1CW1epVr4FBYgNIkBhRSCse+IUKBd0Xj 2vwIZ1+7b/bgtBoZa3k/B2+X9MctYVM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747851975; a=rsa-sha256; cv=none; b=u/7G6nVf0we5ZSJ6RyAweVZ/fNrsPyD8wAhJ0BCMrINjnRTSGM2Bvz417+qCn4fMfD3aAR WULsaWJ5X2xJh5evwT+yymAJWLgBpc5Lkhbgtl+Xi2XO0phm+IBGu/oV97VDx/If2e1OE8 oiGcOHUwR4wbR1RxA3jeyu18KMcw8Ko= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RK1Q4NAD; spf=pass (imf23.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-6015f8d4b7dso3576476a12.1 for ; Wed, 21 May 2025 11:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747851973; x=1748456773; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=137GJ4GfHv//QtR0F1GuTLgJgEBX5CAPbUrQx+K92Jc=; b=RK1Q4NAD8dj8zU0sDkOHT0QqUaamBw9tO9oIJRNpQcAYna/2Jkdvlb6qRQ6lwXUXwe ijfCdHYHnSgD/h5qlcexYbKiCynVpReEvo/WkZyHnRHVTqxBg56dAjAzk+9/dwGT/+O3 ZP2luAjpkGPQIMZUwKXW6Y5LhipyscxqRysrhkhkF6fDG8gO2QgxhI7Tdh8P/7F+UhfB 6mzq26nyqWxv1TxoCl2gBCWWGVUjV4+J9lEX/lv/5n7MaFB46RQPxEEeb3y3169QkXCr uvLtUIpCHgeyjVo9zpTz2nat4SI80neDJofTOS2U7nAJrKwndiB/kApZCTmuI93JDtJx Sekg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747851973; x=1748456773; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=137GJ4GfHv//QtR0F1GuTLgJgEBX5CAPbUrQx+K92Jc=; b=WmiqtosDHVJ9Y7GaIssOxFec5XuppuEYEj5nMuGB/pCPA2UWs5+DB1dYMr/dFoafnI oxEd6btbIonLXiiSYDu2C+e5XjaqG/KpZTcmdvTgAoFxZ3mNUVvA6kNbHP2MSWVz1byt QiMObjHmhfeNuvFKqP/ORjEJsrreb2T+to0JlK3qagsJczYtzoYb6jBGSp9tdlnR3l4d 7yRMUJFKx1Pndwj0SngHMQzrfgNjFVIPZ5BVPYsrypmtDtXhZgpQgpja46MXZDUNNiyV 9chbRj9YGvzJgDu0w61YfV3VcsxSDPpuaK5t1c4Z+az93Hd+QAK4bDjWQOwrThwSU1T5 SBKQ== X-Forwarded-Encrypted: i=1; AJvYcCVP6af5bx8yvQ83Bjf1dm3+IvH1QYNe4Xp16U7/1nkwNgZkgGPIaqaXcpDwPXsfDvcqVR28uCDpDA==@kvack.org X-Gm-Message-State: AOJu0YwZ8ZMFp7qiU5GeefeVVTkPpVmyFEgMAMXQiRviARcWuWDZewWm bXHeehmOJdrOMp8DsH9fUbA4M9Fuviq8/cBvUyxy7EyJkqCyb/7ztOcF X-Gm-Gg: ASbGncuQc+tC1Ur88edR3zCN64wWnz4jJEYp2na1HPEYm8/z0V6u2Pa11RWmvC9Rb68 45tapHyg9+7cOhhv+FYWV4tFtrGfkZvhLK8qaoU2a0/eEso+xtSDybJGE6kWAMka5s/OAAVpWQm TnG7OMHDdCNb/1FlUIVRukUnsjlO9FytvyErD2ss+IVB7XdbavAbkq6cJpYWyfuZ/X54Y00kZaR onlZiM/crRB821fSjl5zJo39Lik4BW0f17921tIANRpSf53lkWjb0mSURN3J3CFKclENJQupUUD Z52DKXVfHXtrj+WA8Jkx8r5e5glH8YIBolymZpWv0kbY2IkVNVGbq3Vh0RLfsCR3yAMK53XfCcz WcZYsNzZWzKuNiMY+B5L/WCBqDYWRaMvYa/75Ow== X-Google-Smtp-Source: AGHT+IGVO4cvKitoUzSJ7KeNwWEBPkBnDvhVrfdBR1/AYHjERdFT484mGqFALdLlEMk6PEQ6CBZQxQ== X-Received: by 2002:a17:907:8e97:b0:ad4:d335:d35d with SMTP id a640c23a62f3a-ad52d45ae47mr2035316166b.4.1747851972839; Wed, 21 May 2025 11:26:12 -0700 (PDT) Received: from ?IPV6:2620:10d:c096:325:8d0:f08c:4e6a:b32f? ([2620:10d:c092:600::8a7e]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ad52d4cc5dbsm934634266b.169.2025.05.21.11.25.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 May 2025 11:26:03 -0700 (PDT) Message-ID: <9ca3f5eb-e76f-4135-91d8-363851f5c3ea@gmail.com> Date: Wed, 21 May 2025 19:25:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 0/5] add process_madvise() flags to modify behaviour To: Lorenzo Stoakes Cc: Shakeel Butt , Andrew Morton , "Liam R . Howlett" , David Hildenbrand , Vlastimil Babka , Jann Horn , Arnd Bergmann , Christian Brauner , linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, SeongJae Park References: <7tzfy4mmbo2utodqr5clk24mcawef5l2gwrgmnp5jmqxmhkpav@jpzaaoys6jro> <5604190c-3309-4cb8-b746-2301615d933c@lucifer.local> <226owobtknee4iirb7sdm3hs26u4nvytdugxgxtz23kcrx6tzg@nryescaj266u> <7a214bee-d184-460f-88d6-2249b9d513ba@lucifer.local> <1a7be28f-c805-4092-a7dc-d71759920714@lucifer.local> Content-Language: en-US From: Usama Arif In-Reply-To: <1a7be28f-c805-4092-a7dc-d71759920714@lucifer.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: F07DA140012 X-Stat-Signature: iebw6k7nmi54ggix65yejuh4aznmpq1a X-Rspam-User: X-HE-Tag: 1747851974-761095 X-HE-Meta: U2FsdGVkX1+fa5upJawGvEBlpC7UWB+NWpWoZPVjxa2EJJrti0ueT7OE36J/ElL1Orx4zQtwdvW2m7VIqgmHXXm0wuxfry/oA5r0aSqSTtppzmXX0CmpKTcFW3OqDk+My3e381liYP1rGwJI1XvVfR1Ic9AtkGxYHpjCf1FBN2NXiWj0Jsi+kyfedirbIEET9Hf5WS9Q9WXJ98TEHm8JMedIrpWuvHPBWKhDHATZu2B8/O6ks07QvL/OoWzBi0H3AlNry40S3Go89aRIHMRKGBYv71qdl4SyYULYWiEHk/OBq9WxmsS3zp1DvtCJHjvy7wxHBa3Bz92E1NYwKO+heNZiUTmVZi9OTTdB5m+HAVkVWFkYJa6fX3PEYbqMMTxNK2SCCSKaaw6b2dgoM8zBrCtrB38PC2AFiklC8ukoRn9WHVNNyXg4Y1DOC1xPzt/sghv8V+Z+m1tQecFVSPyEd8RTc/Odb3eqXhlWzvxowzO6qHb1qQfvyNueAi+FxO2aLT2KEmrUomKJOYQOlWrfw9RkAGYS90ORvZx+RtqZROLLYBNJIfY/2Nb1uBZClzVSEYEUMFY9uLOAMpcSomyIjAuSoczFgEvtdclR+n1FZfRAh/uIi2sVTPFayYpgY5DNyYJpdQka4DbrEqeAEVpN3PxvF9FAcNgALnANV+3taay1PqRhJUa1lZYg74TCkDMYfCyCqTp+aczeU/0apVjdwG6qv82C3KgHOefUKUCEBPYID5Ikp7+5VS+mVAQQRHoOSDc1/T6/btMbtQfmxebCp53K6N7fkAhjCizkm+HiZ/5knr89cAv3pKnun+I9uZ0sSJhonuaAbv4LdYKsD9FC+9B+pA9rg5Wl+Nh9E4XuTLZlOsLLvBf33Bnod5R3tRI6n0eit+zWpWcC9aVKPhJQyV6FpHjouni45iCq6Y+lgVVtd/C2t9j8Vut9k9D40EmzlJ0+Fqkc+Ho2dhF1iwI CxtY5Bjw bn1vDsEvrzfE/16K47d9vnpA4sOYnoZSCaBQE6NGyesrGPay2fFFjJq26cI0Twm7C6G2r 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 21/05/2025 18:39, Lorenzo Stoakes wrote: > On Wed, May 21, 2025 at 05:57:48PM +0100, Usama Arif wrote: >> >> >> On 21/05/2025 17:28, Shakeel Butt wrote: >>> On Wed, May 21, 2025 at 05:21:19AM +0100, Lorenzo Stoakes wrote: >>>> On Tue, May 20, 2025 at 03:02:09PM -0700, Shakeel Butt wrote: >>>> >>> [...] >>>> >>>> So, something Liam mentioned off-list was the beautifully named >>>> 'mmadvise()'. Idea being that we have a system call _explicitly for_ >>>> mm-wide modifications. >>>> >>>> With Barry's series doing a prctl() for something similar, and a whole host >>>> of mm->flags existing for modifying behaviour, it would seem a natural fit. >>>> >>>> I could do a respin that does something like this instead. >>>> >>> >>> Please let's first get consensus on this before starting the work. >>> >>> Usama, David, Johannes and others, WDYT? >>> >> >> I would like that. Introducing another method might make the conversation a >> lot more complex than it already is? > > The argument is about prctl() vs. another method. > So there are a few things that have been on the mailing list prctl, process_madvise, bpf, cgroup based (although that was shot down). I meant adding another one to all of them. But please see below. > Another method was proposed, arguments were made that it didn't seem > suitable, so an alternative was proposed. > > I'm really not sure what complexity this adds? > > And what better means of comparing approaches than actual code? Isn't an > entirely theoretical discussion less helpful? Sounds good! > This feels a little like dismissing my input (and I note, Liam's points > remain unanswered), and I have to admit, that is a little upsetting. > The current prctl version is a lot lot better only because of your input. The previous version had flags2, MMF flags, was breaking vm merge. All of it was fixed only because of your valuable input. So I have never dismissed your input, and try my best to reply quickly to your and everyone elses reviews. We disagree on the best way forward (whether prctl is appropriate) and I think disagreeing is definitely part of good engineering. Please always assume I am acting in good faith. As to not replying to Liams review, if its https://lore.kernel.org/all/ass5hz6l26jc6xhbtybmgdjf55hmb3v4vvhrxhqampv6ohl67u@qi6iacwzwfk5/ I had already done it several hours ago. If there was a email bashing prctl on how it is a bitrot and where everything goes to die, I really dont know how to reply to that anymore. Otherwise I might have missed it. I really hope one thing is clear from our interactions over the past week, that I always try and address feedback. And for the upsetting part, from all the WTF reactions on my v2, and all the rest of discussions we have had, I feel you have always been upset with whatever I have sent (patches/replies), which I really really don't understand. We will have disagreements, its part of the dev process. The current version wasnt going to get any acks, and was not going to get merged in any form, so I really dont get it. Again, please always assume I am acting in good faith. > But I suppose one has to have a thick skin in the kernel. > >> >> I have addressed the feedback from Lorenzo for the prctl series, but am >> holding back sending it as RFC v4. >> The v3 has a NACK on it so I would imagine it would discourage people >> from reviewing it. If we are still progressing with sending patches, would it >> make sense for me to wait a couple of days to see if there are any more comments >> on it and send the RFC v4? > > I've no problem with you respinning RFC"s, as I've said more than once. The > NACK has been explained to you, it's regrettable, but necessary I feel when > explicit agreed-upon review has not been actioned (obviously I realise it > was a mistake - but this doesn't make it less important to be clear like > this). > > As to stopping and having a conversation about which way forward makes most > sense - I feel like that's what I've been trying to do the whole time? I > would like to think my input is of value, it is a pity that it seems that > it apparently is not. > > I am obviously happy to hear other people's input. This is what I've been > working very hard to try to establish, partly by providing _actual code_ so > we can see how things compare. > > It seems generally people don't have much of a strong opinion about the > interface, other than Liam (forgive me if I am misinterpreting you Liam and > please correct if so) and myself very strongly disliking prctl() for > numerous aforementioned reasons. > > I would suggest that in that case, and since we maintain madvise() > interfaces, it would make sense for us therefore to pursue an alternative > approach. > > But for the absolute best means of determining a way forward I'd suggest an > RFC is best. Sounds good to me. > > Thanks.