Bart De Schuymer <bdschuym@xxxxxxxxxx> wrote:
> I can't tell how many of these systems are running ebtables but
> considering most of the functionality has been working on a
> user32/kernel64 system since 2004 I think it's safe to say that
> Florian's patch will break a few systems.
Yes, I had feared that.
The way I see it we have a couple of alternatives.
One way would be to disable the in-kernel ebt-compat layer for
sparc64. Of course this assumes that this userland-side padding
is only used on the sparc platform.
> I'm not familiar with the way this compat layer works, but is there a
> standard way to ensure that old ebtables binaries don't use the compat
> layer, while a new version of the userspace program would?
It should be possible to figure out if we need to do fixups,
because struct ebt_replace size differs (and the sockopt *len
includes this value).
In some cases this is as simple as "if (*len == sizeof(struct
ebt_replace)". But even in case of EBT_SO_GET_ENTRIES it seems
possible. We can try the "native" getsockopt call first, it should
then error out early due to this check:
if (*len != sizeof(struct ebt_replace) + entries_size +
(tmp.num_counters? nentries * sizeof(struct ebt_counter): 0)) {
sizeof(struct ebt_counter): 0)) {
/* -EINVAL */
we can then re-try with all the compat fixups.
What do you think?
I'll do some tests with this in the next couple of days;
if everything looks good (and there are no objections) I'll post a revised
patch set.
> If all else fails, we could do this with a special flag in struct
> ebt_replace::valid_hooks, as this member has some unused bits.
Thanks, its good to know there is some kind of "last resort".
But I'd like to avoid any incompatibilities, if possible.
Regards, Florian
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
