On Thu, Jan 12, 2017 at 4:07 PM, Francois Romieu <rom...@fr.zoreil.com> wrote:
> Cong Wang <xiyou.wangc...@gmail.com> :
> [...]
>> diff --git a/net/atm/common.c b/net/atm/common.c
>> index a3ca922..7ec3bbc 100644
>> --- a/net/atm/common.c
>> +++ b/net/atm/common.c
>> @@ -72,10 +72,11 @@ static struct sk_buff *alloc_tx(struct atm_vcc *vcc, 
>> unsigned int size)
>>                        sk_wmem_alloc_get(sk), size, sk->sk_sndbuf);
>>               return NULL;
>>       }
>> -     while (!(skb = alloc_skb(size, GFP_KERNEL)))
>> -             schedule();
>> -     pr_debug("%d += %d\n", sk_wmem_alloc_get(sk), skb->truesize);
>> -     atomic_add(skb->truesize, &sk->sk_wmem_alloc);
>> +     skb = alloc_skb(size, GFP_KERNEL);
>> +     if (skb) {
>> +             pr_debug("%d += %d\n", sk_wmem_alloc_get(sk), skb->truesize);
>> +             atomic_add(skb->truesize, &sk->sk_wmem_alloc);
>> +     }
>>       return skb;
>>  }
>
> Were alloc_skb moved one level up in the call stack, there would be
> no need to use the new wait api in the subsequent page, thus easing
> pre 3.19 longterm kernel maintenance (at least those on korg page).

alloc_skb(GFP_KERNEL) itself is sleeping, so the new wait api is still
needed.

Reply via email to