netdev - Re: [PATCH net-next v7 04/12] net: hold netdev instance lock during rtnetlink operations

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] [day] [month] [year] [list]

Message-ID: <Z79MuRd1ZBfbDj4p@mini-arch>
Date: Wed, 26 Feb 2025 09:17:45 -0800
From: Stanislav Fomichev <stfomichev@...il.com>
To: Jakub Kicinski <kuba@...nel.org>, edumazet@...gle.com
Cc: Stanislav Fomichev <sdf@...ichev.me>, netdev@...r.kernel.org,
	davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
	Saeed Mahameed <saeed@...nel.org>
Subject: Re: [PATCH net-next v7 04/12] net: hold netdev instance lock during
 rtnetlink operations

On 02/25, Stanislav Fomichev wrote:
> On 02/25, Jakub Kicinski wrote:
> > On Mon, 24 Feb 2025 10:08:00 -0800 Stanislav Fomichev wrote:
> > > +static inline int netdev_lock_cmp_fn(const struct lockdep_map *a,
> > > +				     const struct lockdep_map *b)
> > > +{
> > > +	/* Only lower devices currently grab the instance lock, so no
> > > +	 * real ordering issues can occur. In the near future, only
> > > +	 * hardware devices will grab instance lock which also does not
> > > +	 * involve any ordering. Suppress lockdep ordering warnings
> > > +	 * until (if) we start grabbing instance lock on pure SW
> > > +	 * devices (bond/team/veth/etc).
> > > +	 */
> > > +	return -1;
> > 
> > Does this no kill all lockdep warnings?
> 
> Initially I was gonna say "no" because I've seen (and do see) deadlock
> warnings with netdevsim, but looking at the code I think you're right.

[..]

> And netdevsim doesn't call netdev_lockdep_set_classes :-/ I think we want
> to add that as well?

More context: commit 0bef512012b1 ("net: add netdev_lockdep_set_classes() to
virtual drivers") added netdev_lockdep_set_classes invocation to tunnel
devices (which makes sense), but also lo and dummy (which doesn't). It
might have been overly eager? As discussed, I was under the impression
that netdev_lockdep_set_classes is needed only for the stacked devices or
devices that have peers. 

Eric, if you have more context on why we need netdev_lockdep_set_classes
in dummy/lo please chime in. I'll post v8 without adding
netdev_lockdep_set_classes to netdevsim, can follow up separately.
 
> I will make cmp_fn be:
> if (a == b)
> 	return 0;
> return -1;
> 
> That should bring back deadlock detection for the rest for the sw
> drivers.