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.duma...@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 ;) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1315764199.3174.9.camel@edumazet-laptop
