lkml.org 
[lkml]   [2011]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 2/4] slub,rcu: don't assume the size of struct rcu_head
    From
    On Tue, Mar 1, 2011 at 7:11 AM, Christoph Lameter <cl@linux.com> wrote:
    > On Tue, 1 Mar 2011, Pekka Enberg wrote:
    >
    > > The SLAB and SLUB patches are fine by me if there are going to be real
    > > users for this. Christoph, Paul?
    >
    > The solution is a bit overkill. It would be much simpler to add a union to
    > struct page that has lru and the rcu in there similar things can be done
    > for SLAB and the network layer. A similar issue already exists for the
    > spinlock in struct page. Lets follow the existing way of handling this.
    >
    > Struct page may be larger for debugging purposes already because of the
    > need for extended spinlock data.

    That was so for a long time, but I stopped it just over a year ago
    with commit a70caa8ba48f21f46d3b4e71b6b8d14080bbd57a, stop ptlock
    enlarging struct page.

    Partly out of shame at how large struct page was growing when lockdep
    is on, but also a subtle KSM reason which might apply here too: KSM
    relies on the content of page->mapping to be kernel pointer to a
    relevant structure, NULLed when the page is freed.

    If a union leads to "random junk" overwriting the page->mapping field
    when the page is reused, and that junk could resemble the pointer in
    question, then KSM would mistakenly think it still owned the page.
    Very remote chance, and maybe it amounts to no more than a leak. But
    I'd still prefer we keep page->mapping for pointers (sometimes with
    lower bits set as flags).

    Hugh


    \
     
     \ /
      Last update: 2011-03-02 05:33    [W:0.022 / U:0.748 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site