On 2018/9/13 20:44, Eric Dumazet wrote:
> On Thu, Sep 13, 2018 at 5:32 AM Greg KH wrote:
>>
>> On Thu, Aug 16, 2018 at 05:24:09PM +0200, Greg KH wrote:
>>> On Thu, Aug 16, 2018 at 02:33:56PM +0200, Michal Kubecek wrote:
On Thu, Aug 16, 2018 at 08:05:50PM +0800, maowenan wrote:
> On 201
On Thu, Sep 13, 2018 at 5:32 AM Greg KH wrote:
>
> On Thu, Aug 16, 2018 at 05:24:09PM +0200, Greg KH wrote:
> > On Thu, Aug 16, 2018 at 02:33:56PM +0200, Michal Kubecek wrote:
> > > On Thu, Aug 16, 2018 at 08:05:50PM +0800, maowenan wrote:
> > > > On 2018/8/16 19:39, Michal Kubecek wrote:
> > > >
On Thu, Aug 16, 2018 at 05:24:09PM +0200, Greg KH wrote:
> On Thu, Aug 16, 2018 at 02:33:56PM +0200, Michal Kubecek wrote:
> > On Thu, Aug 16, 2018 at 08:05:50PM +0800, maowenan wrote:
> > > On 2018/8/16 19:39, Michal Kubecek wrote:
> > > >
> > > > I suspect you may be doing something wrong with y
On 2018/8/17 0:06, Michal Kubecek wrote:
> On Thu, Aug 16, 2018 at 05:24:09PM +0200, Greg KH wrote:
>> On Thu, Aug 16, 2018 at 02:33:56PM +0200, Michal Kubecek wrote:
>>>
>>> Anyway, even at this rate, I only get ~10% of one core (Intel E5-2697).
>>>
>>> What I can see, though, is that with curr
On Thu, Aug 16, 2018 at 06:06:16PM +0200, Michal Kubecek wrote:
> > If not, we can go from there and evaluate this much larger patch
> > series. But let's try the simple thing first.
>
> At high packet rates (say 30K pkt/s and more), we can still saturate the
> CPU. This is also mentioned in the
On Thu, Aug 16, 2018 at 05:24:09PM +0200, Greg KH wrote:
> On Thu, Aug 16, 2018 at 02:33:56PM +0200, Michal Kubecek wrote:
> >
> > Anyway, even at this rate, I only get ~10% of one core (Intel E5-2697).
> >
> > What I can see, though, is that with current stable 4.4 code, modified
> > testcase wh
On Thu, Aug 16, 2018 at 02:33:56PM +0200, Michal Kubecek wrote:
> On Thu, Aug 16, 2018 at 08:05:50PM +0800, maowenan wrote:
> > On 2018/8/16 19:39, Michal Kubecek wrote:
> > >
> > > I suspect you may be doing something wrong with your tests. I checked
> > > the segmentsmack testcase and the CPU ut
On Thu, Aug 16, 2018 at 08:05:50PM +0800, maowenan wrote:
> On 2018/8/16 19:39, Michal Kubecek wrote:
> >
> > 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
On 2018/8/16 19:39, Michal Kubecek wrote:
> 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
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
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 backp
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 intrusi
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 a
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
On 2018/8/16 14:52, Michal Kubecek wrote:
> On Thu, Aug 16, 2018 at 02:42:32PM +0800, maowenan wrote:
>> On 2018/8/16 14:16, Michal Kubecek wrote:
>>> On Thu, Aug 16, 2018 at 10:50:01AM +0800, Mao Wenan wrote:
There are five patches to fix CVE-2018-5390 in latest mainline
branch, but
On Thu, Aug 16, 2018 at 02:42:32PM +0800, maowenan wrote:
> On 2018/8/16 14:16, Michal Kubecek wrote:
> > On Thu, Aug 16, 2018 at 10:50:01AM +0800, Mao Wenan wrote:
> >> There are five patches to fix CVE-2018-5390 in latest mainline
> >> branch, but only two patches exist in stable 4.4 and 3.18:
On 2018/8/16 14:16, Michal Kubecek wrote:
> On Thu, Aug 16, 2018 at 10:50:01AM +0800, Mao Wenan wrote:
>> There are five patches to fix CVE-2018-5390 in latest mainline
>> branch, but only two patches exist in stable 4.4 and 3.18:
>> dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_q
On Thu, Aug 16, 2018 at 10:50:01AM +0800, Mao Wenan wrote:
> There are five patches to fix CVE-2018-5390 in latest mainline
> branch, but only two patches exist in stable 4.4 and 3.18:
> dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
> 5fbec48 tcp: avoid collapses in tcp_prune
There are five patches to fix CVE-2018-5390 in latest mainline
branch, but only two patches exist in stable 4.4 and 3.18:
dc6ae4d tcp: detect malicious patterns in tcp_collapse_ofo_queue()
5fbec48 tcp: avoid collapses in tcp_prune_queue() if possible
I have tested with stable 4.4 kernel, and foun
19 matches
Mail list logo
