Possible kqueue related issue on STABLE/RC.

[Patrick Lamaiziere]

Le Wed, 25 Sep 2013 11:06:33 +0300,
Konstantin Belousov <kostikbel at gmail.com> a écrit :

Hello,

> > > On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote:
> > > > I'd like to understand why you think protecting these functions
> > > > w/ the _DETACHED check is correct...  In kern_event.c, all
> > > > calls to f_detach are followed by knote_drop which will ensure
> > > > that the knote is removed and free, so no more f_event calls
> > > > will be called on that knote..
> > > 
> > > My current belief is that what happens is a glitch in the
> > > kqueue_register(). After a new knote is created and attached, the
> > > kq lock is dropped and then f_event() is called. If the vnode is
> > > reclaimed or possible freed meantime, f_event() seems to
> > > dereference freed memory, since kn_hook points to freed vnode.
> > > 
> > > The issue as I see it is that vnode lifecycle is detached from the
> > > knote lifecycle.  Might be, only the second patch, which acquires
> > > a hold reference on the vnode for each knote, is really needed.
> > > But before going into any conclusions, I want to see the testing
> > > results.
> > 
> > Testing looks good with your latest patch. I was able to run a
> > complete poudriere bulk (870 packages). I'm running another bulk to
> > see..

I've made another bulk without problem (with complete patch)

> > If you have other patches to test just ask, I have not updated my
> > packages because there was a change to make gvfsd to ignore some
> > poudriere activity. So I guess it will be harder to see this
> > problem.

> Could you, please, test with the only patch
> http://people.freebsd.org/~kib/misc/vnode_filter.1.patch
> applied ?  I wonder would it be enough.

Looks good with this single patch too, one poudriere bulk is
completed and I'm doing another just in case (but I think it would
have already paniced, that's quite reproductible).

Thanks, regards.