linux-kernel - Re: [RFC][PATCH 01/12 v3] x86/kvm/tracing: Use helper function trace_seq_buffer

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: <6B853B85-57F8-4004-A33E-3B4199804277@intel.com>
Date:	Tue, 4 Nov 2014 20:09:42 +0000
From:	"Rustad, Mark D" <mark.d.rustad@...el.com>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Kosina <jkosina@...e.cz>, Petr Mladek <pmladek@...e.cz>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [RFC][PATCH 01/12 v3] x86/kvm/tracing: Use helper function
 trace_seq_buffer_ptr()

On Nov 4, 2014, at 11:35 AM, Steven Rostedt <rostedt@...dmis.org> wrote:

> On Tue, 4 Nov 2014 14:09:54 -0500
> Steven Rostedt <rostedt@...dmis.org> wrote:
> 
>> On Tue, 4 Nov 2014 17:17:08 +0000
>> "Rustad, Mark D" <mark.d.rustad@...el.com> wrote:
>> 
>>> On Nov 4, 2014, at 7:52 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
>>> 
>>>> From: "Steven Rostedt (Red Hat)" <rostedt@...dmis.org>
>>>> 
>>>> To allow for the restructiong of the trace_seq code, we need users
>>>> of it to use the helper functions instead of accessing the internals
>>>> of the trace_seq structure itself.
>>>> 
>>>> Cc: Mark Rustad <mark.d.rustad@...el.com>
>>>> Cc: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
>>>> Cc: Paolo Bonzini <pbonzini@...hat.com>
>>>> Signed-off-by: Steven Rostedt <rostedt@...dmis.org>
>>>> ---
>>>> arch/x86/kvm/mmutrace.h | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>> 
>>>> diff --git a/arch/x86/kvm/mmutrace.h b/arch/x86/kvm/mmutrace.h
>>>> index 5aaf35641768..ce463a9cc8fb 100644
>>>> --- a/arch/x86/kvm/mmutrace.h
>>>> +++ b/arch/x86/kvm/mmutrace.h
>>>> @@ -22,7 +22,7 @@
>>>> 	__entry->unsync = sp->unsync;
>>>> 
>>>> #define KVM_MMU_PAGE_PRINTK() ({				        \
>>>> -	const u32 saved_len = p->len;					\
>>>> +	const char *saved_ptr = trace_seq_buffer_ptr(p);		\
>>> 
>>> I think the above should not be a const char *, because the location pointed to is surely being changed. It should either be a char * or a char * const.
>> 
>> Ah right. It should be 'char * const'.
>> 
> 
> Actually, I take that back. The contents of saved_ptr should not be
> modified.

At least not by the caller of the macro. The subsequent call to trace_seq_printf will be changing the contents at that address, but not through use of that pointer.

> It may seem strange, but the update is done via the trace_seq_printf().
> Then that content is return back to the user. The user should
> definitely *not* modify the contents of saved_ptr.

Agreed.

> This patch is good as is. It should not be a char *, or char * const.

Yes. I did further checking and agree. Although that memory will be written, it isn't written through that pointer and it is the best type as a return value.

> -- Steve
> 
> 
>> 
>>> 
>>>> 	static const char *access_str[] = {			        \
>>>> 		"---", "--x", "w--", "w-x", "-u-", "-ux", "wu-", "wux"  \
>>>> 	};							        \
>>>> @@ -41,7 +41,7 @@
>>>> 			 role.nxe ? "" : "!",				\
>>>> 			 __entry->root_count,				\
>>>> 			 __entry->unsync ? "unsync" : "sync", 0);	\
>>>> -	p->buffer + saved_len;						\
>>>> +	saved_ptr;							\
>>>> 		})
>>>> 
>>>> #define kvm_mmu_trace_pferr_flags       \
>>>> -- 
>>>> 2.1.1
>>> 
>> 
> 

Acked-by: Mark Rustad <mark.d.rustad@...el.com>

-- 
Mark Rustad, Networking Division, Intel Corporation


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