Re: net/atm: warning in alloc_tx/__might_sleep

[Eric Dumazet]

On Tue, 2017-01-10 at 23:47 +0100, Francois Romieu wrote:
> Eric Dumazet <edumazet@xxxxxxxxxx> :
> > On Tue, Jan 10, 2017 at 9:35 AM, Cong Wang <xiyou.wangcong@xxxxxxxxx> wrote:
> > > On Mon, Jan 9, 2017 at 9:20 AM, Andrey Konovalov <andreyknvl@xxxxxxxxxx> wrote:
> > >
> > > The fix should be straight-forward. Mind to try the attached patch?
> > 
> > 
> > You forgot to remove schedule() ?
> 
> It may be clearer to split alloc_tx in two parts: only the unsleepable
> "if (sk_wmem_alloc_get(sk) && !atm_may_send(vcc, size)) {" part of it
> contributes to the inner "while (!(skb = alloc_tx(vcc, eff))) {" block.
> 
> See net/atm/common.c
> [...]
> static struct sk_buff *alloc_tx(struct atm_vcc *vcc, unsigned int size)
> {
>         struct sk_buff *skb;
>         struct sock *sk = sk_atm(vcc);
> 
>         if (sk_wmem_alloc_get(sk) && !atm_may_send(vcc, size)) {
>                 pr_debug("Sorry: wmem_alloc = %d, size = %d, sndbuf = %d\n",
>                          sk_wmem_alloc_get(sk), size, sk->sk_sndbuf);
>                 return NULL;
>         }
>         while (!(skb = alloc_skb(size, GFP_KERNEL)))
>                 schedule();

Yeah, this code looks quite wrong anyway.

We can read it as an infinite loop in some stress conditions or memcg
constraints.


> The waiting stuff is related to vcc drain but the code makes it look as
> if it were also related to skb alloc (it isn't).
> 
> It may be obvious for you but it took me a while to figure what the
> code is supposed to achieve.
>