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 0FB4FC43334 for ; Fri, 8 Jul 2022 15:58:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E80F6B0072; Fri, 8 Jul 2022 11:58:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 797EC6B0073; Fri, 8 Jul 2022 11:58:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6608A6B0074; Fri, 8 Jul 2022 11:58:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 52DE16B0072 for ; Fri, 8 Jul 2022 11:58:15 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 0DC6712088A for ; Fri, 8 Jul 2022 15:58:15 +0000 (UTC) X-FDA: 79664389350.03.F1A9BA7 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf12.hostedemail.com (Postfix) with ESMTP id 3A08E40049 for ; Fri, 8 Jul 2022 15:58:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=6RqQ8+XNVDVObMJIyPeKINSrkjPLTw+0lvhGuSc1mv4=; b=U/181vdzVYQuUne6r4DSfvY+yg Qp6rXidC6C9LEBdozRcX7xo/qlo8qm4YTHwa+5tM++bKx1vSdPeNWBhbhmZNnefGmT6KhhVc09xee +A7G9itA8blRQMvCB4Vo5CgudikDfZrNXVUeFZ0sMtJsGxpxdyh3ZGnNYMXL/jSwMyLo3MsT6T9T2 wIAPsGLZup7bDPOqfjynoKwYV7hiO43NC8p8DQVShXMX6WIl97tAk9dPcWhcN4yvfSUO/XGf3XtVr 7Ierci+IrPeQU2BuSRPE5zp1AlgTMI7aqsG4Kj5RnglyRUdpbd2TOZUkI2feTeyeA0CZEUZTIXdtb mwZm7L2Q==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1o9qMq-004UMR-T3; Fri, 08 Jul 2022 15:58:08 +0000 Date: Fri, 8 Jul 2022 08:58:08 -0700 From: Luis Chamberlain To: Song Liu Cc: Song Liu , bpf , lkml , Linux-MM , Daniel Borkmann , Kernel Team , "x86@kernel.org" , "dave.hansen@linux.intel.com" , "rick.p.edgecombe@intel.com" Subject: Re: [PATCH v6 bpf-next 0/5] bpf_prog_pack followup Message-ID: References: <20220707223546.4124919-1-song@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657295894; a=rsa-sha256; cv=none; b=6/sdKIACTJzgjvY2BLEuAL8amlSo2vPxXyqZFYAiHtFVH0niyXwMFxX8QRd2ZSAc9HVj5Z nYuxWhdfXVHndaxWgI5MiSuUlLuZHEj3a14bntS5JZCrqt3IVbBQdpFMvaRdngnehrCKRz mXXXStCcBr9y33B5lda0ZEf9HRM+pmA= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b="U/181vdz"; spf=none (imf12.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657295894; h=from:from:sender: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=6RqQ8+XNVDVObMJIyPeKINSrkjPLTw+0lvhGuSc1mv4=; b=IyrWhfpieHqp+R2DuxlCKD46AxEbhap52QngguS/0vH9AynwVMbIInCYatr4z0EachLIIJ TCtk0XQ1LEYKHodD+afI02/7ZlybH4DtGHwXnbNSNoOG9dp6OvfPDVoJ9AzrONEYzOww67 MA55D8A94mmoVpb9T+DqKlUQeMIWhqg= X-Stat-Signature: ci5rrbmkii8555mzftxpstj74wjwmjjo X-Rspamd-Queue-Id: 3A08E40049 Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b="U/181vdz"; spf=none (imf12.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1657295893-864340 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 Fri, Jul 08, 2022 at 01:36:25AM +0000, Song Liu wrote: > > > > On Jul 7, 2022, at 5:53 PM, Luis Chamberlain wrote: > > > > On Thu, Jul 07, 2022 at 11:52:58PM +0000, Song Liu wrote: > >>> On Jul 7, 2022, at 3:59 PM, Luis Chamberlain wrote: > >>> > >>> On Thu, Jul 07, 2022 at 03:35:41PM -0700, Song Liu wrote: > >>>> This set is the second half of v4 [1]. > >>>> > >>>> Changes v5 => v6: > >>>> 1. Rebase and extend CC list. > >>> > >>> Why post a new iteration so soon without completing the discussion we > >>> had? It seems like we were at least going somewhere. If it's just > >>> to include mm as I requested, sure, that's fine, but this does not > >>> provide context as to what we last were talking about. > >> > >> Sorry for sending v6 too soon. The primary reason was to extend the CC > >> list and add it back to patchwork (v5 somehow got archived). > >> > >> Also, I think vmalloc_exec_ work would be a separate project, while this > >> set is the followup work of bpf_prog_pack. Does this make sense? > >> > >> Btw, vmalloc_exec_ work could be a good topic for LPC. It will be much > >> more efficient to discuss this in person. > > > > What we need is input from mm / arch folks. What is not done here is > > what that stuff we're talking about is and so mm folks can't guess. My > > preference is to address that. > > > > I don't think in person discussion is needed if the only folks > > discussing this topic so far is just you and me. > > How about we start a thread with mm / arch folks for the vmalloc_exec_* > topic? I will summarize previous discussions and include pointers to > these discussions. If necessary, we can continue the discussion at LPC. This sounds like a nice thread to use as this is why we are talking about that topic. > OTOH, I guess the outcome of that discussion should not change this set? If the above is done right then actually I think it would show similar considerations for a respective free for module_alloc_huge(). > If we have concern about module_alloc_huge(), maybe we can have bpf code > call vmalloc directly (until we have vmalloc_exec_)? You'd need to then still open code in a similar way the same things which we are trying to reach consensus on. > What do you think about this plan? I think we should strive to not be lazy and sloppy, and prevent growth of sloppy code. So long as we do that I think this is all reasoanble. Luis