Re: Backporting "ipv6: make fragment identifications less predictable"
Le dimanche 11 septembre 2011 à 14:52 +0100, Ben Hutchings a écrit :
> On Sat, 2011-09-10 at 16:59 +0200, Eric Dumazet wrote:
> > Le samedi 10 septembre 2011 à 02:30 +0100, Ben Hutchings a écrit :
> > > Is there any chance that this change could be backported to the 2.6.32.y
> > > longterm branch:
> > >
> > > commit 87c48fa3b4630905f98268dde838ee43626a060c
> > > Author: Eric Dumazet <eric.dumazet@gmail.com>
> > > Date: Thu Jul 21 21:25:58 2011 -0700
> > >
> > > ipv6: make fragment identifications less predictable
> > >
> > > I suspect that it's very much dependent on the earlier changes to dst
> > > and inetpeer, right?
> > >
> > > Ben.
> > >
> >
> > Hi Ben
> >
> > This was the fix meant for next kernels (>= 3.1) , not suitable for a
> > backport.
> >
> > I sent a patch for the backport, and David replied he would take care of
> > stable submission.
>
> However, he doesn't submit patches for 'longterm' series any more.
>
> > He did so, since it was included in 3.0-stable tree (>= 3.0.2)
> >
> > http://permalink.gmane.org/gmane.linux.kernel.stable/16086
> >
> > This one is far more easy to be included in old kernels ;)
>
> Right. So does this the following look right for 2.6.32?
>
It seems fine at a first glance.
> By the way, use of a hash table the size of a cache line doesn't seem
> likely to be much better than a spinlock. Still, anyone who cares about
> performance will avoid fragmentation since they are almost certainly
> going to lose TX checksum offload.
>
Well, its a security issue patch, not a performance fix anyway.
For optimum performances at this layer, the 3.0+ kernels are the way to
go ;)
Reply to: