Re: [PATCHv3 4/5] mm: make compound_head() robust
From: Michal Hocko <mhocko@kernel.org>
Date: 2015-08-27 15:09:21
Also in:
lkml
On Wed 26-08-15 14:29:16, Paul E. McKenney wrote:
On Wed, Aug 26, 2015 at 11:18:45AM -0700, Hugh Dickins wrote:
[...]
quoted
But if you do one day implement that, wouldn't sl?b.c have to use call_rcu_with_added_meaning() instead of call_rcu(), to be in danger of getting that bit set? (No rcu_head is placed in a PageTail page.)Good point, call_rcu_lazy(), but yes.quoted
So although it might be a little strange not to use a variant intended for freeing memory when indeed that's what it's doing, it would not be the end of the world for SLAB_DESTROY_BY_RCU to carry on using straight call_rcu(), in defence of the struct page safety Kirill is proposing.As long as you are OK with the bottom bit being zero throughout the RCU processing, yes.
I am really not sure I udnerstand. What will prevent
call_rcu(&page->rcu_head, free_page_rcu) done in a random driver?
Cannot the RCU simply claim bit1? I can see 1146edcbef37 ("rcu: Loosen
__call_rcu()'s rcu_head alignment constraint") but AFAIU all it would
take to fix this would be to require struct rcu_head to be aligned to
32b no?
Btw. Do we need the same think for page::mapping and KSM?
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>