Date: Sun, 19 Jun 2011 12:44:03 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Mikolaj Golub <trociny@freebsd.org> Cc: freebsd-net@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org> Subject: Re: Scenario to make recv(MSG_WAITALL) stuck Message-ID: <20110619094403.GD48734@deviant.kiev.zoral.com.ua> In-Reply-To: <86k4cntwz2.fsf@in138.ua3> References: <86pqmhn1pf.fsf@kopusha.home.net> <20110614092303.GG48734@deviant.kiev.zoral.com.ua> <86k4cntwz2.fsf@in138.ua3>
next in thread | previous in thread | raw e-mail | index | archive | help
--FM5zcXyvfv2Qtj+b
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Jun 15, 2011 at 09:44:33AM +0300, Mikolaj Golub wrote:
>=20
> On Tue, 14 Jun 2011 12:23:03 +0300 Kostik Belousov wrote:
>=20
> KB> I do not understand what then happens for the recvfrom(2) call ?
> KB> Would it get some error, or 0 as return and no data, or something el=
se ?
>=20
> It will wait for data below in another loop ("Now continue to read any da=
ta
> mbufs off of the head...").
>=20
> Elaborating, I would split soreceive_generic on three logical parts.
>=20
> In the first (restart) part we block until some data are received and also
> (without the patch) in the case of MSG_WAITALL if the buffer is big enoug=
h we
> block until all MSG_WAITALL request is received (actually it will spin in
> "goto restart" loop until some condition becomes invalid).
>=20
> The second part is some processing of received data and the third part is=
a
> "while" loop where data is copied to userspace and in the case of MSG_WAI=
TALL
> request if not all data is received to satisfy the request it also waits =
for
> this data.
>=20
> My patch removes the condition in the first part in the case of MSG_WAITA=
LL to
> wait for all data if buffer is big enough. We always will wait for the re=
st of
> data in the third part. It might be not so effective, and this is my first
> concern about the patch (although not big :-).
Now I think that this part of the patch is right.
The loop in the soreceive_generic() would behave as I would expect
it for MSG_WAITALL. It copyout the received data to userspace by
received chunks.
I do not understand your note about effectiveness there.
>=20
> KB> Also, what is the MT_CONTROL chunk about ?
>=20
> When I removed the condition to skip blocking in the first part I started=
to
> observe panic on KASSERT(m->m_type =3D=3D MT_DATA) for the following scen=
ario
> (produced by HAST):
>=20
> sender:
>=20
> send(4 bytes); /* send protocol name */
> sendmsg(); /* send descriptor (normal data is empty, descriptor in co=
ntrol data) */
>=20
> receiver:
>=20
> recv(127 bytes, MSG_WAITALL); /* recive protocol name */
> recvmsg(); /* recive descriptor */
>=20
> Although the recv() has MSG_WAITALL, it exits after receiving 4 bytes bec=
ause
> the next received data is of different (MT_CONTROL) type. An it panicked =
when
> got control data.
>=20
> It is unclear for me why it is not expected to have MT_CONTROL data in th=
at
> part. We do have processing of MT_CONTROL above (in the second part) in t=
he
> code but I still a have feeling that it is possible to create some scenar=
io to
> break this assert without my patch too, but I have failed so far. And thi=
s is
> my second concern about my patch, big enough, because for now I am not su=
re
> that this is correct. Although I have not observed issues with it so far.=
..
I have no idea about this part.
>=20
> Also, I am not sure if there is sense to bother with soreceive_generic() =
at
> all. May be it is more perspective to spend time on "maturing"
> soreceive_stream(). As I see it is going to be a replacement for
> soreceive_generic() for stream sockets.
>=20
> --=20
> Mikolaj Golub
--FM5zcXyvfv2Qtj+b
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAk39xOMACgkQC3+MBN1Mb4iVbQCg5gbVdCW/Z4WjHOJbSbX+f0so
OiIAnRszcR5KuqTtAUilOouMCCtSTsd/
=y8y3
-----END PGP SIGNATURE-----
--FM5zcXyvfv2Qtj+b--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110619094403.GD48734>