On Thu, Aug 16, 2018 at 03:55:16PM +0800, maowenan wrote: > On 2018/8/16 15:44, Michal Kubecek wrote: > > On Thu, Aug 16, 2018 at 03:39:14PM +0800, maowenan wrote: > >> > >> > >> On 2018/8/16 15:23, Michal Kubecek wrote: > >>> On Thu, Aug 16, 2018 at 03:19:12PM +0800, maowenan wrote: > >>>> On 2018/8/16 14:52, Michal Kubecek wrote: > >>>>> > >>>>> My point is that backporting all this into stable 4.4 is quite intrusive > >>>>> so that if we can achieve similar results with a simple fix of an > >>>>> obvious omission, it would be preferrable. > >>>> > >>>> There are five patches in mainline to fix this CVE, only two patches > >>>> have no effect on stable 4.4, the important reason is 4.4 use simple > >>>> queue but mainline use RB tree. > >>>> > >>>> I have tried my best to use easy way to fix this with dropping packets > >>>> 12.5%(or other value) based on simple queue, but the result is not > >>>> very well, so the RB tree is needed and tested result is my desire. > >>>> > >>>> If we only back port two patches but they don't fix the issue, I think > >>>> they don't make any sense. > >>> > >>> There is an obvious omission in one of the two patches and Takashi's > >>> patch fixes it. If his follow-up fix (applied on top of what is in > >>> stable 4.4 now) addresses the problem, I would certainly prefer using it > >>> over backporting the whole series. > >> > >> Do you mean below codes from Takashi can fix this CVE? > >> But I have already tested like this two days ago, it is not good effect. > > > > IIRC what you proposed was different, you proposed to replace the "=" in > > the other branch by "+=". > > No, I think you don't get what I mean, I have already tested stable 4.4, > based on commit dc6ae4d, and change the codes like Takashi, which didn't > contain any codes I have sent in this patch series. I suspect you may be doing something wrong with your tests. I checked the segmentsmack testcase and the CPU utilization on receiving side (with sending 10 times as many packets as default) went down from ~100% to ~3% even when comparing what is in stable 4.4 now against older 4.4 kernel. This is actually not surprising. the testcase only sends 1-byte segments starting at even offsets so that receiver never gets two adjacent segments and the "range_truesize != head->truesize" condition would never be satisfied, whether you fix the backport or not. Where the missing "range_truesize += skb->truesize" makes a difference is in the case when there are some adjacent out of order segments, e.g. if you omitted 1:10 and then sent 10:11, 11:12, 12:13, 13:14, ... Then the missing update of range_truesize would prevent collapsing the queue until the total length of the range would exceed the value of SKB_WITH_OVERHEAD(SK_MEM_QUANTUM) (i.e. a bit less than 4 KB). Michal Kubecek
