From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Genevi=c3=a8ve_Bastien?= Subject: Re: [PATCH v3] net: Add trace events for all receive exit points Date: Mon, 19 Nov 2018 10:27:50 -0500 Message-ID: <61fe529f-6f06-65fc-bc1c-043180e86cf9@versatic.net> References: <20181113201326.5627-1-gbastien@versatic.net> <20181116.195036.1120979831963497428.davem@davemloft.net> <1286988499.7245.1542479249307.JavaMail.zimbra@efficios.com> <20181117.221921.901866732366630755.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: netdev@vger.kernel.org, rostedt@goodmis.org, mingo@redhat.com To: David Miller , mathieu.desnoyers@efficios.com Return-path: Received: from s056.panelboxmanager.com ([174.142.230.146]:33614 "EHLO s056.panelboxmanager.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729683AbeKTBvv (ORCPT ); Mon, 19 Nov 2018 20:51:51 -0500 Received: from mailnull by s056.panelboxmanager.com with sa-checked (Exim 4.91) (envelope-from ) id 1gOlSt-00AfmZ-Gd for netdev@vger.kernel.org; Mon, 19 Nov 2018 10:27:55 -0500 In-Reply-To: <20181117.221921.901866732366630755.davem@davemloft.net> Content-Language: en-US-large Sender: netdev-owner@vger.kernel.org List-ID: On 2018-11-18 1:19 a.m., David Miller wrote: > From: Mathieu Desnoyers > Date: Sat, 17 Nov 2018 13:27:29 -0500 (EST) > >> I see two possible solutions: >> >> 1) Remove the "skb" argument from the sbk_exit tracepoints completely. >> Anyway, I think it's not really needed for analysis purposes because >> we can link the "entry" with the associated "exit" using the thread ID >> executing those tracepoints. (Genevi�ve, would that work for your >> analyses ?) >> >> 2) Move the skb_exit tracepoints before freeing the skb pointer. My >> concern here is that the instrumentation may become much uglier than >> the currently proposed patch. (I have not looked at the specifics >> though, so I may be wrong.) >> >> Do you have a preference between those two approaches, or perhaps you >> have an alternative solution in mind ? > I wonder how other situations handle this. > > About #2, if you put the tracepoint beforehand you can't log the > 'ret' value. So at least in that regard I prefer #1. > > If tracepoints generally handle this by matching up the thread > ID, then definitely that's how we should do it here too instead > of trying to use the SKB pointer for this purpose. I would go for #1 too, the "skb" is not used to match entry/exit, it is more the context in which they appear (thread, softirq, etc). And I did indeed get seg faults on my first attempt when I tried to use the existing templates. There's just the list tracepoint that would now log nothing, so there's no point looping through the list.