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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 14 Jan 2020 11:39:22 -0800 From: Cong Wang <xiyou.wangcong@...il.com> To: Taehee Yoo <ap420073@...il.com> Cc: syzbot <syzbot+4ec99438ed7450da6272@...kaller.appspotmail.com>, Linux Kernel Network Developers <netdev@...r.kernel.org> Subject: Re: WARNING: bad unlock balance in sch_direct_xmit On Mon, Jan 13, 2020 at 2:53 AM Taehee Yoo <ap420073@...il.com> wrote: > > On Sun, 12 Jan 2020 at 08:28, Cong Wang <xiyou.wangcong@...il.com> wrote: > > > > On Sat, Jan 11, 2020 at 1:53 PM Cong Wang <xiyou.wangcong@...il.com> wrote: > > > The details you provide here are really helpful for me to understand > > > the reasons behind your changes. Let me think about this and see how > > > I could address both problems. This appears to be harder than I originally > > > thought. > > > > Do you think the following patch will make everyone happy? > > > > diff --git a/net/core/dev.c b/net/core/dev.c > > index 0ad39c87b7fd..7e885d069707 100644 > > --- a/net/core/dev.c > > +++ b/net/core/dev.c > > @@ -9177,22 +9177,10 @@ static void > > netdev_unregister_lockdep_key(struct net_device *dev) > > > > void netdev_update_lockdep_key(struct net_device *dev) > > { > > - struct netdev_queue *queue; > > - int i; > > - > > - lockdep_unregister_key(&dev->qdisc_xmit_lock_key); > > lockdep_unregister_key(&dev->addr_list_lock_key); > > - > > - lockdep_register_key(&dev->qdisc_xmit_lock_key); > > lockdep_register_key(&dev->addr_list_lock_key); > > > > lockdep_set_class(&dev->addr_list_lock, &dev->addr_list_lock_key); > > - for (i = 0; i < dev->num_tx_queues; i++) { > > - queue = netdev_get_tx_queue(dev, i); > > - > > - lockdep_set_class(&queue->_xmit_lock, > > - &dev->qdisc_xmit_lock_key); > > - } > > } > > EXPORT_SYMBOL(netdev_update_lockdep_key); > > > > I think as long as we don't take _xmit_lock nestedly, it is fine. And > > most (or all?) of the software netdev's are already lockless, so I can't > > think of any case we take more than one _xmit_lock on TX path. > > > > I tested it with the syzbot reproducer and your set master/nomaster > > commands, I don't get any lockdep splat. > > > > What do you think? > > > > Thanks! > > I have tested this approach and I have no found any problem. > As you said, most of virtual interfaces are already lockless. > So, generally lockdep warning will not occur. > I found two virtual interfaces that they don't have LLTX and they also > could be upper interface. Interfaces are "rmnet" and virt_wifi" type. > > My test case is here. > > [Before] > master0(bond or team or bridge) > | > slave0(rmnet or virt_wifi) > | > master1 > | > slave1 > | > master2 > | > veth > > [After] > master0(bond or team or bridge) > | > slave1(rmnet or virt_wifi) > | > master2 > | > slave0 > | > master1 > | > veth > > In this test, the ordering of slave1 and slave0 will be changed. > But, rmnet and virt_wifi type interface couldn't be slave of bond, team, > and bridge type interface. So, This graph will not be made. > So, I agree with this approach. Thanks for reviewing it and auditing more network devices. I will send out the patch formally.
Powered by blists - more mailing lists