From: Nick Piggin on 26 Jun 2010 04:40 On Fri, Jun 25, 2010 at 05:40:22PM -0400, Bob Peterson wrote: > On 2010-05-25 8:43:23, Nick Piggin wrote: > Hey Nick, > > I spotted what seems to be a regression in this patch. > The spin_lock was moved before the try loop: > > spin_lock(&vmap_area_lock); > retry: > > But later, after the overflow label, it can unlock the spin_lock and > loop back to retry without the spin_lock locked. See: > > overflow: > spin_unlock(&vmap_area_lock); > if (!purged) { > purge_vmap_area_lazy(); > purged = 1; > goto retry; > > If I'm not mistaken we should either put the spin_lock back below the > retry label or move the spin_unlock after the if (!purged) to prevent > accesses without the spin_lock held. > > Regards, > > Bob Peterson > Red Hat File Systems Hi Bob, Thanks for having a look. You are right, I think Minchan spotted this too and the version in Andrew Morton's tree should have that fixed. http://userweb.kernel.org/~akpm/mmotm/broken-out/mm-vmap-area-cache.patch Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: late Gigaset fixes for 2.6.35 Next: arch/tile: Miscellaneous cleanup changes. |