Possible kqueue related issue on STABLE/RC.

John-Mark Gurney jmg at funkthat.com
Wed Sep 25 16:19:59 UTC 2013

Konstantin Belousov wrote this message on Wed, Sep 25, 2013 at 00:21 +0300:
> 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.

Well, if that happens, then the vnode isn't properly clearing up the
knote before it gets reclaimed...  It is the vnode's responsibility to
make sure any knotes that are associated w/ it get cleaned up properly..

> 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.

The vnode lifecycle can't/shouldn't be detached from the knote lifecycle
since the knote contains a pointer to the vnode...  There is the function
knlist_clear that can be used to clean up knotes when the object goes

I was looking at the code, is there a good reason why you do
VI_LOCK/VI_UNLOCK to protect the knote fields instead of getting it in
the vfs_knllock/vfs_knlunlock functions?  Because kq code will modify
the knote fields w/ only running the vfs_knllock/vfs_knlunlock functions,
so either the VI_LOCK/VI_UNLOCK are unnecessary, or should be moved to

  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

More information about the freebsd-stable mailing list