On Fri, 19 Jan 2018 07:35:01 +0000 Lina Iyer <ilina@xxxxxxxxxxxxxx> wrote: > Hi Steven, > > On Thu, Jan 18 2018 at 01:26 +0000, Steven Rostedt wrote: > > > >I wasn't Cc'd on the rest of the patches and this wasn't Cc'd to LKML, > >and I'm not on any of the mailing lists that were Cc'd, I gotta just > >look at what I have here in this patch. > > > I am so sorry. Will add LKML in the future. Thanks. It's just that I had little context to review the patch from. > >> struct rsc_drv *drv = (struct rsc_drv *)data; > >> struct tcs_response *resp; > >> unsigned long flags; > >> - int err; > >> + int err, m; > >> + struct tcs_mbox_msg *msg; > >> > >> do { > >> spin_lock_irqsave(&drv->drv_lock, flags); > >> @@ -364,7 +370,10 @@ static void tcs_notify_tx_done(unsigned long data) > >> list_del(&resp->list); > >> spin_unlock_irqrestore(&drv->drv_lock, flags); > >> err = resp->err; > >> + m = resp->m; > >> + msg = resp->msg; > >> free_response(resp); > >> + trace_rpmh_notify(drv->name, m, msg->payload[0].addr, err); > > > >The reason I ask, is that this is causing more code to be executed > >even when tracing is off. What about passing in resp and assigning it > >within the tracepoint. > > > > trace_rpmh_notify(drv->name, resp); > > > The free_response(resp) will free the resp object and accessing resp->m > is invalid after that. What about placing the trace before the free? -- Steve -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html