Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 04 Apr 2014 07:55:05 +0900 (JST)
From:      Kohji Okuno <okuno.kohji@jp.panasonic.com>
To:        kostikbel@gmail.com
Cc:        freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com
Subject:   Re: kevent has bug?
Message-ID:  <20140404.075505.349505214846463043.okuno.kohji@jp.panasonic.com>
In-Reply-To: <20140403134814.GT21331@kib.kiev.ua>
References:  <20140402174400.GR21331@kib.kiev.ua> <20140403.182656.1696050559410663288.okuno.kohji@jp.panasonic.com> <20140403134814.GT21331@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
From: Konstantin Belousov <kostikbel@gmail.com>
Date: Thu, 3 Apr 2014 16:48:14 +0300
> On Thu, Apr 03, 2014 at 06:26:56PM +0900, Kohji Okuno wrote:
>> > The done_ev_add case is indeed missed in my patch, thank you for noting.
>> > The case of EV_ADD does not need the KN_SCAN workaround, IMO, since the
>> > race is possible just by the nature of adding the knote.
> 
>> I think, we should add KN_SCAN after knote_attach() in
>> kqueue_register(), too. What do you think about this?
> See above, I noted this case in the previous mail.  This may be elaborated.
> 
> First, I think it is technically incorrect to allow the event
> notification before the f_attach() method is finished. So the KN_SCAN
> flag could be set only after f_attach() call, but due to both kq and
> knlist not locked there, we still have the same race. And this race is
> in fact acceptable, since it is the race between application calling
> EV_ADD, and external event occuring, which cannot be avoided. Until the
> kevent(EV_ADD) syscall returned, we do not have an obligation to report
> the event from the kqfd. Having the race somewhat bigger by not setting
> KN_SCAN is fine in my opinion.

Hi,

Thank you for your detailed commnet. And I uderstood about your opinion.
By the way, do you commit your change to HEAD?

Regards,
 Kohji Okuno



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140404.075505.349505214846463043.okuno.kohji>