On Mon, Feb 27, 2012 at 09:23:24AM -0800, Dan Magenheimer wrote: > > From: Andrea Righi [mailto:andrea@xxxxxxxxxxxxxxx] > > Sent: Monday, February 20, 2012 5:12 AM > > To: Greg Kroah-Hartman > > Cc: Dan Magenheimer; Seth Jennings; devel@xxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > > stable@xxxxxxxxxx > > Subject: [PATCH] zcache: avoid AB-BA deadlock condition > > > > Commit 9256a47 fixed a deadlock condition, being sure that the buddy > > list spinlock is always taken before the page spinlock. > > > > However in zbud_free_and_delist() locking order is the opposite > > (page lock -> list lock). > > > > Possible unsafe locking scenario (reported by lockdep): > > > > CPU0 CPU1 > > ---- ---- > > lock(&(&zbpg->lock)->rlock); > > lock(zbud_budlists_spinlock); > > lock(&(&zbpg->lock)->rlock); > > lock(zbud_budlists_spinlock); > > > > Fix by grabbing the locks in opposite order in zbud_free_and_delist(). > > > > Signed-off-by: Andrea Righi <andrea@xxxxxxxxxxxxxxx> > > Acked-by: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> > > Thanks for catching this Andrea! (And thanks also to > Alex Vallacis-Lasso for independently reporting and testing: > http://permalink.gmane.org/gmane.linux.kernel/1257214 ) > > Greg, this patch could be targeted for 3.3-rc6 and 3.2-stable. > AFAIK, nobody has actually experienced a deadlock from this so > if Linus has the screws down tight for -rc6, it could wait > until the 3.4 window. If it helps, without the fix I can easily trigger the lockdep splat running a echo 3 > /proc/sys/vm/drop_caches. -Andrea _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
