Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752150AbbBKK3D (ORCPT ); Wed, 11 Feb 2015 05:29:03 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:45687 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751065AbbBKK3A (ORCPT ); Wed, 11 Feb 2015 05:29:00 -0500 Date: Wed, 11 Feb 2015 11:28:52 +0100 From: Peter Zijlstra To: Steven Rostedt Cc: Alexei Starovoitov , Ingo Molnar , Namhyung Kim , Arnaldo Carvalho de Melo , Jiri Olsa , Masami Hiramatsu , Linux API , Network Development , LKML , Linus Torvalds , ebiederm@xmission.com Subject: Re: [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls Message-ID: <20150211102852.GQ23123@twins.programming.kicks-ass.net> References: <20150210165359.34cc53d9@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150210165359.34cc53d9@gandalf.local.home> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1682 Lines: 38 On Tue, Feb 10, 2015 at 04:53:59PM -0500, Steven Rostedt wrote: > > >> In the future we might add a tracepoint and pass a single > > >> pointer to interesting data struct to it. bpf programs will walk > > >> data structures 'as safe modules' via bpf_fetch*() methods > > >> without exposing it as ABI. > > > > > > Will this work if that structure changes? When the field we are looking > > > for no longer exists? > > > > bpf_fetch*() is the same mechanism as perf probe. > > If there is a mistake by user space tools, the program > > will be reading some junk, but it won't be crashing. > > But what if the userspace tool depends on that value returning > something meaningful. If it was meaningful in the past, it will have to > be meaningful in the future, even if the internals of the kernel make > it otherwise. We're compiling the BPF stuff against the 'current' kernel headers right? So would enforcing module versioning not be sufficient? We already break out-of-tree modules without a second thought, the module interface is not guaranteed. They just need to cope with it. Anything using the kernel headers to look into the kernel guts should be bound to the same rules. So if we think of BFP stuff as out-of-tree modules, and treat them the same, I see no problem. I'm sure some BFP 'scripts' will turn in the same right mess that out-of-tree modules are, with endless #ifdef version checks, but hey, not my problem ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/