[lkml]   [2012]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Oops with DCACHE_WORD_ACCESS and ocfs2, autofs4
    On 3 May 2012 16:23, Nick Piggin <> wrote:
    > On 3 May 2012 15:57, Linus Torvalds <> wrote:
    >> On Wed, May 2, 2012 at 10:02 PM, Nick Piggin <> wrote:
    >>> Linus did you see this thread?
    >> I did not..
    >>>Any ideas what is going on?
    >> Note that the discussion about aligned allocations is irrelevant. It
    >> doesn't matter at all if the pathname allocation is aligned - what
    >> matters if whether the last *component* of the pathname is aligned or
    >> not, and that is not going to depend on the allocation alignment.
    >> The word-at-a-time code assumes that no allocation will be the last
    >> page (whether kmalloc or normal page allocation), which was always
    >> somewhat optimistic but I thought it would be true on PC's.
    >> And that %rbp value does *not* look like end-of-memory, but maybe
    >> there is something else than just the CONFIG_DEBUG_PAGEALLOC that
    >> causes us to punch holes even in the kernel memory map.
    >> Peter, Ingo - do we unmap kernel pages for PAT etc attributes?
    >> Jana, can you send me the whole dmesg for the bootup up to and
    >> including the oops?
    >> There are multiple ways to fix this, including just marking that
    >> unaligned word access as being able to take an exception, but I had
    >> hoped to avoid having to do that. There are alternatives, like always
    >> padding allocations up by 7 bytes, but those are nasty too. So I'd
    >> like to understand what triggers this for Jana, it's possible we can
    >> just work around that particular issue.
    > Ah, I see what you mean. kmalloc is padded to 8 bytes, but that's
    > irrelevant if the full string was exactly modulo 8 bytes long, but the
    > last component starts inside the last 8 bytes.
    > That seems to exonerate OCFS2 and autofs.
    > vmalloc of course does guard pages, and that creeps into percpu
    > data and other things. It's not the case here, but would it be worth
    > putting a check in to catch that, or is it just a totally insane thing
    > to pass vmalloc()/percpu_alloc()/etc name string?
    > Any other strange possible corner cases? If we put a string on stack,
    > do any architectures use vmalloc or anything strange for stacks?

    (I guess in practice stack hardly matters, because you're not going
    to get within 8 bytes of either end, unless stack overflow is imminent)

     \ /
      Last update: 2012-05-03 09:01    [W:0.044 / U:7.452 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site