linux-kernel - Re: [PATCH] ring_buffer: Ensure that buffer page data is aligned.

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: <1308230239.9218.137.camel@gandalf.stny.rr.com>
Date:	Thu, 16 Jun 2011 09:17:19 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Will Newton <will.newton@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>, fweisbec@...il.com,
	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ring_buffer: Ensure that buffer page data is aligned.

On Thu, 2011-06-16 at 14:03 +0100, Will Newton wrote:
> Explicitly align the start of the buffer page data array to the
> required arch alignment. This is required for architectures that
> require 8 byte alignment but do not have a 8 byte local_t.

What arch does that? A 32bit arch that forces 8 byte alignment?

> 
> Signed-off-by: Will Newton <will.newton@...tec.com>
> ---
>  kernel/trace/ring_buffer.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> I don't believe that any currently in-tree architecture is affected by
> this, but it can be an issue on 32bit architectures that require an
> 8 byte aligment but only have a 32bit local_t. I think it's potentially
> cleaner to make the alignment explicit anyway.
> 
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 0ef7b4b..36d5699 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -215,6 +215,8 @@ EXPORT_SYMBOL_GPL(tracing_is_on);
>  # define RB_ARCH_ALIGNMENT		8U
>  #endif
> 
> +#define RB_ALIGN_DATA		__aligned(RB_ARCH_ALIGNMENT)
> +

Note, the code above this is:

#define RB_EVNT_HDR_SIZE (offsetof(struct ring_buffer_event, array))
#define RB_ALIGNMENT		4U
#define RB_MAX_SMALL_DATA	(RB_ALIGNMENT * RINGBUF_TYPE_DATA_TYPE_LEN_MAX)
#define RB_EVNT_MIN_SIZE	8U	/* two 32bit words */

#if !defined(CONFIG_64BIT) || defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
# define RB_FORCE_8BYTE_ALIGNMENT	0
# define RB_ARCH_ALIGNMENT		RB_ALIGNMENT
#else
# define RB_FORCE_8BYTE_ALIGNMENT	1
# define RB_ARCH_ALIGNMENT		8U
#endif


Which means that when CONFIG_64BIT is not set, RB_ARCH_ALIGNMENT is 4.
This means that this patch is really a nop and doesn't do anything for
your arch.

-- Steve

>  /* define RINGBUF_TYPE_DATA for 'case RINGBUF_TYPE_DATA:' */
>  #define RINGBUF_TYPE_DATA 0 ... RINGBUF_TYPE_DATA_TYPE_LEN_MAX
> 
> @@ -363,7 +365,7 @@ EXPORT_SYMBOL_GPL(ring_buffer_event_data);
>  struct buffer_data_page {
>  	u64		 time_stamp;	/* page time stamp */
>  	local_t		 commit;	/* write committed index */
> -	unsigned char	 data[];	/* data of buffer page */
> +	unsigned char	 data[] RB_ALIGN_DATA;	/* data of buffer page */
>  };
> 
>  /*


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/