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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB00BC433EF for ; Wed, 6 Jul 2022 18:40:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230400AbiGFSk6 (ORCPT ); Wed, 6 Jul 2022 14:40:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233860AbiGFSk5 (ORCPT ); Wed, 6 Jul 2022 14:40:57 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F13B2982C for ; Wed, 6 Jul 2022 11:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=EBdCmYbRqUYpedK1noOKKYsmDTbuII4Hh6+poc9GJ8g=; b=MNhia7ldNRpIDRhns59yHzxYoR cezXP9TrPh8MRdyWTqPMxTEuCWNUDv2dykabC/ogogbi9pqvASULI3pURtyxvAJ54/Hc4cWiRgjoP 9XB6UAMGodIlfTm3rfeNwxQ5Z4g5OD0KNhOK/GPB+68H8QTZarJk5ZfoPKV6nHjcyZgHK/QAaRooE qPnMuJRrVEz2xIPlC5fvwBk0r+tk+dBXp6X0RWZg7hbISRTWttVGxAi8GJVyn0YY2WwTH13m8q6Lt 3o4eciUSJH/bro14/FEGQ0Ude3DawT0EoqIjoSQbtlBt4IAfcr3rxdCP5+tYnrRQexdF1r1t8mJfa f8RKa7CA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1o99x6-001seV-TZ; Wed, 06 Jul 2022 18:40:45 +0000 Date: Wed, 6 Jul 2022 19:40:44 +0100 From: Matthew Wilcox To: Alexei Starovoitov Cc: Christoph Hellwig , davem@davemloft.net, daniel@iogearbox.net, andrii@kernel.org, tj@kernel.org, kafai@fb.com, bpf@vger.kernel.org, kernel-team@fb.com, linux-mm@kvack.org, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka Subject: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator. Message-ID: References: <20220623003230.37497-1-alexei.starovoitov@gmail.com> <20220706175034.y4hw5gfbswxya36z@MacBook-Pro-3.local> <20220706180525.ozkxnbifgd4vzxym@MacBook-Pro-3.local.dhcp.thefacebook.com> <20220706182635.ccgt6zcr6bkd3rjc@MacBook-Pro-3.local> <20220706183619.3mmtsyi72c6ss5tu@MacBook-Pro-3.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220706183619.3mmtsyi72c6ss5tu@MacBook-Pro-3.local> Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Wed, Jul 06, 2022 at 11:36:19AM -0700, Alexei Starovoitov wrote: > On Wed, Jul 06, 2022 at 07:31:34PM +0100, Matthew Wilcox wrote: > > On Wed, Jul 06, 2022 at 11:26:35AM -0700, Alexei Starovoitov wrote: > > > On Wed, Jul 06, 2022 at 07:21:29PM +0100, Matthew Wilcox wrote: > > > > On Wed, Jul 06, 2022 at 11:05:25AM -0700, Alexei Starovoitov wrote: > > > > > On Wed, Jul 06, 2022 at 06:55:36PM +0100, Matthew Wilcox wrote: > > > > > > For example, I assume that a BPF program > > > > > > has a fairly tight limit on how much memory it can cause to be allocated. > > > > > > Right? > > > > > > > > > > No. It's constrained by memcg limits only. It can allocate gigabytes. > > > > > > > > I'm confused. A BPF program is limited to executing 4096 insns and > > > > using a maximum of 512 bytes of stack space, but it can allocate an > > > > unlimited amount of heap? That seems wrong. > > > > > > 4k insn limit was lifted years ago. > > > > You might want to update the documentation. > > https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.html > > still says 4096. > > No. Please read what you're quoting first. I did read it. It says : The only limit known to the user space is BPF_MAXINSNS (4096). It’s the : maximum number of instructions that the unprivileged bpf program can have. It really seems pretty clear to me. You're saying my understanding is wrong. So it must be badly written. Even now, I don't understand how I've misunderstood it. > > > bpf progs are pretty close to be at parity with kernel modules. > > > Except that they are safe, portable, and users have full visibility into them. > > > It's not a blob of bytes unlike .ko. > > > > It doesn't seem unreasonable to expect them to behave like kernel > > modules, then. If they want to allocate memory in NMI context, then > > they should get to preallocate it before they go into NMI context. > > You're still missing 'any context' part from the previous email. Really, this is not a productive way to respond. I want to help and you're just snarling at me.