> On Mon, Nov 25, 2002 at 10:46:00AM -0800, Sam Leffler wrote: > > > > I don't see this problem; looutput looks to do the right thing. FWIW > > I've > > > > passed mbufs w/ mtags through the loopback interface. > > > > > > This refers specifically to the following code snippet: > > > > > > if (m && m->m_next != NULL && m->m_pkthdr.len < MCLBYTES) { > > > struct mbuf *n; > > > > > > MGETHDR(n, M_DONTWAIT, MT_HEADER); > > > if (!n) > > > goto contiguousfail; > > > MCLGET(n, M_DONTWAIT); > > > if (! (n->m_flags & M_EXT)) { > > > m_freem(n); > > > goto contiguousfail; > > > } > > > > > > m_copydata(m, 0, m->m_pkthdr.len, mtod(n, caddr_t)); > > > n->m_pkthdr = m->m_pkthdr; > > > n->m_len = m->m_pkthdr.len; > > > n->m_pkthdr.aux = m->m_pkthdr.aux; > > > m->m_pkthdr.aux = (struct mbuf *)NULL; > > > m_freem(m); > > > m = n; > > > } > > > > > > > Something is wrong with your tree: > > > > ebb% grep aux ../sys/mbuf.h > > ebb% > > > > The above code is correct in the repo as is the m_getcl code. > > While the 'aux' part of the code was in fact removed, what Robert is > saying still applies. What happens is that this code 'manually' > performs a mbuf to mbuf+cluster copy because of some pretty bogus > assumption in the KAME code that expects the data to be contiguous in > a single cluster. > > So when the 'n' mbuf is allocated and the cluster with it then a > shallow copy of the packet header is done from mbuf 'm' (the old mbuf) > to the newly allocated mbuf 'n'. What Robert is saying is that > this copy breaks his MAC label semantics which require a deeper copy > in this case and he is concerned that it may break the m_tag semantics > too, especially given the fact that the old mbuf 'm' is then freed > (doesn't this destroy the label?!). If that's indeed the case, then > this copy remains bogus. >
The real code (i.e. what was checked in when I replaced the aux mbufs w/ tags) doesn't do the above; it does the right thing; albeit using the binary copy of the mbuf instead of using the appropriate macro. Regardless Robert and I have been working through the details of revising the system handling of pkthdr's. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message