Date: Wed, 4 Mar 2009 14:35:24 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Matthew Fleming <matthew.fleming@isilon.com> Cc: freebsd-hackers@freebsd.org Subject: Re: knotes Message-ID: <20090304123524.GQ41617@deviant.kiev.zoral.com.ua> In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E0275F4E1@seaxch09.desktop.isilon.com> References: <06D5F9F6F655AD4C92E28B662F7F853E0275F4E1@seaxch09.desktop.isilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--7Zo7F9byXsDd4al8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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 =3D=3D 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(). --7Zo7F9byXsDd4al8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmudYsACgkQC3+MBN1Mb4hWlgCeKTI3BuN/Tn6n/EQNMzTYLRBh F/cAnA75cfsInrXNvFCpGLLkDGQRrF/C =igUn -----END PGP SIGNATURE----- --7Zo7F9byXsDd4al8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090304123524.GQ41617>