Date: Tue, 25 Aug 1998 21:25:12 +0200 (CEST) From: Stefan Bethke <stb@hanse.de> To: freebsd-current@FreeBSD.ORG Subject: Semantics of MGET(m, M_WAIT, *)? [was: Huge Bug not fixed?] Message-ID: <Pine.BSF.3.96.980825211818.25049A-100000@transit.hanse.de> In-Reply-To: <Pine.BSF.3.96.980814023617.9883A-300000@transit.hanse.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <stefan.bethke@hanse.de> Hamburg, Germany <stb@freebsd.org> 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?Pine.BSF.3.96.980825211818.25049A-100000>