Date: Wed, 1 Feb 2012 22:53:48 -0800 From: Navdeep Parhar <nparhar@gmail.com> To: Rozhuk.IM@gmail.com Cc: freebsd-net@freebsd.org Subject: Re: m_pullup - fail Message-ID: <CAPFoGT_6Qp-_qtQ4bDM6VMwG8D4P6m5JYjy5zoUXAZ1aFQBTdQ@mail.gmail.com> In-Reply-To: <4f298d95.82b7cc0a.49b2.5d24@mx.google.com> References: <4f298d95.82b7cc0a.49b2.5d24@mx.google.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 1, 2012 at 11:07 AM, <rozhuk.im@gmail.com> wrote:
> Hello!
>
>
> The function always returns an error and remove the chain MBUF for two or
> more generated on the same host.
> If the pre-call m_defrag no error occurs.
> This is normal behavior?
> How to know in advance the maximum size for MBUF that does not cause a
> failure in m_pullup?
You can't pullup more than MHLEN bytes into a pkthdr mbuf if it's not
associated with an external cluster. See the last sentence in this
excerpt from mbuf(9):
m_pullup(mbuf, len)
Arrange that the first len bytes of an mbuf chain are contiguous
and lay in the data area of mbuf, so they are accessible with
mtod(mbuf, type). It is important to remember that this may
involve reallocating some mbufs and moving data so all pointers
referencing data within the old mbuf chain must be recalculated or
made invalid. Return the new mbuf chain on success, NULL on fail-
ure (the mbuf chain is freed in this case). Note: It does not
allocate any mbuf clusters, so len must be less than MHLEN.
Regards,
Navdeep
>
>
> mbuf: 0xfffffe0074fc0600 len: 42, next: 0xfffffe0073a45800, 2<pkthdr>
> mbuf: 0xfffffe0073a45800 len: 210, next: 0, 1<ext>
> FAIL: m_pullup: m_pkthdr.len = 252, m_len = 42, pullup_len = 252
>
>
>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPFoGT_6Qp-_qtQ4bDM6VMwG8D4P6m5JYjy5zoUXAZ1aFQBTdQ>