On Tue, Mar 03, 2009 at 02:49:45PM -0800, Matthew Fleming wrote: > I am trying to understand the knote system (on 6.1) and I am having some > troubles. > > Specifically, I am confused by the uses of KN_DETACHED and EV_ONESHOT. > >From what I can determine from the comments and code, knotes have a > filterops member, kn_fop. This among other things has a callback to > handle when a note is attached and detached. > > But e.g. in knlist_clear(), when knlist_remove_kq() removes a knote from > the list, it sets KN_DETACHED but does not call the kn_fop->f_detach > routine. Then, in the killkn case, KN_DETACHED is set (again). > Otherwise, EV_ONESHOT is set, presumably so that kqueue_scan() will run > on the knote. However, kqueue_scan() won't call kn_fop->f_detach either > because KN_DETACHED is already set. > > It seems that in knlist_cleardel(), the killkn case should be calling > kn_fop->f_detach before knote_drop(). It also seems that the !killkn > case should not have KN_DETACHED set, which means that > knlist_remove_kq() can't set it. Alternatively, knlist_remove_kq() > should be calling kn_fop->f_detach itself before setting KN_DETACHED. > But in that case I'm not sure I see why there needs to be a use of > EV_ONESHOT. > > So am I reading this wrong, understanding it wrong, or is there a bug in > the code?
There are two pathes to each knote, one from the kqueue(2) syscall, and another is from the kernel subsystem. My understanding is that f_detach handler is intended to be called from the syscall path only. For instance, pipe destructor sys_pipe.c:pipeclose() calls knlist_clear, i.e. knlist_cleardel with killkn == 0. The detach handler for the pipe removes the knote from the corresponding pipe' knlist. It seems that it is simply wrong to call pipe f_detach from knlist_clear().
pgphAjF1AO0sd.pgp
Description: PGP signature
