svn commit: r300764 - head/sys/netinet

John Baldwin jhb at freebsd.org
Fri May 27 14:43:52 UTC 2016


On Friday, May 27, 2016 12:14:28 AM Bjoern A. Zeeb wrote:
> 
> > On 26 May 2016, at 18:35 , John Baldwin <jhb at FreeBSD.org> wrote:
> > 
> > Author: jhb
> > Date: Thu May 26 18:35:37 2016
> > New Revision: 300764
> > URL: https://svnweb.freebsd.org/changeset/base/300764
> > 
> > Log:
> >  Don't reuse the source mbuf in tcp_respond() if it is not writable.
> > 
> >  Not all mbufs passed up from device drivers are M_WRITABLE().  In
> >  particular, the Chelsio T4/T5 driver uses a feature called "buffer packing"
> >  to receive multiple frames in a single receive buffer.  The mbufs for
> >  these frames all share the same external storage so are treated as
> >  read-only by the rest of the stack when multiple frames are in flight.
> >  Previously tcp_respond() would blindly overwrite read-only mbufs when
> >  INVARIANTS was disabled or panic with an assertion failure if INVARIANTS
> >  was enabled.  Note that the new case is a bit of a mix of the two other
> >  cases in tcp_respond().  The TCP and IP headers must be copied explicitly
> >  into the new mbuf instead of being inherited (similar to the m == NULL
> >  case), but the addresses and ports must be swapped in the reply (similar
> >  to the m != NULL case).
> 
> Is the same true for ICMP(v6) replies?

Hmm, icmp_error() always allocates a new packet, but icmp_respond() does not.
There's no assertion to trip in that case. :-/

However, even if this change really isn't quite "perfect".  Specifically,
with "buffer packing" the multiple mbufs sharing a single backing buffer via
m_ext are all using non-overlapping regions of that buffer, and each mbuf does
have exclusive access to its portion of the buffer.  You just can't grow it.
So, if a reuse does not extend the buffer for these particular mbufs then it
is actually ok.  (So icmp_respond() is actually ok, and tcp_respond() is also
probably ok in practice.)  However, we don't have any way to distinguish this
use case from multiple mbufs sharing possibly-overlapping regions of a
buffer.

Fixing icmp_respond() is probably simpler as you can just m_dup() if the source
is not writable and then m_freem() the original and reuse the clone as 'm' for
the rest of the function.

-- 
John Baldwin


More information about the svn-src-head mailing list