Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 01 Apr 2006 20:35:35 +0200
From:      =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= <V.Haisman@sh.cvut.cz>
To:        Dan Nelson <dnelson@allantgroup.com>
Cc:        hackers@freebsd.org
Subject:   Re: kqueue oddity
Message-ID:  <442EC7F7.3000608@sh.cvut.cz>
In-Reply-To: <20060401180311.GA83967@dan.emsphone.com>
References:  <442E9354.5010700@sh.cvut.cz> <20060401180311.GA83967@dan.emsphone.com>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig42E91DB545B863081B0E1FE1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Dan Nelson wrote:
> In the last episode (Apr 01), Vclav Haisman said:
>> Hi,
>> I have a little problem with kqueue/kevent. I am getting somewhat
>> strange events from kevent(). The struct kevent's contents looks like =
this:
>>
>> kevent {.ident =3D  1, .filter =3D 0xfffffffe, .flags =3D 0x0001,=20
>>   .fflags =3D 0x00000000, .data =3D 0x000084c6}
>>
>> .ident =3D=3D 1 is stdout.
>> .filter =3D=3D 0x fffffffe is -2 is EVFILT_WRITE which makes sense for=
 stdout.
>> .fflags is empty, nothing out of ordinary for EVFILT_WRITE.
>> And here comes the oddity: .flags =3D=3D 0x0001 means EV_ADD which tot=
ally
>> doesn't make sense to me and neither does according to man kqueue. The=

>> code that exhibits this behaviour is io_loop_handler_run() in
>> ioloop-kqueue.c of Dovecot IMAP server.
>=20
> It's a kqueue bug, but a minor one.  The problem is that the same
> "flags" field is used to pass "actions" from the client, and return
> status from the kernel.  When you call kqueue with EV_ADD, the kernel
> never clears the flags when creating the internal object, so it's
> always visible when events fire.  This can get annoying when trussing
> kqueue-using programs because very single event has the EV_ADD flag :)
> Apply the following diff to have the kernel strip EV_ADD:
> =20
> Index: kern_event.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /home/ncvs/src/sys/kern/kern_event.c,v
> retrieving revision 1.79.2.9
> diff -u -p -r1.79.2.9 kern_event.c
> --- kern_event.c	29 Jun 2005 18:08:31 -0000	1.79.2.9
> +++ kern_event.c	7 Jul 2005 18:51:29 -0000
> @@ -864,6 +864,7 @@ findkn:
>  			kev->fflags =3D 0;
>  			kev->data =3D 0;
>  			kn->kn_kevent =3D *kev;
> +			kn->kn_kevent.flags &=3D ~EV_ADD;=20
>  			kn->kn_status =3D KN_INFLUX|KN_DETACHED;
> =20
>  			error =3D knote_attach(kn, kq);
>=20
>=20
Thanks. Why isn't this fix applied? From the patch's time stamp it seems
like it is known for quite some time now.


Vaclav Haisman


--------------enig42E91DB545B863081B0E1FE1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEVAwUBRC7H/m56zbtzMDG0AQLoUggAhwf/2GwWw5sU/icVfYzbJdioeAqqlhPj
Wmlu11C0ooYi2+bdPxdgTqEZcvVEmT5H9WLnWpQgySY7zv7eCt4KilbD9XwjIc6R
LIZeYB3eq8b4dw8EttxiuFDNqR1O8OqOVJyfLEzwTHLf27+dOEB9mhjbaePzeEvR
643fGTjY84IDjPGF/doQ4nsYW9qfoGTRwkegHqeKZPWdpM/dmpZaOAD8s+vwWyxB
n3dxQHeREnbF7TnWtUom7QKrclP9fsiq7IJIzdhg6km/ydHotMT3ZeKuJ0xRgnMc
K1ORJVSnwCU/MaEOZzo52dBV5FRt48MhXt4csUWLbDbb1kMK2Q+pug==
=9Poo
-----END PGP SIGNATURE-----

--------------enig42E91DB545B863081B0E1FE1--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?442EC7F7.3000608>