Received: by 2002:ab2:1347:0:b0:1f4:ac9d:b246 with SMTP id g7csp354446lqg; Thu, 11 Apr 2024 05:21:38 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWi/4PDAS9M1+fyaTOjqtSKhiIWWH5qkFiRu38fTojYpE6tXeTwQIWlQ2Vlzy0DMI3K+jWSSSo00JllLz0/EX3gQWEMwOWztKEy/Hglgw== X-Google-Smtp-Source: AGHT+IEDw0ZAwxdAVwwgniVpqLZz/QxmBR0iH8/e7YB7rN+f1ePnWxfkPAxE52VRH2Pm+3Jffxda X-Received: by 2002:a05:6358:4b45:b0:183:9ea4:74ab with SMTP id ks5-20020a0563584b4500b001839ea474abmr6006641rwc.31.1712838097961; Thu, 11 Apr 2024 05:21:37 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712838097; cv=pass; d=google.com; s=arc-20160816; b=F2CerBcHxY3gx47+TyhXu7pE+MeF1ojSFBUqmLABZZkSKSan+54inI/hxsZ3E9YIhy W357A91BsQuqxpv9rdGFzf2zKTc6V7PyecZGbkk5fOJlR+6LxGKWFPc0kHKinPd+bZtS 5sHD5XLtrWQ1ZY/oQOezxrN9/05eNjLJ1/MxSLER5GzyZi+AlWFYVA2Ud6cHzlQqX6rG teSZLbQ8L9AIBoxzarkWzlgyQRsAqjS2VmRWSDuil2tmzSyc27zUYJkLyb0IFVucEYVu bbxP1cNIJB4BChkDjtnjg4soH4Fun++QGd1qcWdf5NJZ38TV4JWOfRtSbp8oBH8PGTt0 XkNg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:list-unsubscribe:list-subscribe :list-id:precedence:dkim-signature; bh=ucpZc0sOAIBf0HKCIhwEI0FsYmNzoD9YG5D9Q7DejMI=; fh=DgdR50Jb8Md89ncNBLL6jOepqccBHpDLShuBQHF76w4=; b=fVHoDqbSiRcAbEEmtOSX31I+H9487dRVcXzOgtUz9jl1kwlIgUt9ZNU7VjMZJfVUTa i9NVSDrPDXHj5I5S/EQvPeWFwxTQklkJc1C0B+y3azHDXngEYpmkAObDX2YSKtpUkOK7 Usv01pmiH7JZ5YEpEHh2HQJgZ5ux5/hI+lPAdizcbg8RfVH5uJtuspG6muFa2KiLWdo4 zEe7p0XzcSyCpS1DHlntzZrmxPwhtuj8OLsy6kPH1SXKoIZpQRnRrJC10Kajlf/LsZHv kBryrqnADGcvr9YG/IvCfKIk6tP3evpzqVEITs5HXx69JGgc3TR6LmSqQKn/uneV10yQ qb9Q==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kylehuey.com header.s=google header.b=TdE0uGBy; arc=pass (i=1 spf=pass spfdomain=kylehuey.com dkim=pass dkdomain=kylehuey.com); spf=pass (google.com: domain of linux-kernel+bounces-140411-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-140411-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id d18-20020a63f252000000b005e485fc4266si1208969pgk.388.2024.04.11.05.21.37 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Apr 2024 05:21:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-140411-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@kylehuey.com header.s=google header.b=TdE0uGBy; arc=pass (i=1 spf=pass spfdomain=kylehuey.com dkim=pass dkdomain=kylehuey.com); spf=pass (google.com: domain of linux-kernel+bounces-140411-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-140411-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id C0967B2437E for ; Thu, 11 Apr 2024 12:11:55 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5EE8614AD36; Thu, 11 Apr 2024 12:11:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kylehuey.com header.i=@kylehuey.com header.b="TdE0uGBy" Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A934814AD35 for ; Thu, 11 Apr 2024 12:11:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712837506; cv=none; b=f4iPXbMs26In6G2scFTWFCDoRj7eYnGCqHLf4qfrtbK1F9RM3wV7yeZ9ZJt52RKlKLd/0fPiHXHac6t043ZgHx1fddpA7lNGTTcXdt7EuiSGiFcCI6XHil70C8ZioR7F3ln93TSCvskw5iRcSvXWOS5+PPyjf+LibxSlnCYCXIE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712837506; c=relaxed/simple; bh=itSQk2b/qeERn9WLQJ1lpDYwPMRo4EGLiCJYs3ABnM4=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=NYzKw0nKcXcPlJ+7K87rdsV/SiBvJ4puSPnWhVDMJ8UoBZ7XHN70hOTwMf3LnSG0xM61zWxgfqQCW0IPepTLxy/mS3SMuTpVuOteY5p3IsPhVCvAwQ8yz4Yc2ae3EpUGwszKiyF32qmY4gqhTl+AMvpacfShF/w7xWwxnmdbPjg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kylehuey.com; spf=pass smtp.mailfrom=kylehuey.com; dkim=pass (2048-bit key) header.d=kylehuey.com header.i=@kylehuey.com header.b=TdE0uGBy; arc=none smtp.client-ip=209.85.208.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kylehuey.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kylehuey.com Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-56e509baddaso4933236a12.1 for ; Thu, 11 Apr 2024 05:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kylehuey.com; s=google; t=1712837503; x=1713442303; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ucpZc0sOAIBf0HKCIhwEI0FsYmNzoD9YG5D9Q7DejMI=; b=TdE0uGByLu4vaXVla5g+rhIlo1ZpcPlP1q68tv+MGIqLpruVpHOk6GSUiLgY3oLvZk CMT/X73OoQ+FocBDWUD614dolJJSnaxifMTwaisaqUDRW+BH3NbHGIL5/VHoy73h2U7A 1dd1mEprRI3ivF1rE+9hgdnwjcKfUweuol1LIyQMWxsVSCADeovL4qrvx8Fj2xSXDikn SKdnsAvi2qhYHGtKXs0DMkH85yI9STG5w0gY/Mvvavx5OxhhS9JZ62Yc0Q4XE5Krb4/6 pzTMPff2Km+dBLoy/NWzHZ0TAYUVXucCdR36U4fV8tsMp+ZW2BsKY+i3bpvFv/dsGXY9 jtGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712837503; x=1713442303; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ucpZc0sOAIBf0HKCIhwEI0FsYmNzoD9YG5D9Q7DejMI=; b=R3fkyySG7H4oavk7GMcgKV49wEkNN62Mekl9fYkIht9/fZuOMjhylwdp3y5LYQHM3I oHvqoSHqGL7Grb4S6eB7BDTMLqwAfId2KwD5NehE4Ew9rciTzvX61lEfoQroW3i7pABt dDKNDADmS37KYkRODt0ypEUOI4kcOkf9TvxuEHxQmF+CAf1Z6oYEaUvuwgW8r6+9M8MZ zH2ijpWTyqOKF1eH573j+aJhAKE5eWYg7zZOxya+03enGLkRoMUuH0PugHVG988xgbBt 0awqfiWxGLWXq2ytYkm5YE2/huwL67PfSseHUQKgLCDgGp1c17ctyrIVtFNTN757U+H4 JOsA== X-Gm-Message-State: AOJu0YyGY5hjq2cNyNXIA6jQ7ljf+AyvZIY7S2rElFyAZ/Cy0pOTRfGh 0BBdulFDn/I1JANXM/9u7AiM9pzjP7/Mk9NCBp1Lf3Osh/cmiMVlUyEvbV0p8XWJsbx/mwtFI57 21MhylfGZEWws1iSLRvouebSpY49taNnsqS3I X-Received: by 2002:a50:9558:0:b0:56e:4ac1:88f with SMTP id v24-20020a509558000000b0056e4ac1088fmr3825888eda.27.1712837502837; Thu, 11 Apr 2024 05:11:42 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240214173950.18570-1-khuey@kylehuey.com> <20240214173950.18570-2-khuey@kylehuey.com> In-Reply-To: From: Kyle Huey Date: Thu, 11 Apr 2024 08:11:28 -0400 Message-ID: Subject: Re: [RESEND PATCH v5 1/4] perf/bpf: Call bpf handler directly, not through overflow machinery To: Ingo Molnar Cc: linux-kernel@vger.kernel.org, Andrii Nakryiko , Jiri Olsa , Namhyung Kim , Marco Elver , Yonghong Song , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , "Robert O'Callahan" , Song Liu , Mark Rutland , Alexander Shishkin , Ian Rogers , Adrian Hunter , linux-perf-users@vger.kernel.org, bpf@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 10, 2024 at 12:32=E2=80=AFAM Ingo Molnar wro= te: > > > * Kyle Huey wrote: > > > To ultimately allow bpf programs attached to perf events to completely > > suppress all of the effects of a perf event overflow (rather than just = the > > sample output, as they do today), call bpf_overflow_handler() from > > __perf_event_overflow() directly rather than modifying struct perf_even= t's > > overflow_handler. Return the bpf program's return value from > > bpf_overflow_handler() so that __perf_event_overflow() knows how to > > proceed. Remove the now unnecessary orig_overflow_handler from struct > > perf_event. > > > > This patch is solely a refactoring and results in no behavior change. > > > > Signed-off-by: Kyle Huey > > Suggested-by: Namhyung Kim > > Acked-by: Song Liu > > Acked-by: Jiri Olsa > > --- > > include/linux/perf_event.h | 6 +----- > > kernel/events/core.c | 28 +++++++++++++++------------- > > 2 files changed, 16 insertions(+), 18 deletions(-) > > > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h > > index d2a15c0c6f8a..c7f54fd74d89 100644 > > --- a/include/linux/perf_event.h > > +++ b/include/linux/perf_event.h > > @@ -810,7 +810,6 @@ struct perf_event { > > perf_overflow_handler_t overflow_handler; > > void *overflow_handler_context; > > #ifdef CONFIG_BPF_SYSCALL > > - perf_overflow_handler_t orig_overflow_handler; > > struct bpf_prog *prog; > > u64 bpf_cookie; > > #endif > > Could we reduce the #ifdeffery please? Not easily. > On distros CONFIG_BPF_SYSCALL is almost always enabled, so it's not like > this truly saves anything on real systems. > > I'd suggest making the perf_event::prog and perf_event::bpf_cookie fields > unconditional. That's not sufficient. See below. > > +#ifdef CONFIG_BPF_SYSCALL > > +static int bpf_overflow_handler(struct perf_event *event, > > + struct perf_sample_data *data, > > + struct pt_regs *regs); > > +#endif > > If the function definitions are misordered then first do a patch that mov= es > the function earlier in the file, instead of slapping a random prototype > into a random place. Ok. > > - READ_ONCE(event->overflow_handler)(event, data, regs); > > +#ifdef CONFIG_BPF_SYSCALL > > + if (!(event->prog && !bpf_overflow_handler(event, data, regs))) > > +#endif > > + READ_ONCE(event->overflow_handler)(event, data, regs); > > This #ifdef would go away too - on !CONFIG_BPF_SYSCALL event->prog should > always be NULL. bpf_overflow_handler() is also #ifdef CONFIG_BPF_SYSCALL. It uses bpf_prog_active, so that would need to be moved out of the ifdef, which would require moving the DEFINE_PER_CPU out of bpf/syscall.c ... or I'd have to add a !CONFIG_BPF_SYSCALL definition of bpf_overflow_handler() that only returns 1 and never actually gets called because the condition short-circuits on event->prog. Neither seems like it makes my patch or the code simpler, especially since this weird ifdef-that-applies-only-to-the-condition goes away in Part 3 where I actually change the behavior. It feels like the root of your objection is that CONFIG_BPF_SYSCALL exists at all. I could remove it in a separate patch if there's consensus about that. > Please keep the #ifdeffery reduction and function-moving patches separate > from these other changes. > > Thanks, > > Ingo - Kyle