Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 01 Sep 1998 22:07:51 +0000
From:      Mike Smith <mike@smith.net.au>
To:        Stefan Bethke <stb@hanse.de>
Cc:        net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG
Subject:   Re: Problems with MGET(m, M_WAIT, *) [was: Semantics of ...] 
Message-ID:  <199809012207.WAA00723@word.smith.net.au>
In-Reply-To: Your message of "Wed, 02 Sep 1998 00:36:28 %2B0200." <Pine.BSF.3.96.980901232001.28484I-100000@transit.hanse.de> 

next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 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.

This comment is significant in the context of a question you ask later.

> 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.

Yes.

> 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. 

How many of those that don't wait handle a NULL return correctly?  Any 
idea how many of them *might* be able to wait?

> 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.

I believe that Garrett is working on a replacement.  It's possible that 
it will be using the zone allocator, but I don't remember why I thought 
that.

> 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 I read the comment I referenced above correctly, it's describing how 
consumers should behave in order to work with the pending new allocator.

> 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.

Definitely fix them.  If you run into ones that might need more 
attention (ie. not an easy fix), then applying either a warning comment 
or a #warning diagnostic to them to flag the problems might actually be 
a very good idea.

Thanks for the analysis!
-- 
\\  Sometimes you're ahead,       \\  Mike Smith
\\  sometimes you're behind.      \\  mike@smith.net.au
\\  The race is long, and in the  \\  msmith@freebsd.org
\\  end it's only with yourself.  \\  msmith@cdrom.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



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