lkml.org 
[lkml]   [2012]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] kdump: force page alignment for per-CPU crash notes.
    On Thu, Mar 1, 2012 at 7:09 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
    > On Wed, Feb 29, 2012 at 09:21:23AM -0800, Eugene Surovegin wrote:
    >> Per-CPU allocations are not guaranteed to be physically contiguous.
    >> However, kdump kernel and user-space code assumes that per-CPU
    >> memory, used for saving CPU registers on crash, is.
    >> This can cause corrupted /proc/vmcore in some cases - the main
    >> symptom being huge ELF note section.
    >>
    >> Force page alignment for note_buf_t to ensure that this assumption holds.
    >>
    >
    > Hi Eugene,
    >
    > Where do we make assumption that crash_notes address is page aligned?

    I never said that. I said that assumption was that note chunks were
    physically contiguous.

    [snip]

    > Are you referring to the fact that note could be stored on two different
    > physical pages and then kexec-tools does not know about the physical
    > address of second page, hence second kernel does not know about it
    > and we never read that data. That sounds like a problem.

    Yes. This is exactly what happens in some cases.

    > So it make sense to force the page size alignment and if notes ever
    > grow beyond 1 page, we need to come up with more complex ways of
    > communicating more than 1 physical address to second kernel.

    Yes. Thankfully notes so far are smaller than a page.
    And if they do grow larger, than kexec-tools have to be modified
    anyways - currently maximum note size (1K) is hardcoded there.
    If this happens, I think instead of coming up with a way to
    communicate phys to virt mapping, it'd be easier just to change th way
    notes are allocated in the kernel so they are phys contiguous.

    --
    Eugene


    \
     
     \ /
      Last update: 2012-03-01 18:07    [W:2.410 / U:0.420 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site