Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 2 Feb 2017 08:29:20 +0000
From:      <Hartmut.Brandt@dlr.de>
To:        <glebius@FreeBSD.org>
Cc:        <src-committers@freebsd.org>, <svn-src-all@freebsd.org>, <svn-src-head@freebsd.org>
Subject:   RE: svn commit: r313043 - head/sys/kern
Message-ID:  <611243783F62AF48AFB07BC25FA4B1061CED9FD9@DLREXMBX01.intra.dlr.de>
In-Reply-To: <20170201180816.GF3334@FreeBSD.org>
References:  <201702011312.v11DC7WJ085025@repo.freebsd.org> <20170201180816.GF3334@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--_002_611243783F62AF48AFB07BC25FA4B1061CED9FD9DLREXMBX01intra_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

To be honest - I feared that when I saw your messages regarding this. Here =
is my original message from july. Attached is also a small test program.

Hi,

I'm trying to use asio (that's boost::asio without boost) to handle listeni=
ng sockets asynchronuosly. This appears not to work. There are also some re=
ports on the net about this problem. I was able to reproduce the problem wi=
th a small C-programm that does the same steps as asio. The relevant sequen=
ce of system calls is:

kqueue()					 =3D 3 (0x3)
socket(PF_INET,SOCK_STREAM,6)			 =3D 4 (0x4)
setsockopt(0x4,0xffff,0x800,0x7fffffffea2c,0x4)	 =3D 0 (0x0)
kevent(3,{ 4,EVFILT_READ,EV_ADD|EV_CLEAR,0x0,0x0,0x0 4,EVFILT_WRITE,EV_ADD|=
EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,0x0) =3D 0 (0x0)
setsockopt(0x4,0xffff,0x4,0x7fffffffea2c,0x4)	 =3D 0 (0x0)
bind(4,{ AF_INET 0.0.0.0:8080 },16)		 =3D 0 (0x0)
listen(0x4,0x80)				 =3D 0 (0x0)
ioctl(4,FIONBIO,0xffffea2c)			 =3D 0 (0x0)
kevent(3,{ 4,EVFILT_READ,EV_ADD|EV_CLEAR,0x0,0x0,0x0 4,EVFILT_WRITE,EV_ADD|=
EV_CLEAR,0x0,0x0,0x0 },2,0x0,0,0x0) =3D 0 (0x0)
kevent(3,0x0,0,0x7fffffffe5a0,32,0x0)		 ERR#4 'Interrupted system call'

The problem here is that asio registers each file descriptor with EVFILT_RE=
AD and EVFILT_WRITE as soon as it is opened (first kevent call).=20
After bringing the socket into the listening state and when async_accept() =
is called it registers the socket a second time. According to the man page =
this is perfectly legal and can be used to modify the registration.

With this sequence of calls kevent() does not return when a connection is e=
stablished successfully.

I tracked down the problem and the reason is in soo_kqfilter(). This is cal=
led for the first EVFILT_READ registration and decides based on the SO_ACCE=
PTCONN flag which filter operations to use solisten_filtops or soread_filto=
ps. In this case it chooses soread_filtops.

The second EVFILT_READ registration does not call soo_kqfilter() again, but=
 just updates the filter from the data and fflags field so the listening so=
cket ends up with the wrong filter operations.



-----Original Message-----
From: Gleb Smirnoff [mailto:glebius@FreeBSD.org]=20
Sent: Wednesday, February 01, 2017 7:08 PM
To: Hartmut Brandt
Cc: src-committers@freebsd.org; svn-src-all@freebsd.org; svn-src-head@freeb=
sd.org
Subject: Re: svn commit: r313043 - head/sys/kern

On Wed, Feb 01, 2017 at 01:12:07PM +0000, Hartmut Brandt wrote:
H> Author: harti
H> Date: Wed Feb  1 13:12:07 2017
H> New Revision: 313043
H> URL: https://svnweb.freebsd.org/changeset/base/313043
H>=20
H> Log:
H>   Merge filt_soread and filt_solisten and decide what to do when checkin=
g
H>   for EVFILT_READ at the point of the check not when the event is regist=
ers.
H>   This fixes a problem with asio when accepting a connection.
H>  =20
H>   Reviewed by:	kib@, Scott Mitchell

This goes into opposite direction with what I am doing:

https://reviews.freebsd.org/D9356

Can you please explain the problem with asio when accepting a connection?

--=20
Totus tuus, Glebius.


--_002_611243783F62AF48AFB07BC25FA4B1061CED9FD9DLREXMBX01intra_
Content-Type: text/plain; name="k.c"
Content-Description: k.c
Content-Disposition: attachment; filename="k.c"; size=1459;
	creation-date="Thu, 02 Feb 2017 07:47:39 GMT";
	modification-date="Thu, 02 Feb 2017 07:47:39 GMT"
Content-Transfer-Encoding: base64

I2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4NCiNpbmNsdWRlIDxzeXMvdHlwZXMuaD4NCiNpbmNsdWRl
IDxzeXMvZXZlbnQuaD4NCiNpbmNsdWRlIDxzeXMvZmlsaW8uaD4NCg0KI2luY2x1ZGUgPHN5cy9p
b2N0bC5oPg0KI2luY2x1ZGUgPG5ldGluZXQvaW4uaD4NCiNpbmNsdWRlIDxzdGRpby5oPg0KI2lu
Y2x1ZGUgPHN0cmluZy5oPg0KI2luY2x1ZGUgPGVyci5oPg0KDQpzdGF0aWMgdm9pZA0Kd2FpdF9s
b29wKGludCBrcSwgaW50IHNvY2spDQp7DQoJc3RydWN0IGtldmVudCBldlszMl07DQoJc3RydWN0
IHNvY2thZGRyX2luIGFkZHI7DQoJc29ja2xlbl90IHNvY2tsZW47DQoNCglmb3IgKDs7KSB7DQoJ
CWludCBuZXYgPSBrZXZlbnQoa3EsIE5VTEwsIDAsIGV2LCAzMiwgTlVMTCk7DQoJCWlmIChuZXYg
PCAxKQ0KCQkJZXJyKDEsICJrZXZlbnQiKTsNCgkJZm9yIChpbnQgaSA9IDA7IGkgPCBuZXY7ICsr
aSkgew0KCQkJaWYgKGV2W2ldLmlkZW50ID09IHNvY2spIHsNCgkJCQlwcmludGYoImFjY2VwdFxu
Iik7DQoJCQkJaW50IGZkID0gYWNjZXB0KGV2W2ldLmlkZW50LA0KCQkJCSAgICAoc3RydWN0IHNv
Y2thZGRyICopJmFkZHIsICZzb2NrbGVuKTsNCgkJCQlpZiAoZmQgPT0gLTEpDQoJCQkJCWVycigx
LCAiYWNjZXB0Iik7DQoJCQl9DQoJCX0NCgl9DQp9DQoNCmludA0KbWFpbigpDQp7DQoJc3RydWN0
IHNvY2thZGRyX2luIGFkZHI7DQoNCgkvKiBvcGVuIGEgVENQIHNvY2tldCAqLw0KCWludCBrcSA9
IGtxdWV1ZSgpOw0KDQoJaW50IHNvY2sgPSBzb2NrZXQoUEZfSU5FVCwgU09DS19TVFJFQU0sIDAp
Ow0KDQoJc3RydWN0IGtldmVudCBldlsyXTsNCglFVl9TRVQoJmV2WzBdLCBzb2NrLCBFVkZJTFRf
UkVBRCwgRVZfQUREIHwgRVZfQ0xFQVIsIDAsIDAsIE5VTEwpOw0KCUVWX1NFVCgmZXZbMV0sIHNv
Y2ssIEVWRklMVF9XUklURSwgRVZfQUREIHwgRVZfQ0xFQVIsIDAsIDAsIE5VTEwpOw0KDQoJaW50
IG9wdCA9IDE7DQoJc2V0c29ja29wdChzb2NrLCBTT0xfU09DS0VULCBTT19OT1NJR1BJUEUsICZv
cHQsIHNpemVvZihvcHQpKTsNCg0KCWlmIChrZXZlbnQoa3EsIGV2LCAyLCBOVUxMLCAwLCBOVUxM
KSA9PSAtMSkNCgkgICAgZXJyKDEsICJrZXZlbnQiKTsNCg0KCXNldHNvY2tvcHQoc29jaywgU09M
X1NPQ0tFVCwgU09fUkVVU0VBRERSLCAmb3B0LCBzaXplb2Yob3B0KSk7DQoNCgltZW1zZXQoJmFk
ZHIsIDAsIHNpemVvZihhZGRyKSk7DQoJYWRkci5zaW5fcG9ydCA9IGh0b25zKDEwMDAwKTsNCg0K
CWJpbmQoc29jaywgKHN0cnVjdCBzb2NrYWRkciAqKSZhZGRyLCBzaXplb2YoYWRkcikpOw0KCWxp
c3Rlbihzb2NrLCAweDgwKTsNCg0KCWlvY3RsKHNvY2ssIEZJT05CSU8sICZvcHQpOw0KDQoJaWYg
KGtldmVudChrcSwgZXYsIDIsIE5VTEwsIDAsIE5VTEwpID09IC0xKQ0KCQllcnIoMSwgImtldmVu
dCIpOw0KDQoJd2FpdF9sb29wKGtxLCBzb2NrKTsNCn0NCg==

--_002_611243783F62AF48AFB07BC25FA4B1061CED9FD9DLREXMBX01intra_--



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