netdev - Re: WARNING: bad unlock balance in sch_direct

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMArcTVHj2_yGjsYMoMow0LsAe0cs+Xyz68+TAa6Nb4tQbc6EA@mail.gmail.com>
Date:   Mon, 13 Jan 2020 19:53:42 +0900
From:   Taehee Yoo <ap420073@...il.com>
To:     Cong Wang <xiyou.wangcong@...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 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.

Thank you so much!
Taehee Yoo