linux-kernel - Re: [PATCH] make idr_remove_all() do removal -before- free

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20090308192024.GQ10625@linux.vnet.ibm.com>
Date:	Sun, 8 Mar 2009 12:20:24 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org, manfred@...orfullife.com,
	Nadia.Derbey@...l.net, miltonm@...tin.ibm.com,
	akpm@...ux-foundation.org, peterz@...radead.org,
	lnxninja@...ux.vnet.ibm.com, efault@....de, riel@...hat.com
Subject: Re: [PATCH] make idr_remove_all() do removal -before- free_layer()

On Sun, Mar 08, 2009 at 04:33:36PM +0100, Ingo Molnar wrote:
> 
> * Paul E. McKenney <paulmck@...ux.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@...tin.ibm.com>
> > Tested-by: Milton Miller II <miltonm@...tin.ibm.com>
> > Signed-off-by: Paul E. McKenney <paulmck@...ux.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/