Re: [PATCH] make idr_remove_all() do removal -before- free_layer()

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Sun, Mar 08, 2009 at 04:33:36PM +0100, Ingo Molnar wrote:
> 
> * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> 
> > The following patch fixes a problem in the IDR system, where 
> > an idr_remove_all() hands a data element to call_rcu() (via 
> > free_layer()) before making that data element inaccessible to 
> > new readers.  This is very bad, and results in readers still 
> > having a reference to this data element at the end of the 
> > grace period.  Tests on large machines that concurrently map 
> > and unmap user-space memory within the same multithreaded 
> > process result in crashes within about five minutes.  Applying 
> > this patch increases the kernel's longevity to the 
> > three-to-eight-hour range.
> > 
> > There appear to be other similar problems in 
> > idr_get_empty_slot() and sub_remove(), but I fixed the easy 
> > one in idr_remove_all() first.  It is therefore no surprise 
> > that failures still occur.
> > 
> > (Yes, and I did look at the relevant patch last year without 
> > spotting this one.  Goes to show the value of testing as well 
> > as code review, I guess...)
> > 
> > Nadia, Manfred, any thoughts?
> > 
> > Located-by: Milton Miller II <miltonm@austin.ibm.com>
> > Tested-by: Milton Miller II <miltonm@austin.ibm.com>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> 
> Hm, looks like something we really want to see fixed in 
> 2.6.29-final, right?

This was located in real testing, so I agree that it is pretty high
priority.  So this patch should go into 2.6.29.

The priority of the remaining yet-as-unknown fixes depends on their
complexity and risk.

							Thanx, Paul