Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752212AbcKYXip (ORCPT ); Fri, 25 Nov 2016 18:38:45 -0500 Received: from mail-io0-f194.google.com ([209.85.223.194]:33024 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751041AbcKYXio (ORCPT ); Fri, 25 Nov 2016 18:38:44 -0500 MIME-Version: 1.0 In-Reply-To: <20161125214840.kexe5mj2yn4jtazi@thunk.org> References: <1479926662-21718-1-git-send-email-ross.zwisler@linux.intel.com> <1479926662-21718-4-git-send-email-ross.zwisler@linux.intel.com> <20161124173220.GR1555@ZenIV.linux.org.uk> <20161125024918.GX31101@dastard> <20161125041419.GT1555@ZenIV.linux.org.uk> <20161125070642.GZ31101@dastard> <20161125073747.GU1555@ZenIV.linux.org.uk> <20161125214840.kexe5mj2yn4jtazi@thunk.org> From: Linus Torvalds Date: Fri, 25 Nov 2016 15:38:41 -0800 X-Google-Sender-Auth: LsZ0JvU_O3d0eYLBj_k99ANfYQY Message-ID: Subject: Re: [PATCH 3/6] dax: add tracepoint infrastructure, PMD tracing To: "Theodore Ts'o" , Linus Torvalds , Al Viro , Dave Chinner , Ross Zwisler , Linux Kernel Mailing List , Andrew Morton , Christoph Hellwig , Dan Williams , Ingo Molnar , Jan Kara , Matthew Wilcox , Steven Rostedt , "linux-ext4@vger.kernel.org" , linux-fsdevel , linux-mm , "linux-nvdimm@lists.01.org" Cc: "linux-nvdimm@lists.01.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1941 Lines: 45 On Fri, Nov 25, 2016 at 1:48 PM, Theodore Ts'o wrote: > > There is a reason why people want to be able to do that, and that's > because kprobes doesn't give you access to the arguments and return > codes to the functions. Honestly, that's simply not a good reason. What if everybody did this? Do we pollute the whole kernel with this crap? No. And if not, then what's so special about something like afs that it would make sense there? The thing is, with function tracing, you *can* get the return value and arguments. Sure, you'll probably need to write eBPF and just attach it to that fentry call point, and yes, if something is inlined you're just screwed, but Christ, if you do debugging that way you shouldn't be writing kernel code in the first place. If you cannot do filesystem debugging without tracing every single function entry, you are doing something seriously wrong. Add a couple of relevant and valid trace points to get the initial arguments etc (and perhaps to turn on the function tracing going down the stack). > After all, we need *some* way of saying this can never be considered > stable. Oh, if you pollute the kernel with random idiotic trace points, not only are they not going to be considered stable, after a while people should stop pulling from you. I do think we should probably add a few generic VFS level breakpoints to make it easier for people to catch the arguments they get from the VFS layer (not every system call - if you're a filesystem person, you _shouldn't_ care about all the stuff that the VFS layer caches for you so that you never even have to see it). I do think that Al's "no trace points what-so-ever" is too strict. But I think a lot of people add complete crap with the "maybe it's needed some day" kind of mentality. The tracepoints should have a good _specific_ reason, and they should make sense. Not be randomly sprinkled "just because". Linus