linux-kernel - Re: net/atm: warning in alloc_tx/__might

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 11 Jan 2017 11:11:59 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Francois Romieu <romieu@...zoreil.com>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Andrey Konovalov <andreyknvl@...gle.com>,
        "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        James Morris <jmorris@...ei.org>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Patrick McHardy <kaber@...sh.net>,
        netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Kostya Serebryany <kcc@...gle.com>,
        syzkaller <syzkaller@...glegroups.com>
Subject: Re: net/atm: warning in alloc_tx/__might_sleep

On Tue, 2017-01-10 at 23:47 +0100, Francois Romieu wrote:
> Eric Dumazet <edumazet@...gle.com> :
> > On Tue, Jan 10, 2017 at 9:35 AM, Cong Wang <xiyou.wangcong@...il.com> wrote:
> > > On Mon, Jan 9, 2017 at 9:20 AM, Andrey Konovalov <andreyknvl@...gle.com> 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.
>