[lkml]   [2010]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Random scheduler/unaligned accesses crashes with perf lock events on sparc 64
    From: Frederic Weisbecker <>
    Date: Mon, 5 Apr 2010 21:40:58 +0200

    > It happens without CONFIG_FUNCTION_TRACER as well (but it happens
    > when the function tracer runs). And I hadn't your
    > perf_arch_save_caller_regs() when I triggered this.

    I think there's still something wrong with the ring buffer stuff on
    architectures like sparc64.

    Stephen, I'm looking at the 8-byte alignment fix that was made a few
    weeks ago, commit:

    commit 2271048d1b3b0aabf83d25b29c20646dcabedc05
    Author: Steven Rostedt <>
    Date: Thu Mar 18 17:54:19 2010 -0400

    ring-buffer: Do 8 byte alignment for 64 bit that can not handle 4 byte align

    and I'm not so sure it's completely correct.

    Originally, the ring buffer entries determine where the entry data
    resides (either &event->array[0] or &event->array[1]) based upon the

    Beforehand, in all cases:

    1) If length could be encoded into event->type_len (ie. <=
    RB_MAX_SMALL_DATA) then event->type_len holds the length
    and the event data starts at &event->array[0]

    2) Otherwise (length > RB_MAX_SMALL_DATA) the length is
    encoded into event->array[0] and the event data starts at

    But now, there is a new semantic when CONFIG_64BIT is true and
    CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is false (which isn't the right
    test btw, f.e. sparc 32-bit needs this handling just like sparc 64-bit
    does since it uses full 64-bit loads and stores to access u64 objects
    and thus will crash without proper alignment, the correct test should

    This new semantic is:

    1) Entries always encode the length in ->array[0] and ->type_len
    is set to zero.

    And then there are special cases like events of type
    RINGBUF_TYPE_PADDING which, even though ->type_len is non-zero, encode
    a length field in ->array[0] which is used by the ring buffer
    iterators such as rb_event_length(), but this only applies only if
    event->time_delta is non-zero. (Phew!)

    The commit adjusts the code in rb_calculate_event_length() to force 8
    byte chunks when RB_FORCE_8BYTE_ALIGNMENT is set. It also adjusted
    the rb_update_event() logic so that it unconditionally uses
    event->array[0] for the length on such platforms.

    However I don't see any logic added to ring_buffer_event_length()
    to handle this forcing. That alone can't explain the crashes
    Frederic and I are seeing, since only oprofile seems to use that
    helper function, but I can just imagine there might be other
    subtle bugs linering after the above commit.

    Anyways, that's just the inital potential problem I've discovered.
    I'll start auditing the rest of this code.

    I wonder if there's a simpler way to implement this alignment fix such
    that we don't have to constantly make sure scores of locations in
    ring_buffer.c get this magic exception case correct.

    We should probably also BUILD_BUG_ON() if BUF_PAGE_HDR_SIZE is not
    a multiple of the necessary alignment, since the ring buffer
    entries start at the end of that.

    Also I noticed (painfully :-) that 2.6.33 needs a backport of this
    alignment fix too, so we should submit it to -stable (once we sift
    out all the bugs of course).

     \ /
      Last update: 2010-04-06 04:19    [W:0.022 / U:76.528 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site