kqueue oddity

[John-Mark Gurney]

Vclav Haisman wrote this message on Sat, Apr 01, 2006 at 20:35 +0200:
> 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 =  1, .filter = 0xfffffffe, .flags = 0x0001, 
> >>   .fflags = 0x00000000, .data = 0x000084c6}
> >>
> >> .ident == 1 is stdout.
> >> .filter == 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 == 0x0001 means EV_ADD which totally
> >> 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.
> > 
> > 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:
> >  
> > Index: kern_event.c
> > ===================================================================
> > 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 = 0;
> >  			kev->data = 0;
> >  			kn->kn_kevent = *kev;
> > +			kn->kn_kevent.flags &= ~EV_ADD; 
> >  			kn->kn_status = KN_INFLUX|KN_DETACHED;
> >  
> >  			error = knote_attach(kn, kq);
> > 
> > 
> Thanks. Why isn't this fix applied? From the patch's time stamp it seems
> like it is known for quite some time now.

Because I was never informed of the patch, so had no clue that it was
necessary... I'll commit a similar patch shortly...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

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