On Sat, Nov 10, 2012 at 05:33:47PM +0100, J. Hannken-Illjes wrote: > On Nov 10, 2012, at 12:20 PM, Manuel Bouyer <bou...@antioche.eu.org> wrote: > > > On Thu, Nov 08, 2012 at 12:45:55PM +0100, J. Hannken-Illjes wrote: > >> To make it short, Manuels fix was right, me removing it and trying to get > >> it > >> done in vn_lock() is wrong. > >> > >> While vget() vs. cleanvnode() (the cleaner) was always free of races, > >> vget() vs. vrelel() is not. Manuels fix checking the vnode state when > >> vrelel() > >> got its vnode lock and before it starts inactivating and cleaning is right. > >> > >> Please try the attached diff that brings back the fix. > > > > I'm not sure how this would fix it. Although there may also be a race > > bwteen vget() and vrelel(), the race I described is really between > > vget() and cleanvnode() here (more specifically, vget() and vclean(), which > > is > > used by both cleanvnode() and vrelel()). I can't see how your patch would > > fix > > this one. > > I still don't get it. If vget() gets preempted after releasing the nodes > interlock this node has already been removed from the freelist so cleanvnode() > cannot take and clean it.
Looks like you're right. the thread which did clean the vnode in the back of vget was probably another one ... -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --