Date: Wed, 2 Sep 1998 00:36:28 +0200 (CEST) From: Stefan Bethke <stb@hanse.de> To: net@FreeBSD.ORG Cc: freebsd-current@FreeBSD.ORG Subject: Re: Problems with MGET(m, M_WAIT, *) [was: Semantics of ...] Message-ID: <Pine.BSF.3.96.980901232001.28484I-100000@transit.hanse.de> In-Reply-To: <Pine.BSF.3.96.980825233251.25049C-100000@transit.hanse.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 25 Aug 1998, Stefan Bethke wrote:
> On Tue, 25 Aug 1998, Garrett Wollman wrote:
>
> > <<On Tue, 25 Aug 1998 21:25:12 +0200 (CEST), Stefan Bethke <stb@hanse.de>
> > said:
> >
> > > What are the expected semantics of MGET(m, M_WAIT, *)? I would suggest
> > > that by specifing M_WAIT, the caller wants to sleep until a mbuf becomes
> > > available, as it is already the case if the vm map must be extended.
> >
> > It should sleep, but actually doing so while avoiding deadlocks is
> > problematic. Since the mbuf allocator as currently formulated is
> > going away, callers to mget should expect that the allocation might
> > fail, but that M_WAIT makes it ``try harder'' as it were.
According to TCP Illustrated Vol II, p. 42:
Even though the caller specifies M_WAIT, ther return value must still be
checked, since [...] waiting for an mbuf does not guarantee that one
will be available.
Although our mbuf allocator is modified, it pretty much describes the
semantics.
I've tried to locate pieces of code in a recent -current that use M_WAIT,
but don't check for the return value. Interestingly enought, only 23
occurences of 160 total in the source use M_WAIT at all. For m_get(), its 22
to 110. Checking the 45 hits for pieces of code shows the following problem
areas:
For a total of 22 occurences, the return value isn't checked, in:
kern/uipc_socket:479 and :484, :1059 (including sosend())
netinet/ip_output.c:869, :884, :927, and :1345
netinet/raw_ip.c:285
netinet/tcp_usrreq.c:641
netkey/key.c:2199
nfs/krpc_subr.c:283 and :474
nfs/nfs_serv.c:517 and :685
nfs/nfs_socket.c:285 and :1188
nfs/nfs_subs.c:589, :684, :713, :746, :889, :921, :970, and :1063
In additional two occurences, I'm not sure, but I regard it as quite likely
that the function called will stumble over a NULL mbuf pointer, or a pointer
to it:
kern/uipc_socket.c:597
netinet/ip_mroute.c:425
So I have the following questions:
As Garrett said, the current mbuf allocator is going to go away. Is it? I
tried to find anything about it in the list archives, but to no avail.
Will the semantics of the new mbuf allocator be the same (M_WAIT may
return 0)? I guess so, but the one(s) working on the new allocator might
want to confirm that.
If so, should I start on trying to fix it, or will it be easy enougth to
fix these bugs when the new allocator is coming? At least some these
occurences seam to be fixable quite easily.
Thanks,
Stefan
--
Stefan Bethke
Muehlendamm 12 Phone: +49-40-256848, +49-177-3504009
D-22087 Hamburg <stefan.bethke@hanse.de>
Hamburg, Germany <stb@freebsd.org>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980901232001.28484I-100000>