Re: m_move_pkthdr leaves m_nextpkt 'dangling'

2017-10-23 Thread Adrian Chadd
On 16 October 2017 at 10:57, Gleb Smirnoff wrote: > Karim, > > On Mon, Oct 16, 2017 at 10:37:02AM -0400, Karim Fodil-Lemelin wrote: > K> > Not only mbufs of M_PKTHDR may have m_nextpkt set. However, I tend to > agree > K> > with the patch. But shouldn't we first copy the

Re: m_move_pkthdr leaves m_nextpkt 'dangling'

2017-10-16 Thread Gleb Smirnoff
Karim, On Mon, Oct 16, 2017 at 10:37:02AM -0400, Karim Fodil-Lemelin wrote: K> > Not only mbufs of M_PKTHDR may have m_nextpkt set. However, I tend to agree K> > with the patch. But shouldn't we first copy the m_nextpkt to the new mbuf: K> > K> > + to->m_nextpkt = from->m_nextpkt; K> > +

Re: m_move_pkthdr leaves m_nextpkt 'dangling'

2017-10-16 Thread Karim Fodil-Lemelin
On 2017-10-13 5:10 PM, Gleb Smirnoff wrote: On Fri, Oct 13, 2017 at 12:59:47AM -0700, Adrian Chadd wrote: A> When doing so m_move_pkthdr is called to copy the current PKTHDR fields A> (tags and flags) to the mbuf that was prepended. The function also does: A> A> to->m_pkthdr

Re: m_move_pkthdr leaves m_nextpkt 'dangling'

2017-10-13 Thread Gleb Smirnoff
On Fri, Oct 13, 2017 at 12:59:47AM -0700, Adrian Chadd wrote: A> When doing so m_move_pkthdr is called to copy the current PKTHDR fields A> (tags and flags) to the mbuf that was prepended. The function also does: A> A> to->m_pkthdr = from->m_pkthdr; A> A> This, for

Re: m_move_pkthdr leaves m_nextpkt 'dangling'

2017-10-13 Thread Adrian Chadd
Gleb, what do you think? -a On 12 October 2017 at 13:42, Karim Fodil-Lemelin wrote: > On 2017-07-07 10:46 AM, Andrey V. Elsukov wrote: >> >> On 05.07.2017 19:23, Adrian Chadd wrote: As many of you know, when dealing with IP fragments the kernel will

Re: m_move_pkthdr leaves m_nextpkt 'dangling'

2017-10-12 Thread Karim Fodil-Lemelin
On 2017-07-07 10:46 AM, Andrey V. Elsukov wrote: On 05.07.2017 19:23, Adrian Chadd wrote: As many of you know, when dealing with IP fragments the kernel will build a list of packets (fragments) chained together through the m_nextpkt pointer. This is all good until someone tries to do a

[Bug 220882] m_move_pkthdr leaves m_nextpkt 'dangling'

2017-07-20 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220882 Mark Linimon changed: What|Removed |Added Assignee|freebsd-b...@freebsd.org

Re: m_move_pkthdr leaves m_nextpkt 'dangling'

2017-07-07 Thread Andrey V. Elsukov
On 05.07.2017 19:23, Adrian Chadd wrote: >> As many of you know, when dealing with IP fragments the kernel will build a >> list of packets (fragments) chained together through the m_nextpkt pointer. >> This is all good until someone tries to do a M_PREPEND on one of the packet >> in the chain and

Re: m_move_pkthdr leaves m_nextpkt 'dangling'

2017-07-05 Thread Adrian Chadd
On 30 June 2017 at 08:42, Karim Fodil-Lemelin wrote: > Hi, > > As many of you know, when dealing with IP fragments the kernel will build a > list of packets (fragments) chained together through the m_nextpkt pointer. > This is all good until someone tries to do a

m_move_pkthdr leaves m_nextpkt 'dangling'

2017-06-30 Thread Karim Fodil-Lemelin
Hi, As many of you know, when dealing with IP fragments the kernel will build a list of packets (fragments) chained together through the m_nextpkt pointer. This is all good until someone tries to do a M_PREPEND on one of the packet in the chain and the M_PREPEND has to create an extra mbuf