From owner-freebsd-current Tue Sep 1 22:11:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA10263 for freebsd-current-outgoing; Tue, 1 Sep 1998 22:11:10 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from word.smith.net.au (castles304.castles.com [208.214.167.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA10202; Tue, 1 Sep 1998 22:11:01 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost [127.0.0.1]) by word.smith.net.au (8.9.1/8.8.8) with ESMTP id WAA00723; Tue, 1 Sep 1998 22:07:52 GMT (envelope-from mike@word.smith.net.au) Message-Id: <199809012207.WAA00723@word.smith.net.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Stefan Bethke cc: net@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Problems with MGET(m, M_WAIT, *) [was: Semantics of ...] In-reply-to: Your message of "Wed, 02 Sep 1998 00:36:28 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Sep 1998 22:07:51 +0000 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > 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