On Mon, Jan 29, 2018 at 9:03 AM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
> On Mon, Jan 29, 2018 at 8:00 AM, Stephen Hemminger
> <step...@networkplumber.org> wrote:
>> On Mon, 29 Jan 2018 16:18:07 +0100
>> "Roland Franke" <fl...@franke-prem.de> wrote:
>>
>>> Hello,
>>>
>>> > To: Roland Franke ; netdev@vger.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.wangc...@gmail.com>
Date:   Mon Dec 4 10:48:18 2017 -0800

    net_sched: get rid of rcu_barrier() in tcf_block_put_ext()

Reply via email to