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 2ACA6C43334 for ; Wed, 6 Jul 2022 18:55:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B6F466B0073; Wed, 6 Jul 2022 14:55:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B1F926B0074; Wed, 6 Jul 2022 14:55:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E64B6B0075; Wed, 6 Jul 2022 14:55:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8C7936B0073 for ; Wed, 6 Jul 2022 14:55:33 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 5DBEC34077 for ; Wed, 6 Jul 2022 18:55:33 +0000 (UTC) X-FDA: 79657578546.07.F819A09 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf22.hostedemail.com (Postfix) with ESMTP id 01DC8C0032 for ; Wed, 6 Jul 2022 18:55:32 +0000 (UTC) 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=KZFsk7y7JYTxqy6VfuUQHbE8FIEJpo9MA6tv6wo/JGs=; b=Oz2uJccQVkLS55Lx5ytdPT/WJR ruo6qPnDUq+tLeOgV2yw6UzYtTAe+aRFvCWXgY7tPCnNkF5D49fZp7p3j5Ba5LYSRQtcIKMnyhX0s aQwUGE5/j4+4gsa2o073inbxPUvlTKsWi7eqiM9LYGupnC8U/OZC1n6uwbhAA+HAZjM/Y6w9jjld5 e5b0YhYimRsDVo4t02BAiDHbc7hdS55K6gr3b9Jdz7bGSQ3UtbVCf31d4raNlD9Vs/ihq998nrc5S XbcCKEqYMlmT3JHaYkh5YyFj39K7AVfAAJ0zAoLOhyIbvrA+pYkGkr1PXo/eTei7nOPHVWSxfeFT/ 7Qyn9RcQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1o9ABB-001ta8-3z; Wed, 06 Jul 2022 18:55:17 +0000 Date: Wed, 6 Jul 2022 19:55:17 +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: <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> <20220706185103.jdybh757u5esokt3@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: <20220706185103.jdybh757u5esokt3@MacBook-Pro-3.local> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657133733; 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=KZFsk7y7JYTxqy6VfuUQHbE8FIEJpo9MA6tv6wo/JGs=; b=oCIIr2yYxhAPb7lHgKnTjdTiAVT65zOhAdbBFmqE3oN+oOEEubLMo9akuaFKUefUQX3LVD IcYqPD+C1Q4AljjifV1v6KW6nezLjG3L/1U8zea4sjYzdtvlF7AUuuMcb/35UudyzPMbgH CItFeSon+xGtg1LLJr9TXYRFVcnze2A= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Oz2uJccQ; dmarc=none; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657133733; a=rsa-sha256; cv=none; b=HIzfSq3jVcVCUN121bnB3920d6w4kbTTiIi+0Lw3DeilP9SzS2aCa5nkSaI2ZSqxdS3F4H 6la3Y+IUKOuL5A4mA0euZpmAqhOlJRz1UXrC8I2XRTjp6lFIW8c46XhJ8CehIY0YCN8+yr htsHNbAzn9lGU3bN0P0CaSG2Ej1QSRY= X-Rspamd-Server: rspam11 X-Rspam-User: X-Stat-Signature: qo4pasg7khm958sebp5ff7rgyuf1gdzq X-Rspamd-Queue-Id: 01DC8C0032 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Oz2uJccQ; dmarc=none; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-HE-Tag: 1657133732-596277 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 Wed, Jul 06, 2022 at 11:51:03AM -0700, Alexei Starovoitov wrote: > On Wed, Jul 06, 2022 at 07:40:44PM +0100, Matthew Wilcox wrote: > > 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. > > huh? Still missing 'unprivileged' in the above ? > and completely ignoring the rest of the paragraph in the link above? Are you saying that unprivileged programs are not allowed to allocate memory? Or that there is a limit on the amount of heap memory that unprivileged programs are allowed to allocate. > > > > > 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. > > To help you need to understand what bpf is while you're failing > to read the doc. Part of working with other people is understanding that they don't know as much as you do about your thing, and at the same time understanding that you don't know as much as they do about their thing. That means explaining things in a way which makes sense to them instead of getting all huffy when they don't understand the details of your thing.