Re: WARNING: bad unlock balance in sch_direct_xmit

[Cong Wang <xiyou.wangcong@gmail.com>]

On Mon, Jan 13, 2020 at 2:53 AM Taehee Yoo <ap420073@gmail.com> wrote:
>
> On Sun, 12 Jan 2020 at 08:28, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> >
> > On Sat, Jan 11, 2020 at 1:53 PM Cong Wang <xiyou.wangcong@gmail.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.