[lkml]   [2009]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Patch BUGFIX] kcore: fix its wrong size on x86_64
    Amerigo Wang <> writes:

    > Fix wrong /proc/kcore size on x86_64.
    > x86_64 uses __va() macro to caculate the virtual address passed to kclist_add()
    > but decodes it with its own macro kc_vadd_to_offset(). This is wrong.

    Ok. I finally understand what is going on here, and no kc_vaddr_to_offset
    is not wrong when applied to a virtual address. In fact I expect the current
    definition makes things a bit more predictable.

    And yes kclist_add is must be given a virtual address

    > Also, according to Documentation/x86/x86_64/mm.txt, kc_vaddr_to_offset()
    > is wrong too.

    How so? The file offset is a number space that is different from both
    physical and virtual addresses.

    > So just remove them, use the generic macro.

    I think a case can be made either way. In practice neither answer
    gives us a dense offset space on x86_64 so I think I prefer the
    current definition which sets or clears the high bits as opposed
    to something that mangles the address more.

    > BTW, the man page for /proc/kcore is wrong, its size can be more than
    > the physical memory size, because it also contains memory area of
    > vmalloc(), vsyscall etc...

    Yes, the man page is wrong. The kcore code is also misleading as it
    uses two entirely different definitions of size (aka the maximum
    offset accepted).

    It uses get_kcore_size and (size_t)high_memory - PAGE_OFFSET + PAGE_SIZE;
    The second definition being bogus as it has nothing to do with which
    offsets are accepted.


     \ /
      Last update: 2009-06-15 12:11    [W:0.026 / U:4.752 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site