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 9FCABC04AB5 for ; Thu, 6 Jun 2019 22:14:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 769252064A for ; Thu, 6 Jun 2019 22:14:01 +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 S1729081AbfFFWOA (ORCPT ); Thu, 6 Jun 2019 18:14:00 -0400 Received: from mail-qt1-f195.google.com ([209.85.160.195]:45707 "EHLO mail-qt1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729013AbfFFWOA (ORCPT ); Thu, 6 Jun 2019 18:14:00 -0400 Received: by mail-qt1-f195.google.com with SMTP id j19so52385qtr.12 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=c0NJUT91YkfXclOfcNnAgJzBswI1dqd4S5l5yyQqyMMqlO54km4T3RtD677GV8/KrP vHmN3vFsmofqbHC9wrZyC2+mDillxY8qXvYWdCZUIpSoE7pKyf3bfpNGRS8ChOYlLdrD a15aKpSR0Rj65lKdA/a3euB22/ZdOo+A1Wq7rDrTAwEbLhXle1B1jiXp+xkNDR0m6n75 VdHA6OyVEmVSNZV69BhgQ2Gxk1eUTIuRtBffkeKOYopqVi34BTPLLCQbpZXdQE9pb7vQ hoJUGMeVTvrmsEaaYTervBAcihGKdxzoLVxrmoW1XH2YbE4YCbcZ2U8GQ+Bca4u+2M3W MSFA== X-Gm-Message-State: APjAAAWeKTO8s7uMj9cQfs/iqiVlOkMYkmL2rkUB8mLTU3dXN56hLAqI 7GnCpSeu3xkrpmLu4sjWkO+FwA== 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: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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...