From owner-freebsd-net Tue Sep 1 15:51:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA10922 for freebsd-net-outgoing; Tue, 1 Sep 1998 15:51:12 -0700 (PDT) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from rrz.Hanse.DE (rrz.Hanse.DE [193.174.9.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA10905; Tue, 1 Sep 1998 15:50:59 -0700 (PDT) (envelope-from stb@hanse.de) Received: from daemon.Hanse.DE (daemon.Hanse.DE [193.174.9.17]) by rrz.Hanse.DE (8.8.8/8.8.8) with ESMTP id XAA14301; Tue, 1 Sep 1998 23:57:34 +0200 (CEST) (envelope-from stb@hanse.de) Received: from transit.hanse.de (transit.Hanse.DE [193.174.9.161]) by daemon.Hanse.DE (8.8.8/8.8.8) with ESMTP id AAA29423; Wed, 2 Sep 1998 00:51:10 +0200 (CEST) (envelope-from stb@hanse.de) Received: from localhost (stb@localhost) by transit.hanse.de (8.8.8/8.8.8) with SMTP id AAA03809; Wed, 2 Sep 1998 00:36:29 +0200 (CEST) X-Authentication-Warning: transit.hanse.de: stb owned process doing -bs Date: Wed, 2 Sep 1998 00:36:28 +0200 (CEST) From: Stefan Bethke Reply-To: Stefan Bethke To: net@FreeBSD.ORG cc: freebsd-current@FreeBSD.ORG Subject: Re: Problems with MGET(m, M_WAIT, *) [was: Semantics of ...] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 25 Aug 1998, Stefan Bethke wrote: > On Tue, 25 Aug 1998, Garrett Wollman wrote: > > > < > > 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 Hamburg, Germany To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message