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 4596FC43334 for ; Tue, 28 Jun 2022 05:01:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 361EC8E0002; Tue, 28 Jun 2022 01:01:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 311B08E0001; Tue, 28 Jun 2022 01:01:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 227EE8E0002; Tue, 28 Jun 2022 01:01:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 12FAD8E0001 for ; Tue, 28 Jun 2022 01:01:36 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id C7B0960FF9 for ; Tue, 28 Jun 2022 05:01:35 +0000 (UTC) X-FDA: 79626446550.30.DF59B58 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf30.hostedemail.com (Postfix) with ESMTP id 7374E80018 for ; Tue, 28 Jun 2022 05:01:35 +0000 (UTC) Received: by mail-ed1-f46.google.com with SMTP id fd6so15854563edb.5 for ; Mon, 27 Jun 2022 22:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UvXt0QKxGokC5Mv5jnCy49Hq+RV9N+QKHjY/AgslfQE=; b=Xvm/SGALCa2V/HdfC6/6G39xodSBynsjWfTEbvBnVzAklKNHzg6cl1Kg0cP/c1cmY9 1QNgFL6sYK0KuRb7f7sKB0gbNFX1mxNl4Md3OMpJYbiiM+TjHhmkSubdZb+PWlTLsHRN VeaWNzlaYqSmgGQm88PZfNsQ1ANpXcUe5Lo9sxlTg/Stnqyz7PwxP4eAjOEwRCi8TYCL pcLxt3PpZVu4txlRD07gUsKZqiXSMXEhxuuFoom3oJI4j31ojni4FHFNTWKKEY+miQw0 bvQakJyU1WBjogLnAA1osAAC6ZquqiKn+gojy7v9L6ZQWmGASDuoJ5EgYL/6oQXEIqJP MJOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UvXt0QKxGokC5Mv5jnCy49Hq+RV9N+QKHjY/AgslfQE=; b=yUnhzy0gn3Y+wwT9vpcyyE7tNbOvpYWSt68sRsjAmDGpfN9OK8wicHGBdR92r5nMDN ov3hegDswbY0PM/8U9hV1lb1D7mkwDijoe3INYw7jKvZqsSXb2znJXB/ECyDSuAN24vr q2+n0f59GS9LbLtcWm9nLp9CbnCLNkE0mF0VMIVXii0RG47JN8JO9mi7+9GiGdgUcHg+ L5YIqIVzsiOBq7PuvMkHJPws5xztJf9lqwFxij7Z9n9DYdxYEE8ybDxSmMffoVrHtFyc E0iOSg8ZRxorAAnknc0uH3DquYBHXzOThSLpxChFbPrBsOXMHhRCrge2Kov7rUqeRD5M kwog== X-Gm-Message-State: AJIora8W9h+LkLX1ZAkiMcD/2SYrg/nsc0wgajZJHjm8iUebJil5vV2d J8ObwhT9u3kYi+RJjiR8+znHiFxM9/0DKiLCeCY= X-Google-Smtp-Source: AGRyM1uzGh02quBk6k30rlvaoPSJftfTLX/CfrRCsVhdFDBzATRxnh9qlS6Inu2A13e+rniWlY8iJB0dTEuu7t+deks= X-Received: by 2002:a05:6402:2398:b0:435:9685:1581 with SMTP id j24-20020a056402239800b0043596851581mr20821978eda.333.1656392493970; Mon, 27 Jun 2022 22:01:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexei Starovoitov Date: Mon, 27 Jun 2022 22:01:22 -0700 Message-ID: Subject: Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator. To: Christoph Lameter Cc: Christoph Hellwig , David Miller , Daniel Borkmann , Andrii Nakryiko , Tejun Heo , Martin KaFai Lau , bpf , Kernel Team , linux-mm , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="Xvm/SGAL"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf30.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656392495; 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=UvXt0QKxGokC5Mv5jnCy49Hq+RV9N+QKHjY/AgslfQE=; b=LgHwtgvcPsDYkzya8Nokm3KKPjkcyabojfs5UqGotA8XkrtHCTN5EdJEVWpQD+q2jSSMLm 7P0hqHHTqIgLuu/XgwlF8u0Ew2BScnEFyOVjaTAPjWks/N10MGefl4q7iHWajghswQPx67 7Enb3PeTM8bE3AS1Ys4BIhWQ/DG1sqs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656392495; a=rsa-sha256; cv=none; b=0l/ddR68vF4F9LYp788YuP4/f94OMz62WZD18PjqMe7ytW2gjRmBbk5RUkeoL0fG5xSwku R1heAkNaL6wzSW8cjwl1IeIOVxqj106aWVrcGZwYAbEtZ8R1tgfXYHDYov3I/E0hlQl4pK dXMF2+RvMkdWauKGnwAGWwy/2tyst64= X-Stat-Signature: e9jhiiswgzhry643kgxk4brbopqck7zq X-Rspamd-Queue-Id: 7374E80018 X-Rspam-User: Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="Xvm/SGAL"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf30.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com X-Rspamd-Server: rspam12 X-HE-Tag: 1656392495-670893 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 Mon, Jun 27, 2022 at 5:17 PM Christoph Lameter wrote: > > > From: Alexei Starovoitov > > > > Introduce any context BPF specific memory allocator. > > > > Tracing BPF programs can attach to kprobe and fentry. Hence they > > run in unknown context where calling plain kmalloc() might not be safe. > > Front-end kmalloc() with per-cpu per-bucket cache of free elements. > > Refill this cache asynchronously from irq_work. > > GFP_ATOMIC etc is not going to work for you? slab_alloc_node->slab_alloc->local_lock_irqsave kprobe -> bpf prog -> slab_alloc_node -> deadlock. In other words, the slow path of slab allocator takes locks. Which makes it unsafe to use from tracing bpf progs. That's why we preallocated all elements in bpf maps, so there are no calls to mm or rcu logic. bpf specific allocator cannot use locks at all. try_lock approach could have been used in alloc path, but free path cannot fail with try_lock. Hence the algorithm in this patch is purely lockless. bpf prog can attach to spin_unlock_irqrestore and safely do bpf_mem_alloc.