I'm trying to plug some of the holes not checking for mbuf shortage.
In particular, there are the following unchecked calls to MGET and
friends in /sys/kern/uipc_socket.c:sosend() (see patches below).
Would anyone mind if I commit these? I won't be able to commit
these before next Sunday evening, so if anyone deems these to be
useful, he's welcome to commit before then.
Another big problem is that there's a check in m_retry and friends
that panics when falling short of mbufs! I really believe this does
more harm than good, because it prevents correct calling code
(checking for NULL mbuf pointers) from exiting gracefully with
ENOBUFS...
These could most certainly help with 3.2-RELEASE too. Same problem,
I won't be able to do anything more before Sunday.
--- uipc_socket.c.orig Wed May 5 16:48:57 1999
+++ uipc_socket.c Wed May 12 16:55:27 1999
@@ -497,15 +497,27 @@
} else do {
if (top == 0) {
MGETHDR(m, M_WAIT, MT_DATA);
+ if (m == 0) {
+ error = ENOBUFS;
+ goto release;
+ }
mlen = MHLEN;
m->m_pkthdr.len = 0;
m->m_pkthdr.rcvif = (struct ifnet *)0;
} else {
MGET(m, M_WAIT, MT_DATA);
+ if (m == 0) {
+ error = ENOBUFS;
+ goto release;
+ }
mlen = MLEN;
}
if (resid >= MINCLSIZE) {
MCLGET(m, M_WAIT);
+ if (m == 0) {
+ error = ENOBUFS;
+ goto release;
+ }
if ((m->m_flags & M_EXT) == 0)
goto nopages;
mlen = MCLBYTES;
@@ -617,6 +629,8 @@
flags = 0;
if (flags & MSG_OOB) {
m = m_get(M_WAIT, MT_DATA);
+ if (m == 0)
+ return (ENOBUFS);
error = (*pr->pr_usrreqs->pru_rcvoob)(so, m, flags & MSG_PEEK);
if (error)
goto bad;
--- uipc_mbuf.c.orig Fri Apr 30 12:33:50 1999
+++ uipc_mbuf.c Wed May 12 17:05:02 1999
@@ -263,10 +263,7 @@
if (m != NULL) {
mbstat.m_wait++;
} else {
- if (i == M_DONTWAIT)
- mbstat.m_drops++;
- else
- panic("Out of mbuf clusters");
+ mbstat.m_drops++;
}
return (m);
}
@@ -291,10 +288,7 @@
if (m != NULL) {
mbstat.m_wait++;
} else {
- if (i == M_DONTWAIT)
- mbstat.m_drops++;
- else
- panic("Out of mbuf clusters");
+ mbstat.m_drops++;
}
return (m);
}
--
Pierre Beyssac p...@enst.fr
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
