Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752785AbbBXNhF (ORCPT ); Tue, 24 Feb 2015 08:37:05 -0500 Received: from mail-vc0-f169.google.com ([209.85.220.169]:33228 "EHLO mail-vc0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751776AbbBXNgu (ORCPT ); Tue, 24 Feb 2015 08:36:50 -0500 MIME-Version: 1.0 In-Reply-To: <1424778476-28242-1-git-send-email-james.hogan@imgtec.com> References: <1424778476-28242-1-git-send-email-james.hogan@imgtec.com> Date: Tue, 24 Feb 2015 08:36:48 -0500 Message-ID: Subject: Re: [PATCH] sunrpc: Fix trace events to store data in the struct From: Trond Myklebust To: James Hogan Cc: Jeff Layton , "J. Bruce Fields" , Linux Kernel Mailing List , Steven Rostedt , Ingo Molnar , Stable Tree Mailing List 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: 4126 Lines: 104 On Tue, Feb 24, 2015 at 6:47 AM, James Hogan wrote: > Commit 83a712e0afef ("sunrpc: add some tracepoints around enqueue and > dequeue of svc_xprt") merged in v3.19-rc1 added some new trace events, > however a couple of them printed data from dereferenced pointers rather > than storing the data in the struct. In general this isn't safe as the > print may not happen until later when the data may have changed or been > freed, and nor is it portable as userland won't have access to that > other data in order to interpret the trace data itself. > > Fix by copying the data into the struct and printing from there. > > Fixes: 83a712e0afef ("sunrpc: add some tracepoints around enqueue ...") > Signed-off-by: James Hogan > Cc: Jeff Layton > Cc: J. Bruce Fields > Cc: Trond Myklebust > Cc: Steven Rostedt > Cc: Ingo Molnar > Cc: # v3.19+ > --- > Build tested only. Perhaps somebody familiar with the code could give it > a spin to sanity check the trace output. > --- > include/trace/events/sunrpc.h | 22 +++++++++++++++------- > 1 file changed, 15 insertions(+), 7 deletions(-) > > diff --git a/include/trace/events/sunrpc.h b/include/trace/events/sunrpc.h > index b9c1dc6c825a..47dfcaebfaaf 100644 > --- a/include/trace/events/sunrpc.h > +++ b/include/trace/events/sunrpc.h > @@ -503,18 +503,22 @@ TRACE_EVENT(svc_xprt_do_enqueue, > > TP_STRUCT__entry( > __field(struct svc_xprt *, xprt) > - __field(struct svc_rqst *, rqst) > + __field_struct(struct sockaddr_storage, ss) > + __field(unsigned long, flags); > + __field(int, pid) > ), > > TP_fast_assign( > __entry->xprt = xprt; > - __entry->rqst = rqst; > + xprt ? memcpy(&__entry->ss, &xprt->xpt_remote, sizeof(__entry->ss)) : memset(&__entry->ss, 0, sizeof(__entry->ss)); How could xprt ever be NULL here, and even if it was, why the esoteric C instead of a simple 'if' statement? > + __entry->flags = xprt ? xprt->xpt_flags : 0; > + __entry->pid = rqst ? rqst->rq_task->pid : 0; > ), > > TP_printk("xprt=0x%p addr=%pIScp pid=%d flags=%s", __entry->xprt, > - (struct sockaddr *)&__entry->xprt->xpt_remote, > - __entry->rqst ? __entry->rqst->rq_task->pid : 0, > - show_svc_xprt_flags(__entry->xprt->xpt_flags)) > + (struct sockaddr *)&__entry->ss, > + __entry->pid, > + show_svc_xprt_flags(__entry->flags)) > ); > > TRACE_EVENT(svc_xprt_dequeue, > @@ -562,17 +566,21 @@ TRACE_EVENT(svc_handle_xprt, > > TP_STRUCT__entry( > __field(struct svc_xprt *, xprt) > + __field_struct(struct sockaddr_storage, ss) > + __field(unsigned long, flags); > __field(int, len) > ), > > TP_fast_assign( > __entry->xprt = xprt; > + xprt ? memcpy(&__entry->ss, &xprt->xpt_remote, sizeof(__entry->ss)) : memset(&__entry->ss, 0, sizeof(__entry->ss)); Ditto. > + __entry->flags = xprt ? xprt->xpt_flags : 0; > __entry->len = len; > ), > > TP_printk("xprt=0x%p addr=%pIScp len=%d flags=%s", __entry->xprt, > - (struct sockaddr *)&__entry->xprt->xpt_remote, __entry->len, > - show_svc_xprt_flags(__entry->xprt->xpt_flags)) > + (struct sockaddr *)&__entry->ss, __entry->len, > + show_svc_xprt_flags(__entry->flags)) > ); > #endif /* _TRACE_SUNRPC_H */ > > -- > 2.0.5 > -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/