Re: [PATCH v1 net-next] tun: Ignore tun in netdev_lock_pos().

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Eric Dumazet wrote:
> On Fri, Mar 27, 2026 at 4:16 PM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> >
> > Kuniyuki Iwashima wrote:
> > > On Fri, Mar 27, 2026 at 2:48 PM Eric Dumazet <edumazet@google.com> wrote:
> > > >
> > > > On Fri, Mar 27, 2026 at 2:34 PM Kuniyuki Iwashima <kuniyu@google.com> wrote:
> > > > >
> > > > > dev->type could be any value on tun due to TUNSETLINK.
> > > > >
> > > > > Let's not warn about it in netdev_lock_pos().
> > > > >
> > > > > Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
> > > >
> > > > Hmmm... should we instead have a list of supported types ?
> > > >
> > > > And reject user space requests for unsupported ones ?
> > >
> > > I chose a safer way but maybe we could reuse tun_get_addr_len()
> > > and define the default case there as unsupported ?
> > >
> > > I guess it's okay even if it breaks userspace because we can
> > > just add a single line to restore the support.
> >
> > We shouldn't risk breaking userspace, over such a sanity check.
> 
> The thing is : this check makes sure that each type has a different
> lockdep class.
> 
> >
> > Presumably any truly newly added type will have a non-zero addr_len.
> > While tun sets this to zero for weird inputs. Maybe just filter on
> > that in the WARN_ONCE?
> 
> Then we might hit some lockdep issues...

Warnings due to stacked devices wouldn't apply to tun.

Can this be used to set up (false positive) lock inversion deadline
reports?
 
> Perhaps use lockdep_register_key() on each tun device...

In tun_set_iff replace the xmit_lockdep_class previously set by
netdev_init_one_queue?


If keeping the approach from v1, perhaps a tun device can already be
identified in core code without having to export tun_link_ops.
From the init in tun_set_iff, dev->sysfs_groups[0] will have an attr
"tun_flags". There might be something more elegant. Just the first I
spotted.