linux-next 20141208 - net/sched/sch_fq_codel.c:97 suspicious RCU

linux-next 20141208 - net/sched/sch_fq_codel.c:97 suspicious RCU

[Valdis Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 3478 bytes --]

Spotted this in dmesg while investigating why my wireless broke
sometime between next-20141201 and next-20141208.  Probably not
related, as wireless has been broken on several boot attempts of -1208,
but this has popped only once....

Looks like the fault of

commit 46e5da40aec256155cfedee96dd21a75da941f2c
Author: John Fastabend <john.fastabend@gmail.com>
Date:   Fri Sep 12 20:04:52 2014 -0700

    net: qdisc: use rcu prefix and silence sparse warnings

but I freely admit that exhausts my RCU debugging skills. :)

[  104.743212] ===============================
[  104.743214] [ INFO: suspicious RCU usage. ]
[  104.743218] 3.18.0-next-20141208 #27 Tainted: G           OE
[  104.743219] -------------------------------
[  104.743224] net/sched/sch_fq_codel.c:97 suspicious rcu_dereference_check() usage!
[  104.743227]
other info that might help us debug this:

[  104.743231]
rcu_scheduler_active = 1, debug_locks = 1
[  104.743236] 4 locks held by unbound/1873:
[  104.743239]  #0:  (rcu_read_lock_bh){......}, at: [<ffffffff8a537066>] rcu_lock_acquire+0x0/0x22
[  104.743257]  #1:  (rcu_read_lock_bh){......}, at: [<ffffffff8a4ebd44>] rcu_lock_acquire+0x0/0x22
[  104.743274]  #2:  (dev->qdisc_tx_busylock ?: &qdisc_tx_busylock){+.....}, at: [<ffffffff8a4f3ea4>] __dev_queue_xmit+0x32a/0x66a
[  104.743292]  #3:  (&qdisc_tx_lock){+.-...}, at: [<ffffffff8a4f3ead>] __dev_queue_xmit+0x333/0x66a
[  104.743302]
stack backtrace:
[  104.743307] CPU: 2 PID: 1873 Comm: unbound Tainted: G           OE  3.18.0-next-20141208 #27
[  104.743309] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A15 06/20/2014
[  104.743312]  0000000000000001 ffff8800b9f3f978 ffffffff8a6ba925 ffff880223bac210
[  104.743317]  0000000000000001 ffff8800b9f3f9a8 ffffffff8a07f124 ffff8800b9ce4e00
[  104.743323]  ffff880223fea600 0000000000000000 ffff8800c6e2c000 ffff8800b9f3f9f8
[  104.743329] Call Trace:
[  104.743336]  [<ffffffff8a6ba925>] dump_stack+0x50/0xa8
[  104.743343]  [<ffffffff8a07f124>] lockdep_rcu_suspicious+0xea/0xf3
[  104.743348]  [<ffffffff8a514903>] fq_codel_enqueue+0x79/0x21c
[  104.743353]  [<ffffffff8a6c5228>] ? _raw_spin_lock+0x37/0x3f
[  104.743357]  [<ffffffff8a4f3fb5>] __dev_queue_xmit+0x43b/0x66a
[  104.743362]  [<ffffffff8a4f41ef>] dev_queue_xmit+0xb/0xd
[  104.743367]  [<ffffffff8a537beb>] ip_finish_output2+0x42b/0x46c
[  104.743371]  [<ffffffff8a53838f>] ip_finish_output+0x13c/0x144
[  104.743376]  [<ffffffff8a5393f1>] ip_output+0x4c/0x70
[  104.743381]  [<ffffffff8a538d92>] ip_local_out_sk+0x54/0x5f
[  104.743385]  [<ffffffff8a539c2f>] ip_send_skb+0x12/0x37
[  104.743390]  [<ffffffff8a55d145>] udp_send_skb+0x176/0x1db
[  104.743394]  [<ffffffff8a55d839>] udp_sendmsg+0x63e/0x87c
[  104.743398]  [<ffffffff8a537379>] ? skb_set_owner_w+0x56/0x56
[  104.743404]  [<ffffffff8a09011d>] ? __rcu_read_unlock+0xf5/0xfd
[  104.743408]  [<ffffffff8a568135>] ? rcu_read_unlock+0x3e/0x5d
[  104.743413]  [<ffffffff8a568af9>] inet_sendmsg+0x3d/0x66
[  104.743419]  [<ffffffff8a4d6a4b>] __sock_sendmsg_nosec+0x25/0x27
[  104.743422]  [<ffffffff8a4d80da>] sock_sendmsg+0x5a/0x7b
[  104.743429]  [<ffffffff8a12581b>] ? might_fault+0xae/0xb0
[  104.743433]  [<ffffffff8a4d6c22>] ? audit_sockaddr+0x2b/0x44
[  104.743437]  [<ffffffff8a4da1ff>] SYSC_sendto+0x119/0x15c
[  104.743443]  [<ffffffff8a00e2b5>] ? do_audit_syscall_entry+0xb8/0xc7
[  104.743447]  [<ffffffff8a4da85d>] SyS_sendto+0x9/0xb
[  104.743453]  [<ffffffff8a6c5fd2>] system_call_fastpath+0x12/0x17


[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

Re: linux-next 20141208 - net/sched/sch_fq_codel.c:97 suspicious RCU

[Eric Dumazet]

On Tue, Dec 9, 2014 at 9:51 AM, Valdis Kletnieks
<Valdis.Kletnieks@vt.edu> wrote:
> Spotted this in dmesg while investigating why my wireless broke
> sometime between next-20141201 and next-20141208.  Probably not
> related, as wireless has been broken on several boot attempts of -1208,
> but this has popped only once....
>
> Looks like the fault of
>
> commit 46e5da40aec256155cfedee96dd21a75da941f2c
> Author: John Fastabend <john.fastabend@gmail.com>
> Date:   Fri Sep 12 20:04:52 2014 -0700

Well, its a (harmless) typo : this should really be an
rcu_dereference_bh() instead of rcu_dereference()

Re: linux-next 20141208 - net/sched/sch_fq_codel.c:97 suspicious RCU

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

On Tue, 09 Dec 2014 10:07:31 -0800, Eric Dumazet said:
> On Tue, Dec 9, 2014 at 9:51 AM, Valdis Kletnieks

> > commit 46e5da40aec256155cfedee96dd21a75da941f2c
> > Author: John Fastabend <john.fastabend@gmail.com>
> > Date:   Fri Sep 12 20:04:52 2014 -0700
>
> Well, its a (harmless) typo : this should really be an
> rcu_dereference_bh() instead of rcu_dereference()

You want a patch, or you got it already?


[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

Re: linux-next 20141208 - net/sched/sch_fq_codel.c:97 suspicious RCU

[Eric Dumazet]

On Tue, Dec 9, 2014 at 10:54 AM,  <Valdis.Kletnieks@vt.edu> wrote:

> You want a patch, or you got it already?
>

If you could submit it formally, this would be great , thanks !

diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c
index b9ca32ebc1de..1e52decb7b59 100644
--- a/net/sched/sch_fq_codel.c
+++ b/net/sched/sch_fq_codel.c
@@ -94,7 +94,7 @@ static unsigned int fq_codel_classify(struct sk_buff
*skb, struct Qdisc *sch,
            TC_H_MIN(skb->priority) <= q->flows_cnt)
                return TC_H_MIN(skb->priority);

-       filter = rcu_dereference(q->filter_list);
+filter = rcu_dereference_bh(q->filter_list);
        if (!filter)
                return fq_codel_hash(q, skb) + 1;