From: Eric Dumazet <eric.dumazet@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: netdev <netdev@vger.kernel.org>
Subject: Re: [RFC] should we care of COMPAT mode in bridge ?
Date: Mon, 06 Jun 2011 22:12:54 +0200 [thread overview]
Message-ID: <1307391174.2642.8.camel@edumazet-laptop> (raw)
In-Reply-To: <201106062206.29134.arnd@arndb.de>
Le lundi 06 juin 2011 à 22:06 +0200, Arnd Bergmann a écrit :
> On Monday 06 June 2011 21:45:40 Eric Dumazet wrote:
> > While trying Alexander Holler patch, I found a 32bit brctl program was
> > not able to work on a 64bit kernel. So I had to switch to another
> > machine for my tests.
> >
> > brctl addbr mybridge
> > ->
> > socket(PF_FILE, SOCK_STREAM, 0) = 3
> > ioctl(3, SIOCSIFBR, 0xffd509c0) = -1 EINVAL (Invalid argument)
> >
> > Should we care or not ?
> >
>
> Generally, we try to make all ioctls work in compat mode. For the old
> bridge ioctls, this is currently impossible because it uses SIOCPRIVATE
> ioctls, but it would be easy to add an ndo_do_compat_ioctl.
>
> The solution that is documented in net/socket.c is to return
> an invalid version number for BRCTL_VERSION, in the hope that
> brctl would switch to the newer interfaces. The new style bridge
> ioctls (SIOCBRADDBR, SIOCBRADDIF, ...) are actually supposed to work,
> but I've never tried that.
>
I see... problem is brctl does :
int br_add_bridge(const char *brname)
{
int ret;
#ifdef SIOCBRADDBR
ret = ioctl(br_socket_fd, SIOCBRADDBR, brname);
if (ret < 0)
#endif
{
char _br[IFNAMSIZ];
unsigned long arg[3]
= { BRCTL_ADD_BRIDGE, (unsigned long) _br };
strncpy(_br, brname, IFNAMSIZ);
ret = ioctl(br_socket_fd, SIOCSIFBR, arg);
}
return ret < 0 ? errno : 0;
}
So for an old binary, compiled at the time SIOCBRADDBR wasnt there (in
include file I mean), we ended doing :
{
char _br[IFNAMSIZ];
unsigned long arg[3]
= { BRCTL_ADD_BRIDGE, (unsigned long) _br };
strncpy(_br, brname, IFNAMSIZ);
ret = ioctl(br_socket_fd, SIOCSIFBR, arg);
}
And this breaks on 64bit kernel
I guess we shall add some logic in kernel to support SIOCSIFBR
afterall ;)
Thanks !
BTW: I confirm that compiling an up2date 32bit brctl with an up2date
include files is OK on 64bit kernel.
next prev parent reply other threads:[~2011-06-06 20:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-06 19:45 [RFC] should we care of COMPAT mode in bridge ? Eric Dumazet
2011-06-06 20:03 ` David Miller
2011-06-06 20:23 ` Chris Friesen
2011-06-06 20:31 ` Arnd Bergmann
2011-06-06 20:31 ` Andreas Schwab
2011-06-06 20:34 ` Eric Dumazet
2011-06-07 23:51 ` Stephen Hemminger
2011-06-08 0:27 ` David Miller
2011-06-08 16:08 ` Stephen Hemminger
2011-06-06 20:06 ` Arnd Bergmann
2011-06-06 20:09 ` David Miller
2011-06-06 20:19 ` Arnd Bergmann
2011-06-06 20:23 ` David Miller
2011-06-07 23:54 ` Stephen Hemminger
2011-06-06 20:12 ` Eric Dumazet [this message]
2011-06-06 20:26 ` Arnd Bergmann
2011-06-06 20:32 ` Eric Dumazet
2011-06-06 20:33 ` Arnd Bergmann
2011-06-06 20:35 ` Eric Dumazet
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=1307391174.2642.8.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=arnd@arndb.de \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox