[<prev] [next>] [day] [month] [year] [list]
Message-ID: <a7a0f63afdcd30ec89692781b5804d0cb28e7ee8.camel@nvidia.com>
Date: Thu, 8 Oct 2020 17:54:40 +0000
From: Nikolay Aleksandrov <nikolay@...dia.com>
To: "kuba@...nel.org" <kuba@...nel.org>
CC: "bridge@...ts.linux-foundation.org"
<bridge@...ts.linux-foundation.org>,
"henrik.bjoernlund@...rochip.com" <henrik.bjoernlund@...rochip.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"horatiu.vultur@...rochip.com" <horatiu.vultur@...rochip.com>,
Roopa Prabhu <roopa@...dia.com>,
"UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>
Subject: Re: [PATCH net] bridge: Netlink interface fix.
On Thu, 2020-10-08 at 10:09 -0700, Jakub Kicinski wrote:
> On Thu, 8 Oct 2020 10:18:09 +0000 Nikolay Aleksandrov wrote:
> > On Wed, 2020-10-07 at 14:49 +0000, Nikolay Aleksandrov wrote:
> > > On Wed, 2020-10-07 at 12:07 +0000, Henrik Bjoernlund wrote:
> > > > This commit is correcting NETLINK br_fill_ifinfo() to be able to
> > > > handle 'filter_mask' with multiple flags asserted.
> > > >
> > > > Fixes: 36a8e8e265420 ("bridge: Extend br_fill_ifinfo to return MPR status")
> > > >
> > > > Signed-off-by: Henrik Bjoernlund <henrik.bjoernlund@...rochip.com>
> > > > Reviewed-by: Horatiu Vultur <horatiu.vultur@...rochip.com>
> > > > Suggested-by: Nikolay Aleksandrov <nikolay@...dia.com>
> > > > Tested-by: Horatiu Vultur <horatiu.vultur@...rochip.com>
> > > > ---
> > > > net/bridge/br_netlink.c | 26 +++++++++++---------------
> > > > 1 file changed, 11 insertions(+), 15 deletions(-)
> > > >
> > >
> > > The patch looks good, please don't separate the Fixes tag from the others.
> > > Acked-by: Nikolay Aleksandrov <nikolay@...dia.com>
> > >
> >
> > TBH, this does change a user facing api (the attribute nesting), but I think
> > in this case it's acceptable due to the format being wrong and MRP being new, so
> > I doubt anyone is yet dumping it mixed with vlan filter_mask and checking for
> > two identical attributes, i.e. in the old/broken case parsing the attributes
> > into a table would hide one of them and you'd have to walk over all attributes
> > to catch that.
>
> To be clear - this changes the uAPI as far as 5.9-rcs are concerned.
> So if this change was to hit 5.9 final there would be no uAPI breakage,
> right?
Yes, correct.
Powered by blists - more mailing lists