netdev - Re: [PATCH net v4 07/12] macvlan: use dynamic lockdep key instead of subclass

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: <33adc57c243dccc1dcb478113166fa01add3d49a.camel@sipsolutions.net>
Date:   Sat, 28 Sep 2019 21:14:54 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Taehee Yoo <ap420073@...il.com>, davem@...emloft.net,
        netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
        jakub.kicinski@...ronome.com, j.vosburgh@...il.com,
        vfalico@...il.com, andy@...yhouse.net, jiri@...nulli.us,
        sd@...asysnail.net, roopa@...ulusnetworks.com, saeedm@...lanox.com,
        manishc@...vell.com, rahulv@...vell.com, kys@...rosoft.com,
        haiyangz@...rosoft.com, stephen@...workplumber.org,
        sashal@...nel.org, hare@...e.de, varun@...lsio.com,
        ubraun@...ux.ibm.com, kgraul@...ux.ibm.com,
        jay.vosburgh@...onical.com, schuffelen@...gle.com, bjorn@...k.no
Subject: Re: [PATCH net v4 07/12] macvlan: use dynamic lockdep key instead
 of subclass

Hi,

I hadn't seen the previous patchsets of this, and looking briefly in the
archives didn't really seem to say anything about this.

However, I'm wondering now: patches 2-7 of this patchset look basically
all identical in a way:
 * you set the addr_list_lock's class to a newly registered key inside
   the netdev (or rather the private struct, but doesn't make a big
   difference)
 * you set each TX queue's _xmit_lock's class similarly
 * you set the qdisc_tx_busylock/qdisc_running_key

The first two of these look pretty much completely identical.

Would it perhaps make sense to just do that for *every* netdev? Many of
those netdevs won't ever nest so it wouldn't really be useful, but I'm
not convinced it would put that much more strain on lockdep - if
anything, people are probably creating more VLANs than regular PF/VF
netdevs anyway?

I didn't see any discussion on this, but perhaps I missed it? The cost
would be a bigger netdev struct (when lockdep is enabled), but we
already have that for all the VLANs etc. it's just in the private data,
so it's not a _huge_ difference really I'd think, and this is quite a
bit of code for each device type now.

Alternatively, maybe there could just be some common helper code:

struct nested_netdev_lockdep {
	struct lock_class_key xmit_lock_key;
	struct lock_class_key addr_lock_key;
};

void netdev_init_nested_lockdep(struct net_device *dev,
				struct netsted_netdev_lockdep *l)
{
	/* ... */
}

so you just have to embed a "struct nested_netdev_lockdep" in your
private data structure and call the common code.

Or maybe make that

void netdev_init_nested_lockdep(
	struct net_device *dev,
	struct
netsted_netdev_lockdep *l,
	struct lock_class_key
*qdisc_tx_busylock_key,
	struct lock_class_key *qdisc_running_key)

so you can't really get that part wrong either?

> @@ -922,6 +938,9 @@ static void macvlan_uninit(struct net_device *dev)
>  	port->count -= 1;
>  	if (!port->count)
>  		macvlan_port_destroy(port->dev);
> +
> +	lockdep_unregister_key(&vlan->addr_lock_key);
> +	lockdep_unregister_key(&vlan->xmit_lock_key);
>  }

OK, so I guess you need an equivalent "deinit" function too -
netdev_deinit_nested_lockdep() or so.

What's not really clear to me is why the qdisc locks can actually stay
the same at all levels? Can they just never nest? But then why are they
different per device type?

Thanks,
johannes