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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52411C28EB8 for ; Thu, 6 Jun 2019 22:14:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2863C2064A for ; Thu, 6 Jun 2019 22:14:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b="rkRXhFjo" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729087AbfFFWOB (ORCPT ); Thu, 6 Jun 2019 18:14:01 -0400 Received: from mail-qt1-f193.google.com ([209.85.160.193]:32900 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729055AbfFFWOA (ORCPT ); Thu, 6 Jun 2019 18:14:00 -0400 Received: by mail-qt1-f193.google.com with SMTP id 14so115364qtf.0 for ; Thu, 06 Jun 2019 15:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=wnCP9LHM/9q0T5YeodyvkG+3NIqd4AJlc0R/psluHCw=; b=rkRXhFjoWZ55fC7yOH0kqTaTRrdB3k1BaYHKrXwOKlqO3Lj8E6y/3m1kxlPHJqvDuB HNe1HZo/hCsDKBHtjOvQROjpjNuFhCqgVO7E1LX8Q5+Geiicmg9mBwYI+ORkSAoVoy4I 1ZkXqeaN2WWOdhlzsnngXpW4Ia72ASBbOYQfvxQ+rQFbMv+LQztxgzoK43w8G5eDI9fP tucUOZ4RXAh9xTMuR0M2NH9GcDV14lib62h28GA9yhBw2zzDbJEnjjaB+5ihjRKTMKUe cbO26PuTtbkDvEHYWS6DX3xlj4q6Ht1GFJ/IshA9ckkHTGXw9/wN9eD+chib8Npf95xN 9FZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=wnCP9LHM/9q0T5YeodyvkG+3NIqd4AJlc0R/psluHCw=; b=DGB0itXx93COMMJBgg1hmmTNatKCZ+7UBO/FgGrDixn2MelWgEubiKqr9e3eyhkPbV p7SqpDmx9NaNI59+y+8uFL1aXTwPcbC5PrPSGeQKXLV6RREoobBQuS+rDA47lwAqnCED ER+UKNzZPIr9d9qjjvFAKoo9Bmq+Dp89LmBNuvlEre+GMcNrhFq/IkJvGVNsUU/zY+jB o4MXp57JMPOSm6/cjZ2pi66trhfXwRq61X35h70tacLRI9+YXQhVQVhy2CD4S7UKR1RG WwHgZjMWwtE05UGeQ29zlUeFz4kP3mXOUJrIzwwAM1OwQ1qJ4GbQR4O3bP/2GBtbk5aC W61A== X-Gm-Message-State: APjAAAVCyzPy8M339NIQasRNZxnaW8FLkSKiPJ9XYf4pYlP1N00N+Hdy FoeDCVOyW3CKQAM5cAB0BAO4Rg== X-Google-Smtp-Source: APXvYqw1rzC6OTnpZ+39/hsG12pO3JpYun3yNbCTLHGF4Q6Fiw2lxqwEaCapVXUEIan7qToQI0uIKg== X-Received: by 2002:ac8:2e84:: with SMTP id h4mr42663472qta.267.1559859238493; Thu, 06 Jun 2019 15:13:58 -0700 (PDT) Received: from cakuba.netronome.com ([66.60.152.14]) by smtp.gmail.com with ESMTPSA id s23sm187901qtj.56.2019.06.06.15.13.55 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 06 Jun 2019 15:13:58 -0700 (PDT) Date: Thu, 6 Jun 2019 15:13:46 -0700 From: Jakub Kicinski To: Matt Mullins Cc: , , , , , , Steven Rostedt , "Ingo Molnar" , Martin KaFai Lau , Song Liu , Yonghong Song Subject: Re: [PATCH bpf] bpf: fix nested bpf tracepoints with per-cpu data Message-ID: <20190606151346.6a9ed27e@cakuba.netronome.com> In-Reply-To: <20190606185427.7558-1-mmullins@fb.com> References: <20190606185427.7558-1-mmullins@fb.com> Organization: Netronome Systems, Ltd. MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, 6 Jun 2019 11:54:27 -0700, Matt Mullins wrote: > BPF_PROG_TYPE_RAW_TRACEPOINTs can be executed nested on the same CPU, as > they do not increment bpf_prog_active while executing. > > This enables three levels of nesting, to support > - a kprobe or raw tp or perf event, > - another one of the above that irq context happens to call, and > - another one in nmi context > (at most one of which may be a kprobe or perf event). > > Fixes: 20b9d7ac4852 ("bpf: avoid excessive stack usage for perf_sample_data") No comment on the code, but you're definitely missing a sign-off. > --- > This is more lines of code, but possibly less intrusive than the > per-array-element approach. > > I don't necessarily like that I duplicated the nest_level logic in two > places, but I don't see a way to unify them: > - kprobes' bpf_perf_event_output doesn't use bpf_raw_tp_regs, and does > use the perf_sample_data, > - raw tracepoints' bpf_get_stackid uses bpf_raw_tp_regs, but not > the perf_sample_data, and > - raw tracepoints' bpf_perf_event_output uses both...