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 66CE6E77188 for ; Mon, 6 Jan 2025 21:03:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E6F426B00B6; Mon, 6 Jan 2025 16:03:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E44946B00B7; Mon, 6 Jan 2025 16:03:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D0C676B00B8; Mon, 6 Jan 2025 16:03:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B46066B00B6 for ; Mon, 6 Jan 2025 16:03:45 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5E450C0339 for ; Mon, 6 Jan 2025 21:03:45 +0000 (UTC) X-FDA: 82978253610.24.9F0B761 Received: from out-183.mta0.migadu.com (out-183.mta0.migadu.com [91.218.175.183]) by imf12.hostedemail.com (Postfix) with ESMTP id 6B36940012 for ; Mon, 6 Jan 2025 21:03:43 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=fq4DTnKX; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf12.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.183 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736197423; a=rsa-sha256; cv=none; b=CCalb8MOwA5ADBarqZkFoNPkGKI8sd0+R/VdhbooHUDfFrOiW9BMvYZz8kjjRWMGXoTVFC SM9BXsxRlf4DC4CQ2VZKolsOc41/Ok4wl0HQMbS1PEOMdYtJso1y7j3AaEe2iMWIHRWWG5 psVg+Z8fkCZmA19vM1hjmkUxNcEbfjo= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=fq4DTnKX; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf12.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.183 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736197423; 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=2XnxA8bBrbeEfZhjJa7nYBpTgQjLSeAqkIA9Z+SmJUI=; b=8GN+aKT51g3/1LVp8NlrD5Sqvh05TI+cav8rje95KIxgl0gaGlf6tY6pDpXuWls6/y+gNK D6CxCEccsi099pRzSl89IBMuWgixBemgDN/tB9RZF/kWc2EvuTcOGONuTXTV6lKZSpwj+S Mjo8O15pcu+fYwUiR2UAkuorZhkYSIk= Date: Mon, 6 Jan 2025 13:03:31 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1736197416; 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=2XnxA8bBrbeEfZhjJa7nYBpTgQjLSeAqkIA9Z+SmJUI=; b=fq4DTnKXE18xy2+YLZLT1tL53b3p56K2VG9eCm6dnhl22ODMaVmiL9CM8DdDXaN2KGy6Gx 136B0G+QS8CW0qincZlNX7t4UZH601umFUZLFCBWzbQbjYB+UtFK3YO1cxy72D1Gle05Iz VIBQyyA9Xh0SDZLCazXk+KM0i+bfBCo= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Lorenzo Stoakes Cc: Christian Brauner , Oleg Nesterov , Christian Brauner , Shuah Khan , "Liam R . Howlett" , Suren Baghdasaryan , Vlastimil Babka , pedro.falcato@gmail.com, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Oliver Sang , John Hubbard Subject: Re: [PATCH v6 2/5] pidfd: add PIDFD_SELF_* sentinels to refer to own thread/process Message-ID: References: <8eceec08eb64b744b24bf2aa09d4535e77e1ba47.1729926229.git.lorenzo.stoakes@oracle.com> <20241028-gesoffen-drehmoment-5314faba9731@brauner> <55764300-1b53-4d14-99cc-e735d3704713@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 6B36940012 X-Stat-Signature: ry8wgpcz8jyfrpjm7abc4sd7etj4wp48 X-HE-Tag: 1736197423-227350 X-HE-Meta: U2FsdGVkX1+EQCCArDCJuHJlLEhftVlDKpmRLAKZExdNUbGH9IiPtnd9o1ElI1qv+Egw2ZGI3//kSXFD0W4FS9txzc1pLxv++Y3OE/kEN9GinmTY77Duuuvw6yTtvnU8sGSkaa8Yvv3DAO3qoEoc+0xOMX3TOkIz9/NXHP0QWwdgL4J7x3bt5W5OxQDC9qqjuDlC5LoTACqfu+W5JOv42oTzxHUMtfBr53VtCnZpyRfo7lGFgCV+bkP70IFn7mfc2GNiNmbYaIyNVQZT5tg3gBkBFuCmgb7PvsnjyYXue7LTmBN3wl65atY3H4H9G5X8lucW0CsLq3oiW2ZyfzwEigtXHEjKuVQ7jGstaZxWqdzR+SsnCgijncBMBN3v1HqJJ5Z7KlkezywplY47K88hCKHkmlBCLbzXuwuD01rr5iWh1FJQ69c38mF+rkjRQSQOFFx/A2I+5/mWlXrrEZWpCBqlb3juhbIQFBoTrq2AUB90n/Kk8xd3iur+hrpZR9yL9veCI1SkXBuTFBLPpBuuDWwrQvRYoxrdl+U9dS0xf3YEs/41jPY+fQvShr8wL4x5ThmPfJIJQ9eaV83fywmxGQJb50DwEFWBcBzXEIC+WIrsqcquydwuh9E6iSzh0wou6WYGkaag2wVpJITJZzaUpnbVkdz+DOqEOCXLOEj/pVsFYsgKZlIbTIYXMb/JYeeIgMeAGxZS5OfTbDIScragrGXaGAARcXNUWZFMEpaC1uuVahBfLvKinSdZBlTJuHUGvjhztmOTVMTO4rtaEhvAM3Wh52T/LdyG4KmkqWQ11VfhFN1M9mrrvbw4Tda6w1/5g0FSyWEyTuEqE7cK6GGK4DqRRtaVbNuATUSohr4Zct7tOta9q/5YVeT12UWQbBiPYSg5EnDEFb9RqGq11Ly9ABSBhGy1Cx4JeGcVJPh6uRrfL2IqIl4Y4qcDSSxjf30Hy0Cq3ysXRVBUMjjXGOV 5hjdUEUK 9DXYWv3au4hHgPXb5L7/ahF6vajeR1iBlBNM1SxhK1sYSD238Stplq9TnbxcolZwiSajRZoUAoMYFF3PMwp7c/Cwisi1f8UaIEjtN8Lb/ZvFaYegpyEs9IvyJSaMIL6vU0xsJwMclk+pEIHr2eHIa+q+o30LTql3Fm/AnIcF5uZl8g9ajC8rAkfjT2XbKcCUUDuCj7KgIbI+cAKbabPCTRlyDh7co/nhyfs1GytJ7afmtam8l0Bqfrc+Pqg/B8uiOcDi5eFSp9OXEAFA65RKsiCmBvlpespxeSRC9 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 Mon, Dec 02, 2024 at 10:52:13AM +0000, Lorenzo Stoakes wrote: > On Fri, Nov 08, 2024 at 02:28:14PM +0000, Lorenzo Stoakes wrote: > > On Wed, Oct 30, 2024 at 04:37:37PM +0000, Lorenzo Stoakes wrote: > > > On Mon, Oct 28, 2024 at 04:06:07PM +0000, Lorenzo Stoakes wrote: > > > > I guess I'll try to adapt that and respin a v7 when I get a chance. > > > > > > Hm looking at this draft patch, it seems like a total rework of pidfd's > > > across the board right (now all pidfd's will need to be converted to > > > pid_fd)? Correct me if I'm wrong. > > > > > > If only for the signal case, it seems like overkill to define a whole > > > pid_fd and to use this CLASS() wrapper just for this one instance. > > > > > > If the intent is to convert _all_ pidfd's to use this type, it feels really > > > out of scope for this series and I think we'd probably instead want to go > > > off and do that as a separate series and put this on hold until that is > > > done. > > > > > > If instead you mean that we ought to do something like this just for the > > > signal case, it feels like it'd be quite a bit of extra abstraction just > > > used in this one case but nowhere else, I think if you did an abstraction > > > like this it would _have_ to be across the board right? > > > > > > I agree that the issue is with this one signal case that pins only the fd > > > (rather than this pid) where this 'pinning' doesn't _necessary_ mess around > > > with reference counts. > > > > > > So we definitely must address this, but the issue you had with the first > > > approach was that I think (correct me if I'm wrong) I was passing a pointer > > > to a struct fd which is not permitted right? > > > > > > Could we pass the struct fd by value to avoid this? I think we'd have to > > > unfortunately special-case this and probably duplicate some code which is a > > > pity as I liked the idea of abstracting everything to one place, but we can > > > obviously do that. > > > > > > So I guess to TL;DR it, the options are: > > > > > > 1. Implement pid_fd everywhere, in which case I will leave off on > > > this series and I guess, if I have time I could look at trying to > > > implement that or perhaps you'd prefer to? > > > > > > 2. We are good for the sake of this series to special-case a pidfd_to_pid() > > > implementation (used only by the pidfd_send_signal() syscall) > > > > > > 3. Something else, or I am misunderstanding your point :) > > > > > > Let me know how you want me to proceed on this as we're at v6 already and I > > > want to be _really_ sure I'm doing what you want here. > > > > > > Thanks! > > > > Hi Christian, > > > > Just a gentle nudge on this - as I need some guidance in order to know how > > to move the series forwards. > > > > Obviously no rush if your workload is high at the moment as this is pretty > > low priority, but just in case you missed it :) > > > > Thanks, Lorenzo > > Hi Christian, > > Just a ping on this now we're past the merge window and it's been over a > month. > > It'd be good to at least get a polite ack to indicate you're aware even if > you don't have the time to respond right now. > > If you'd prefer this series not to go ahead just let me know, but > unfortunately I really require your input to know how to move forward > otherwise I risk doing work that you might then reject. > Hey Lorenzo & Christian, what's the latest here? I see Christian has code suggestions at [1] which just needs to be addressed. Any thing else? I am hoping we can get this merged in the coming open window. [1] https://lore.kernel.org/linux-mm/20241202-wahrnehmen-mitten-e330cbd1eaf0@brauner/