Thread (11 messages) flat view 11 messages, 4 authors, 2011-03-19

Re: [PATCH 2/4] slub,rcu: don't assume the size of struct rcu_head

From: Hugh Dickins <hughd@google.com>
Date: 2011-03-02 04:31:20
Also in: linux-mm, lkml

On Tue, Mar 1, 2011 at 7:11 AM, Christoph Lameter [off-list ref] wrote:
On Tue, 1 Mar 2011, Pekka Enberg wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help