Re: [patch 1/6] mmu_notifier: Core code

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Christoph Lameter <clameter@...>
Cc: Andrea Arcangeli <andrea@...>, Robin Holt <holt@...>, Avi Kivity <avi@...>, Izik Eidus <izike@...>, Nick Piggin <npiggin@...>, <kvm-devel@...>, Benjamin Herrenschmidt <benh@...>, Peter Zijlstra <a.p.zijlstra@...>, <steiner@...>, <linux-kernel@...>, <linux-mm@...>, <daniel.blueman@...>, Hugh Dickins <hugh@...>
Date: Tuesday, February 5, 2008 - 2:05 pm

On Mon, Jan 28, 2008 at 12:28:41PM -0800, Christoph Lameter wrote:

Does this ->release actually release the 'nm' and its associated hlist?
I see in this thread that this ordering is deemed "use after free" which
implies so.

If it does that seems wrong.  This is an RCU hlist, therefore the list
integrity must be maintained through the next grace period in case there
are parallell readers using the element, in particular its forward
pointer for traversal.


For this to be updating the list, you must have some form of "write-side"
exclusion as these primatives are not "parallel write safe".  It would
be helpful for this routine to state what that write side exclusion is.


I am not sure it makes sense to add a _safe_rcu variant.  As I understand
things an _safe variant is used where we are going to remove the current
list element in the middle of a list walk.  However the key feature of an
RCU data structure is that it will always be in a "safe" state until any
parallel readers have completed.  For an hlist this means that the removed
entry and its forward link must remain valid for as long as there may be
a parallel reader traversing this list, ie. until the next grace period.
If this link is valid for the parallel reader, then it must be valid for
us, and if so it feels that hlist_for_each_entry_rcu should be sufficient
to cope in the face of entries being unlinked as we traverse the list.

-apw
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[patch 1/6] mmu_notifier: Core code, Christoph Lameter, (Mon Jan 28, 4:28 pm)
Re: [patch 1/6] mmu_notifier: Core code, Andy Whitcroft, (Tue Feb 5, 2:05 pm)
Re: [patch 1/6] mmu_notifier: Core code, Christoph Lameter, (Tue Feb 5, 2:19 pm)
Re: [patch 1/6] mmu_notifier: Core code, Peter Zijlstra, (Tue Feb 5, 2:17 pm)
Re: [patch 1/6] mmu_notifier: Core code, Robin Holt, (Tue Jan 29, 12:07 pm)
Re: [patch 1/6] mmu_notifier: Core code, Andrea Arcangeli, (Tue Jan 29, 9:59 am)
Re: [patch 1/6] mmu_notifier: Core code, Christoph Lameter, (Tue Jan 29, 3:49 pm)
Re: [patch 1/6] mmu_notifier: Core code, Avi Kivity, (Tue Jan 29, 4:41 pm)
Re: [patch 1/6] mmu_notifier: Core code, Andrea Arcangeli, (Tue Jan 29, 10:34 am)
Re: [patch 1/6] mmu_notifier: Core code, Robin Holt, (Mon Jan 28, 8:05 pm)
Re: [patch 1/6] mmu_notifier: Core code, Christoph Lameter, (Mon Jan 28, 9:19 pm)
Re: [patch 1/6] mmu_notifier: Core code, Christoph Lameter, (Mon Jan 28, 6:06 pm)