From: Remi Pommarel <repk@triplefau.lt>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
linux-kernel@vger.kernel.org,
Nikolay Aleksandrov <nikolay@nvidia.com>,
Roopa Prabhu <roopa@nvidia.com>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [Bridge] [PATCH net 2/2] net: bridge: Get SIOCGIFBR/SIOCSIFBR ioctl working in compat mode
Date: Thu, 23 Dec 2021 19:05:20 +0100 [thread overview]
Message-ID: <YcS6YAJVFUDcDmo0@pilgrim> (raw)
In-Reply-To: <20211223095318.30d2b9ce@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
On Thu, Dec 23, 2021 at 09:53:18AM -0800, Jakub Kicinski wrote:
> On Thu, 23 Dec 2021 18:50:30 +0100 Remi Pommarel wrote:
> > On Thu, Dec 23, 2021 at 08:59:44AM -0800, Jakub Kicinski wrote:
> > > On Thu, 23 Dec 2021 16:31:39 +0100 Remi Pommarel wrote:
> > > > In compat mode SIOC{G,S}IFBR ioctls were only supporting
> > > > BRCTL_GET_VERSION returning an artificially version to spur userland
> > > > tool to use SIOCDEVPRIVATE instead. But some userland tools ignore that
> > > > and use SIOC{G,S}IFBR unconditionally as seen with busybox's brctl.
> > > >
> > > > Example of non working 32-bit brctl with CONFIG_COMPAT=y:
> > > > $ brctl show
> > > > brctl: SIOCGIFBR: Invalid argument
> > > >
> > > > Example of fixed 32-bit brctl with CONFIG_COMPAT=y:
> > > > $ brctl show
> > > > bridge name bridge id STP enabled interfaces
> > > > br0
> > > >
> > > > Signed-off-by: Remi Pommarel <repk@triplefau.lt>
> > > > Co-developed-by: Arnd Bergmann <arnd@arndb.de>
> > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > >
> > > Since Arnd said this is not supposed to be backported I presume it
> > > should go to net-next?
> >
> > Yes, out of curiosity, is it appropriate to mix "[PATCH net]" and
> > "[PATCH net-next]" in the same serie ?
>
> It's not, mixing makes it quite hard to know what's needed where.
> Also hard to automate things on our end. Let me pick out the first
> patch, I'll be sending a PR to Linus shortly and then merge net into
> net-next. At which point you'll be able to rebase on top of net-next
> and resend just the second patch for net-next..
Ok sounds good to me thanks.
WARNING: multiple messages have this Message-ID (diff)
From: Remi Pommarel <repk@triplefau.lt>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org, Roopa Prabhu <roopa@nvidia.com>,
Nikolay Aleksandrov <nikolay@nvidia.com>,
Arnd Bergmann <arnd@arndb.de>,
"David S. Miller" <davem@davemloft.net>,
bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net 2/2] net: bridge: Get SIOCGIFBR/SIOCSIFBR ioctl working in compat mode
Date: Thu, 23 Dec 2021 19:05:20 +0100 [thread overview]
Message-ID: <YcS6YAJVFUDcDmo0@pilgrim> (raw)
In-Reply-To: <20211223095318.30d2b9ce@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
On Thu, Dec 23, 2021 at 09:53:18AM -0800, Jakub Kicinski wrote:
> On Thu, 23 Dec 2021 18:50:30 +0100 Remi Pommarel wrote:
> > On Thu, Dec 23, 2021 at 08:59:44AM -0800, Jakub Kicinski wrote:
> > > On Thu, 23 Dec 2021 16:31:39 +0100 Remi Pommarel wrote:
> > > > In compat mode SIOC{G,S}IFBR ioctls were only supporting
> > > > BRCTL_GET_VERSION returning an artificially version to spur userland
> > > > tool to use SIOCDEVPRIVATE instead. But some userland tools ignore that
> > > > and use SIOC{G,S}IFBR unconditionally as seen with busybox's brctl.
> > > >
> > > > Example of non working 32-bit brctl with CONFIG_COMPAT=y:
> > > > $ brctl show
> > > > brctl: SIOCGIFBR: Invalid argument
> > > >
> > > > Example of fixed 32-bit brctl with CONFIG_COMPAT=y:
> > > > $ brctl show
> > > > bridge name bridge id STP enabled interfaces
> > > > br0
> > > >
> > > > Signed-off-by: Remi Pommarel <repk@triplefau.lt>
> > > > Co-developed-by: Arnd Bergmann <arnd@arndb.de>
> > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > >
> > > Since Arnd said this is not supposed to be backported I presume it
> > > should go to net-next?
> >
> > Yes, out of curiosity, is it appropriate to mix "[PATCH net]" and
> > "[PATCH net-next]" in the same serie ?
>
> It's not, mixing makes it quite hard to know what's needed where.
> Also hard to automate things on our end. Let me pick out the first
> patch, I'll be sending a PR to Linus shortly and then merge net into
> net-next. At which point you'll be able to rebase on top of net-next
> and resend just the second patch for net-next..
Ok sounds good to me thanks.
next prev parent reply other threads:[~2021-12-23 18:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-23 15:31 [Bridge] [PATCH net 0/2] Fix SIOCGIFBR/SIOCSIFBR ioctl Remi Pommarel
2021-12-23 15:31 ` Remi Pommarel
2021-12-23 15:31 ` [Bridge] [PATCH net 1/2] net: bridge: fix ioctl old_deviceless bridge argument Remi Pommarel
2021-12-23 15:31 ` Remi Pommarel
2021-12-23 15:31 ` [Bridge] [PATCH net 2/2] net: bridge: Get SIOCGIFBR/SIOCSIFBR ioctl working in compat mode Remi Pommarel
2021-12-23 15:31 ` Remi Pommarel
2021-12-23 16:59 ` [Bridge] " Jakub Kicinski
2021-12-23 16:59 ` Jakub Kicinski
2021-12-23 17:50 ` [Bridge] " Remi Pommarel
2021-12-23 17:50 ` Remi Pommarel
2021-12-23 17:53 ` [Bridge] " Jakub Kicinski
2021-12-23 17:53 ` Jakub Kicinski
2021-12-23 18:05 ` Remi Pommarel [this message]
2021-12-23 18:05 ` Remi Pommarel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YcS6YAJVFUDcDmo0@pilgrim \
--to=repk@triplefau.lt \
--cc=arnd@arndb.de \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nikolay@nvidia.com \
--cc=roopa@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.