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 linux-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
