[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpWZxdxmYBJmo-46FOPM22T63MOn9ZCCNfc=VdgcOyktKQ@mail.gmail.com>
Date: Mon, 29 Jan 2018 11:07:49 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: Roland Franke <fli4l@...nke-prem.de>,
Eric Dumazet <eric.dumazet@...il.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: iproute2 4.14.1 tc class add come to kernel-panic
On Mon, Jan 29, 2018 at 9:03 AM, Cong Wang <xiyou.wangcong@...il.com> wrote:
> On Mon, Jan 29, 2018 at 8:00 AM, Stephen Hemminger
> <stephen@...workplumber.org> wrote:
>> On Mon, 29 Jan 2018 16:18:07 +0100
>> "Roland Franke" <fli4l@...nke-prem.de> wrote:
>>
>>> Hello,
>>>
>>> > To: Roland Franke ; netdev@...r.kernel.org
>>> > Subject: Re: BUG: iproute2 4.14.1 tc class add come to kernel-panic
>>> >>
>>> >> tc qdisc add dev eth0 root handle 20: htb default 4 r2q 1
>>> >> tc class add dev eth0 parent 20: classid 20:7 htb rate 10000kbit
>>> >> tc qdisc add dev eth0 parent 20:7 sfq perturb 10
>>> >> tc class add dev eth0 parent 20:7 classid 20:1 htb rate 200kbit ceil
>>> >> 10000kbit prio 0
>>> >>
>>> >> I become an Kernel-panic with the following output:
>>> >> kern.err kernel: BUG: scheduling while atomic: tc/1036/0x00000200
>>> >
>>>
>>> > Would you have a stack trace to share with us ?
>>>
>>> As i will be an absolute newby here, i will not know how to
>>> get the stack trace out.
>>> When i will get some information how to get this, i can try to
>>> give you this information.
>>> But by my last tests i made the first 3 commands on an console
>>> and had no error. Only by typing the last line i will get the error and
>>> here i get actally only the "kern.err kernel: BUG: ....." message.
>>>
>>> Roland
>>
>> It generates this with lockdep (on 4.15)
>>
>> [ 151.355076] HTB: quantum of class 200007 is big. Consider r2q change.
>> [ 151.371495] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747
>> [ 151.371815] in_atomic(): 1, irqs_disabled(): 0, pid: 1135, name: tc
>> [ 151.371875] 2 locks held by tc/1135:
>> [ 151.371878] #0: (rtnl_mutex){+.+.}, at: [<ffffffff98826e5b>] rtnetlink_rcv_msg+0x23b/0x5f0
>> [ 151.371899] #1: (&qdisc_tx_lock){+...}, at: [<ffffffffc07a5f0f>] htb_change_class+0x55f/0x880 [sch_htb]
>> [ 151.371918] CPU: 2 PID: 1135 Comm: tc Not tainted 4.14.15 #2
>> [ 151.371921] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
>> [ 151.371924] Call Trace:
>> [ 151.371934] dump_stack+0x7c/0xbe
>> [ 151.371944] ___might_sleep+0x21e/0x250
>> [ 151.371953] __mutex_lock+0x59/0x9a0
>> [ 151.371960] ? lock_acquire+0xec/0x1e0
>> [ 151.371973] ? __raw_spin_lock_init+0x1c/0x50
>> [ 151.371990] ? _rcu_barrier+0x2f/0x170
>> [ 151.371995] ? __lockdep_init_map+0x5c/0x1d0
>> [ 151.371998] _rcu_barrier+0x2f/0x170
>> [ 151.372006] tcf_block_put+0x7f/0xa0
>> [ 151.372013] sfq_destroy+0x15/0x50 [sch_sfq]
>> [ 151.372021] qdisc_destroy+0x6c/0xe0
>> [ 151.372028] htb_change_class+0x704/0x880 [sch_htb]
>
>
> We hold qdisc tree spinlock but call rcu_barrier() in
> mini_qdisc_pair_swap()...
Well, not min_qdisc things, but it should be resolved by:
commit efbf78973978b0d25af59bc26c8013a942af6e64
Author: Cong Wang <xiyou.wangcong@...il.com>
Date: Mon Dec 4 10:48:18 2017 -0800
net_sched: get rid of rcu_barrier() in tcf_block_put_ext()
Powered by blists - more mailing lists