mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Will Newton <will.newton@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	fweisbec@gmail.com,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ring_buffer: Ensure that buffer page data is aligned.
Date: Thu, 16 Jun 2011 13:24:29 -0400	[thread overview]
Message-ID: <1308245069.9218.148.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <BANLkTinO85w4G9nFjio4HtOcrS0u-Ezz1Q@mail.gmail.com>

On Thu, 2011-06-16 at 14:32 +0100, Will Newton wrote:
> On Thu, Jun 16, 2011 at 2:17 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > 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?
> 
> Yes, it's likely for all 64bit arches will be aligned correctly.

What arch is this exactly. Is it because 64bit variables must be aligned
on 8byte boundaries?

> 
> >>
> >> Signed-off-by: Will Newton <will.newton@imgtec.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.
> 
> I have modified that conditional in my local tree so the patch is not
> a nop there. Obviously it doesn't make any sense to merge that change
> yet. I thought this part of the patch was a reasonable cleanup to make
> the code a bit more self documenting though.

Unfortunately, if anything it confuses the code more. If I were
reviewing it and saw that we are aligning something that is already
aligned with the same value, I would question that code.

Now if/when your arch is merged, we can add this with the other changes
you have, which will make reviewing the code not as confusing.

-- Steve




  reply	other threads:[~2011-06-16 17:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-16 13:03 Will Newton
2011-06-16 13:17 ` Steven Rostedt
2011-06-16 13:32   ` Will Newton
2011-06-16 17:24     ` Steven Rostedt [this message]
2011-06-17 10:05       ` Will Newton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1308245069.9218.148.camel@gandalf.stny.rr.com \
    --to=rostedt@goodmis.org \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=will.newton@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®