From owner-freebsd-current Tue Aug 25 12:26:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA19733 for freebsd-current-outgoing; Tue, 25 Aug 1998 12:26:26 -0700 (PDT) (envelope-from owner-freebsd-current@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 MAA19703 for ; Tue, 25 Aug 1998 12:26:17 -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 UAA26647 for ; Tue, 25 Aug 1998 20:32:59 +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 VAA22232 for ; Tue, 25 Aug 1998 21:26:25 +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 VAA27410 for ; Tue, 25 Aug 1998 21:25:13 +0200 (CEST) X-Authentication-Warning: transit.hanse.de: stb owned process doing -bs Date: Tue, 25 Aug 1998 21:25:12 +0200 (CEST) From: Stefan Bethke To: freebsd-current@FreeBSD.ORG Subject: Semantics of MGET(m, M_WAIT, *)? [was: Huge Bug not fixed?] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 14 Aug 1998, Stefan Bethke wrote: > > Looking at kern/uipc_socket.c:sosend(), one can easily spot the problem > > > Because sosend() expects a MGET(m, M_WAIT, MT_DATA) to always succeed, it > > pagefaults while trying to manipulate the non-allocated mbuf > > (m->m_pkthdr.len at 0+0x18). > > > The solution would be either to make MGET() and MGETHRD() to always succeed > > (or sleep indefinitly), or check the result of any of those calls (as many > > callers already do). 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. Alternatively, all callers must check whether they actually obtained a mbuf; for so_send(), this is definitly beyond my grasp. While the problem in so_send() seems to strike only under rare circumstances, I fell we should fix the problem nonetheless (instead of putting panic()s into m_retry). 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-current" in the body of the message