Re: [PATCH RFC/RFT net-next v2 1/5] net: dsa: deny bridge VLAN with existing 8021q upper on any port

Simon Horman
2025-12-02T16:16:52Z

On Mon, Dec 01, 2025 at 02:48:48PM -0800, Chris Mason wrote:
> On Mon, 1 Dec 2025 20:52:34 +0100 Jonas Gorski <jonas.gorski@gmail.com> wrote:
>
> > Hi,
> >
> > On Mon, Dec 1, 2025 at 3:48 PM Simon Horman <horms@kernel.org> wrote:
> > >
> > > On Mon, Dec 01, 2025 at 11:28:13AM +0100, Jonas Gorski wrote:
> > >
> > > ...
> > >
> > > > diff --git a/net/dsa/user.c b/net/dsa/user.c
> > > > index f59d66f0975d..fa1fe0f1493a 100644
> > > > --- a/net/dsa/user.c
> > > > +++ b/net/dsa/user.c
> > > > @@ -653,21 +653,30 @@ static int dsa_user_port_attr_set(struct net_device *dev, const void *ctx,
> > > >
> > > > /* Must be called under rcu_read_lock() */
> > > > static int
> > > > -dsa_user_vlan_check_for_8021q_uppers(struct net_device *user,
> > > > +dsa_user_vlan_check_for_8021q_uppers(struct dsa_port *dp,
> > > > const struct switchdev_obj_port_vlan *vlan)
> > > > {
> > > > - struct net_device *upper_dev;
> > > > - struct list_head *iter;
> > > > + struct dsa_switch *ds = dp->ds;
> > > > + struct dsa_port *other_dp;
> > > >
> > > > - netdev_for_each_upper_dev_rcu(user, upper_dev, iter) {
> > > > - u16 vid;
> > > > + dsa_switch_for_each_user_port(other_dp, ds) {
> > > > + struct net_device *user = other_dp->user;
> > >
> > > Hi Jonas,
> > >
> > > The AI robot is concerned that user may be NULL here.
> > > And I can't convince myself that cannot be the case.
> > >
> > > Could you take a look?
> > >
> > > https://netdev-ai.bots.linux.dev/ai-review.html?id=47057e-e740-4b66-9d60-9ec2a7ee92a1#patch-0
> >
> > At this point it can be NULL. But it being NULL is not an issue, as ...
> > >
> > > > + struct net_device *upper_dev;
> > > > + struct list_head *iter;
> > > >
> > > > - if (!is_vlan_dev(upper_dev))
> > > > + if (!dsa_port_bridge_same(dp, other_dp))
> > > > continue;
> >
> > ... this condition will filter all cases where it is NULL. For
> > dsa_port_bridge_same() to return true both ports need to be attached
> > to a bridge (and to the same bridge), and to be attached to a bridge a
> > net_device is required, so other_dp->user cannot be NULL. And we only
> > access user after here.

Thanks for the explanation Jonas.

I wasn't very confident with this report.
And I was too focused on working out if user could be NULL rather
than if it matters. Still, I may not have worked it out.

>
> I reproduced this false positive here, thanks for the explanation. This is an
> example of a class of review mistakes I've wanted to fix, so I used it to
> improve the prompts around NULL pointers that are protected via other checks.
>
> I'll test this on some more commits and push it out.

Thanks for following-up on this Chris.

I guess everyone has their own opinion on AI.
And, in a similar vein, many have opinions on the review-prompts.
But, FTR, I've been impressed by the output I've seen,
having used them for a few weeks now. And I look forward
to that improving further.