On Mon, Jan 13, 2020 at 2:53 AM Taehee Yoo [off-list ref] wrote:

On Sun, 12 Jan 2020 at 08:28, Cong Wang [off-list ref] wrote:

quoted

On Sat, Jan 11, 2020 at 1:53 PM Cong Wang [off-list ref] wrote:

quoted

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.