cvs commit: src/sys/kern uipc_mbuf.c src/sys/sys mbuf.h
silby at silby.com
Thu Feb 24 20:02:51 GMT 2005
On Thu, 24 Feb 2005, Robert Watson wrote:
> On Fri, 28 Mar 2003, Mike Silbersack wrote:
>> Add the m_defrag routine, as discussed on committers at . This
>> incarnation should address the concerns of all in the discussion,
>> and keeps statistics which show how much it is used.
> I just started tracking a bug report from Peter Holm in which if_rl free's
> an already free'd mbuf, and tracked it back to the following problem: when
> you went through and adapted various drivers to use m_defrag(), two bugs
> were introduced:
I don't see any flaw in if_rl's use of m_defrag, please be more specific
as to what the error is.
> (1) Callers of m_defrag() did not properly handle the case where
> m_defrag() would return a new mbuf cluster as the head. Specifically,
> on encapsulation failure, they might requeue the old head in the ifnet
m_defrag ALWAYS returns a new mbuf cluster as the head!
> (2) Callers of m_defrag() did not properly handle the case where
> m_defrag() would return NULL due to mbuf exhaustion. Specifically, on
> encapsulation failure in the case where m_defrag() fails, they might
> attempt to enqueue a NULL mbuf pointer or a free'd mbuf pointer into
> the ifnet queue.
Sounds possible, we'll have to do a sweep for this. Alternately, we could
ask that people enable the MBUF_STRESS_TEST option and try running various
netperf tests with kern.ipc.m_defragrandomfailures=1 and with
net.inet.ip.mbuf_frag_size=-1 and -2. Those tests should be sufficient to
expose any bugs in m_defrag usage.
Mike "Silby" Silbersack
More information about the cvs-all