On 08/26/2015 05:04 PM, Kirill A. Shutemov wrote:
That's
bad news then. It's not that we would trigger that bit when the rcu_head part of
the union is "active". It's that pfn scanners could inspect such page at
arbitrary time, see the bit 0 set (due to RCU processing) and think that it's a
tail page of a compound page, and interpret the rest of the pointer as a pointer
to the head page (to test it for flags etc).
On the other hand, if you avoid scanning rcu_head structures for pages
that are currently waiting for a grace period, no problem. RCU does
not use the rcu_head structure at all except for during the time between
when call_rcu() is invoked on that rcu_head structure and the time that
the callback is invoked.
Is there some other page state that indicates that the page is waiting
for a grace period? If so, you could simply avoid testing that bit in
that case.
No, I don't think so.
For compound pages most of info of its state is stored in head page (e.g.
page_count(), flags, etc). So if we examine random page (pfn scanner case)
the very first thing we want to know if we stepped on tail page.
PageTail() is what I wanted to encode in the bit...
What if we change order of fields within rcu_head and put ->func first?
Or change the order of compound_head wrt the rest?
Can we expect this pointer to have bit 0 always clear?
That's probably a question whether $compiler is guaranteed to align
functions on all architectures...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>