Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5113502imu; Tue, 8 Jan 2019 11:45:35 -0800 (PST) X-Google-Smtp-Source: ALg8bN4Y8QXbDBv8/KIizyrUbeB2XfNbLZb4GgvqcQntrjkw3ic3wkHqLo9ZDevVR0GtucrGBozx X-Received: by 2002:a63:d34a:: with SMTP id u10mr2708548pgi.301.1546976735562; Tue, 08 Jan 2019 11:45:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546976735; cv=none; d=google.com; s=arc-20160816; b=urBgLgzq3VKeaMpzkzJbtF4IAEkHhILg5jwqz7tAeacqepXH1VcQc8/rMNAsxANwmN YqW4qFJ1yjmRIc9ERWXyWEpKucQwamxJbUgvT8DOHWp26V2Ze0RnjSdlmbxcgA7EtVZR DuYD0GUvqA30OsbH7hi7him2VE2drBq34NJ8hzTJhoX6xny8wmDkfzFOzS9/LY+sYGjt KoFxMqrurm+XZpexQqDFp5bByBp+TYkRMZnIFoiLK5/rKt7KVNhrEcJ+d2623NhXqqwO 7jpF6CQ68wDUEopjuLPwAx/AE+kgF7SsMLDQwDAAJGIl8j/E+8OJ317PF5Xk1ZcGe4K3 Mlsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=AUOfq+X9RJimQkb3B3mEHNGAavaLitn3Hl8uHiWIqCc=; b=I96nggPDFqjmjAUPxb/X/47TReMXU8owN2gBl885IJUv+WPqJf40giUMh0oGjrREaC S8buLuxkQxMY6Cp6ZIRrpYGuXq/9Lmdj/tZWDJs/Sh7GzDHTaKxFINflTshnRES4HleV OgMTx7+CsGd5lRwQcQnXHGuS8nT7lePu/Y06Yp1Ve1dswJ8WngfJGPxMlJqbL6epRIGz hIRRvEmR9tAqDydRzNAXG2MPL55ZwiMj6Xm07LeIpKRTDNWsh4JTpvXahmo5dNiQtli+ 5kvM6nIGlf7Q8L03r2W1r5dWeetInaQAgvpR7XJLjfFwUvZ7PLKDiNL6r5mIFsjHzxra XWoA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=iwdJtN8l; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b11si18811998pla.405.2019.01.08.11.45.20; Tue, 08 Jan 2019 11:45:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=iwdJtN8l; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732726AbfAHTn2 (ORCPT + 99 others); Tue, 8 Jan 2019 14:43:28 -0500 Received: from merlin.infradead.org ([205.233.59.134]:56218 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731966AbfAHTn0 (ORCPT ); Tue, 8 Jan 2019 14:43:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AUOfq+X9RJimQkb3B3mEHNGAavaLitn3Hl8uHiWIqCc=; b=iwdJtN8lmLFDvwKdHO8r4GiGb fgAolE2IgxlTVTE+Rd2Trs0thFfChaK+U+a7PHrbKyhxphfWuDoRPabef2F4f4BIokXB/kajx22g3 eEXhl2mv34FzZ77oHG/KtQ1dS718Yy6DnwUN1bUkDGvvXPgPj9OMBIUk3TNNSNWjSIdn+/JS8W7zD w7SoZFiws0XwH5pYlCj8oOd6G85Fz26YrVW/uvQvky7uMZ8kfN3fiVhwXeeFIFb3cbetwySyp+FD5 zUktCBUEsdpfPq2NoHVQEiRl/xKrD1747/u7FCUZvk4WSceEKvblUwf4wpIvVLae43+mfCtJ/vgUm pS7XcN15A==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1ggxHL-0003mI-V5; Tue, 08 Jan 2019 19:43:12 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 69A3520280192; Tue, 8 Jan 2019 20:43:10 +0100 (CET) Date: Tue, 8 Jan 2019 20:43:10 +0100 From: Peter Zijlstra To: Song Liu Cc: lkml , "netdev@vger.kernel.org" , "acme@kernel.org" , "ast@kernel.org" , "daniel@iogearbox.net" , Kernel Team , Andi Kleen Subject: Re: [PATCH v5 perf, bpf-next 3/7] perf, bpf: introduce PERF_RECORD_BPF_EVENT Message-ID: <20190108194310.GD1900@hirez.programming.kicks-ass.net> References: <20181220182904.4193196-1-songliubraving@fb.com> <20181220182904.4193196-4-songliubraving@fb.com> <20190108184116.GC30894@hirez.programming.kicks-ass.net> <77A478D9-F36F-443A-BBFD-F0C1FFE0DD90@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77A478D9-F36F-443A-BBFD-F0C1FFE0DD90@fb.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 08, 2019 at 07:10:20PM +0000, Song Liu wrote: > > On Jan 8, 2019, at 10:41 AM, Peter Zijlstra wrote: > > On Thu, Dec 20, 2018 at 10:29:00AM -0800, Song Liu wrote: > >> @@ -986,9 +987,35 @@ enum perf_event_type { > >> */ > >> PERF_RECORD_KSYMBOL = 17, > >> > >> + /* > >> + * Record bpf events: > >> + * enum perf_bpf_event_type { > >> + * PERF_BPF_EVENT_UNKNOWN = 0, > >> + * PERF_BPF_EVENT_PROG_LOAD = 1, > >> + * PERF_BPF_EVENT_PROG_UNLOAD = 2, > >> + * }; > >> + * > >> + * struct { > >> + * struct perf_event_header header; > >> + * u16 type; > >> + * u16 flags; > >> + * u32 id; > >> + * u8 tag[BPF_TAG_SIZE]; > >> + * struct sample_id sample_id; > >> + * }; > >> + */ > >> + PERF_RECORD_BPF_EVENT = 18, > >> + > > > > Elsewhere today, I raised the point that by the time (however short > > interval) userspace gets around to reading this event, the actual > > program could be gone again. > > > > In this case the program has been with us for a very short period > > indeed; but it could still have generated some samples or otherwise > > generated trace data. > > Since we already have the separate KSYMBOL events, BPF_EVENT is only > required for advanced use cases, like annotation. So I guess missing > it for very-short-living programs should not be a huge problem? > > > It was suggested to allow pinning modules/programs to avoid this > > situation, but that of course has other undesirable effects, such as a > > trivial DoS. > > > > A truly horrible hack would be to include an open filedesc in the event > > that needs closing to release the resource, but I'm sorry for even > > suggesting that **shudder**. > > > > Do we have any sane ideas? > > How about we gate the open filedesc solution with an option, and limit > that option for root only? If this still sounds hacky, maybe we should > just ignore when short-living programs are missed? I'm afraid we might also 'need' this for the kallsym thing. The problem is that things like Intel PT (ARM Coresight too IIRC) encode a bitstream of branch-taken decisions. The only way to decode that and reconstruct the actual code-flow is with an exact matching text image. In order to have this matching text we need to be able to copy out every piece of dynamic text (from kcore) that has ever executed before it dissapears. Elsewhere (*), Andi suggests to have a kind of text-free fence interface, where userspace can call a complete. And I suppose as long we know there is a consumer, we also know we'll not be blocked indefinitely. So it would have to be slightly more complicated than suggested, but I think that is something we could work with. It would also not complicate these events. [*] https://lkml.kernel.org/r/20190108172721.GN6118@tassilo.jf.intel.com