On 05/14/2018 03:45 PM, stran...@codeaurora.org wrote:
> On 2018-05-11 17:16, Willem de Bruijn wrote:
>
>>> Hmm, no, we absolutely need to fix GSO instead.
>>>
>>> Think of a bonding device (or any virtual devices), your patch wont avoid
>>> the crash.
>
> Hi Eric. Can you clarify what you mea
>> Paged skbuffs is an optimization for gso, but the feature should
>> continue to work even if gso skbs are linear, indeed (if at the cost
>> of copying during skb_segment).
>>
>> We need to make paged contingent on scatter-gather. Rough
>> patch below. That is for ipv4 only, the same will be need
On 2018-05-11 17:16, Willem de Bruijn wrote:
Hmm, no, we absolutely need to fix GSO instead.
Think of a bonding device (or any virtual devices), your patch wont
avoid the crash.
Hi Eric. Can you clarify what you mean by "fix GSO?" Is that just having
the GSO path work
regardless of whether
On Thu, May 10, 2018 at 8:51 PM, Eric Dumazet wrote:
>
>
> On 05/10/2018 05:38 PM, Sean Tranchetti wrote:
>> Using GSO in the UDP path on a device with
>> scatter-gather netdevice feature disabled will result in a kernel
>> panic with the following call stack:
>>
>> This panic is the result of all
On 05/10/2018 05:38 PM, Sean Tranchetti wrote:
> Using GSO in the UDP path on a device with
> scatter-gather netdevice feature disabled will result in a kernel
> panic with the following call stack:
>
> This panic is the result of allocating SKBs with small size
> for the newly segmented SKB. If
Using GSO in the UDP path on a device with
scatter-gather netdevice feature disabled will result in a kernel
panic with the following call stack:
kernel BUG at net/core/skbuff.c:104!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
PC is at skb_panic+0x4c/0x54
LR is at skb_panic+0x4c/0x54
Process ud