linux-kernel - Re: [PATCH] sunrpc: Fix trace events to store data in the struct

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54EC885B.6090905@imgtec.com>
Date:	Tue, 24 Feb 2015 14:19:07 +0000
From:	James Hogan <james.hogan@...tec.com>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	Jeff Layton <jlayton@...marydata.com>,
	"J. Bruce Fields" <bfields@...hat.com>,
	<linux-kernel@...r.kernel.org>,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	Ingo Molnar <mingo@...hat.com>, <stable@...r.kernel.org>
Subject: Re: [PATCH] sunrpc: Fix trace events to store data in the struct

Hi Steven,

On 24/02/15 14:09, Steven Rostedt wrote:
> On Tue, 24 Feb 2015 11:47:56 +0000
> James Hogan <james.hogan@...tec.com> wrote:
> 
> 
> 
>>  	TP_printk("xprt=0x%p addr=%pIScp pid=%d flags=%s", __entry->xprt,
>> -		(struct sockaddr *)&__entry->xprt->xpt_remote,
> 
> There's actually nothing wrong with the above even if xprt is NULL.
> It's not dereferencing the structure, it is just getting the address of
> what would be dereference.

I think that corresponds to the %pIScp format which I presumed does
dereference the pointer?

Looking at Documentation/printk-formats.txt I see:

> IPv4/IPv6 addresses (generic, with port, flowinfo, scope):
> ...
>         %pISpc  1.2.3.4:12345   or [1:2:3:4:5:6:7:8]:12345

Same applies below. Should these formats still be avoided?

Thanks for reviewing,

Cheers
James

> 
>> -		__entry->rqst ? __entry->rqst->rq_task->pid : 0,
>> -		show_svc_xprt_flags(__entry->xprt->xpt_flags))
>> +		(struct sockaddr *)&__entry->ss,
> 
> The above is meaningless. You just printed the address of the ring
> buffer and this will be different (and useless) every time.
> 
>> +		__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));
>> +		__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,
> 
> Ditto.
> 
> Don't use field_struct() unless you really know what you are doing.
> This is copying the entire struct into the ring buffer and only using
> the address of that struct. Which not only is useless, but wastes a lot
> of space in the ring buffer.
> 
> -- Steve
> 
>> +		show_svc_xprt_flags(__entry->flags))
>>  );
>>  #endif /* _TRACE_SUNRPC_H */
>>  
> 


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)