On 2018-11-18 1:19 a.m., David Miller wrote: > From: Mathieu Desnoyers <mathieu.desnoy...@efficios.com> > 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.
