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

[Stanislav Fomichev <stfomichev@gmail.com>]

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.