On Sun, Nov 13, 2016 at 7:11 PM, Fengguang Wu wrote:
>>> Hi guys.
>>>
>>> I took a look at the commit again and I do not see how this can happen.
>>>
>>> Are you sure patch was properly applied ?
>>>
>>> In particular, the following extract is obscure for me :
>>>
>>>
On Mon, 2016-11-14 at 07:49 +0800, kernel test robot wrote:
> FYI, we noticed the following commit:
>
> https://github.com/0day-ci/linux
> Eric-Dumazet/net-__skb_flow_dissect-must-cap-its-return-value/20161110-080839
> commit 2ab9fb18c46b91b16a0f0f329336d3be9fc32deb ("net: __skb_flow_dissect()
On 11/14, Fengguang Wu wrote:
>>>Hi guys.
>>>
>>>I took a look at the commit again and I do not see how this can happen.
>>>
>>>Are you sure patch was properly applied ?
>>>
>>>In particular, the following extract is obscure for me :
>>>
>>>
https://github.com/0day-ci/linux
Hi guys.
I took a look at the commit again and I do not see how this can happen.
Are you sure patch was properly applied ?
In particular, the following extract is obscure for me :
https://github.com/0day-ci/linux
Eric-Dumazet/net-__skb_flow_dissect-must-cap-its-return-value/20161110-080839
On 11/13, Eric Dumazet wrote:
>On Mon, 2016-11-14 at 07:49 +0800, kernel test robot wrote:
>> FYI, we noticed the following commit:
>
>
>> in testcase: kbuild
>> with following parameters:
>>
>> runtime: 300s
>> nr_task: 50%
>> cpufreq_governor: performance
>>
>>
>>
>>
>> on
On Mon, 2016-11-14 at 07:49 +0800, kernel test robot wrote:
> FYI, we noticed the following commit:
> in testcase: kbuild
> with following parameters:
>
> runtime: 300s
> nr_task: 50%
> cpufreq_governor: performance
>
>
>
>
> on test machine: 8 threads Intel(R) Atom(TM)