Bug 128398 - IPV6_V6ONLY handling broken in 2.6 on ppc64 for 32-bit binaries
Summary: IPV6_V6ONLY handling broken in 2.6 on ppc64 for 32-bit binaries
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: powerpc
OS: Linux
Target Milestone: ---
: ---
Assignee: David Woodhouse
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-07-22 15:46 UTC by Joe Orton
Modified: 2007-11-30 22:07 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2005-01-14 10:48:21 UTC

Attachments (Terms of Use)
repro case (1.67 KB, text/plain)
2004-07-22 15:48 UTC, Joe Orton
no flags Details
Patch to be more selective about when we mangle sockopt args. (858 bytes, patch)
2004-09-03 16:56 UTC, David Woodhouse
no flags Details | Diff

Description Joe Orton 2004-07-22 15:46:29 UTC
Description of problem:
For a 32-bit binary running on a ppc64 kernel, calling setsockopt for
the IPV6_V6ONLY option always enables the option regardless of the
value passed.

Version-Release number of selected component (if applicable):
Linux pseries.cambridge.redhat.com 2.6.7-1.451.2.3 #1 SMP Wed Jul 14
17:48:42 EDT 2004 ppc64 ppc64 ppc64 GNU/Linux

How reproducible:

Actual results:
[root@pseries root]# gcc  ./bind.c
[root@pseries root]# ./a.out
Setting V6ONLY to 0
V6ONLY setting is now: 1

Expected results:
as per -m64 build or any other kernel:

[root@pseries root]# gcc -m64  ./bind.c
[root@pseries root]# ./a.out
Setting V6ONLY to 0
V6ONLY setting is now: 0

Additional info:

Comment 1 Joe Orton 2004-07-22 15:48:31 UTC
Created attachment 102147 [details]
repro case

Comment 2 Joe Orton 2004-07-22 16:08:56 UTC
(net effect of this bug is that httpd doesn't accept connections to
IPv4 addresses in the default config on pseries in the current RHEL4 tree)

Comment 3 David Miller 2004-07-22 18:49:04 UTC
This works perfectly fine for a 32-bit binary running
on sparc64, so this looks entirely like some kind of
ppc64 specific problem with it's compat layer handling.

This should be thus assigned to a ppc64 expert.

Comment 4 Joe Orton 2004-07-23 14:07:45 UTC
Interesting you mention sparc64, we had a report upstream with exactly
the same symptoms as this problem from a 2.6.7 user on SPARC.  Maybe
you can try the whole test case with the #if 0 -> #if 1 to check it
really does accept connections to IPv4 addresses.

Comment 5 David Miller 2004-07-23 20:39:40 UTC
Yep, works perfectly fine under 2.6.8-rc2

davem@nuts:/disk1/BK/net-2.6$ uname -a
Linux nuts 2.6.8-rc2 #4 SMP Fri Jul 23 00:10:29 PDT 2004 sparc64 GNU/Linux
davem@nuts:/disk1/BK/net-2.6$ gcc -m32 -O2 -o bind bind.c
davem@nuts:/disk1/BK/net-2.6$ ./bind
Setting V6ONLY to 0
V6ONLY setting is now: 0
Accepted connection from ::ffff:, port 32782

Comment 6 Joe Orton 2004-08-11 12:42:08 UTC
Bug still present in:

Linux fish.cambridge.redhat.com 2.6.7-1.503 #1 SMP Mon Aug 2 14:05:20
EDT 2004 ppc64 ppc64 ppc64 GNU/Linux

Comment 7 David Woodhouse 2004-09-01 18:01:02 UTC
Bug is in generic compat_sys_setsockopt(). It mangles the arguments if
optname == SO_ATTACH_FILTER.

SO_ATTACH_FILTER == 26 == IPV6_V6ONLY. Surely when deciding how to
mangle we ought to be looking at level too, not just optname?

I'm going to chase down bug #129905 first -- the mangling for some of
the special cases also looks broken. 

Comment 8 David Woodhouse 2004-09-03 16:56:10 UTC
Created attachment 103442 [details]
Patch to be more selective about when we mangle sockopt args.

This makes compat_sys_setsockopt() a little more selective about when it
mangles the arguments. It does fix the observed problem but it's still not

Is do_netfilter_replace() actually correct to do the same thing for
IPT_SO_SET_REPLACE and IPT6_SO_SET_REPLACE and anything else which happens to
have optname 64?

Should we move the struct-conversion to the actual sockopt handlers rather than
having it in the syscall wrapper?

Comment 9 David Woodhouse 2004-09-03 16:59:09 UTC
cf. bug #129905 -- when we _do_ munge, we seem to get it wrong somehow.

Does _that_ work OK on sparc64?

Comment 10 David Miller 2004-09-03 17:03:32 UTC
If you want to move it into the sockopt handlers you'll need
to somehow pass down "this is compat sockopt" down the
call chain.  Every time I've suggested to add a
"is_compat_task()" call Andi Kleen and friends shoot it down.

Don't get me started with do_netfilter_replace(), that area
needs a lot of work.  But it is true that each and every
piece of code needs to check the socket level too, the
sockopt numbers are only unique within a socket level

Comment 11 David Woodhouse 2004-09-03 18:10:38 UTC
is_compat_task() might be nice in the general case but in this
specific case we have optlen. Isn't that sufficient to tell which kind
of userspace we're dealing with -- at least in the cases where it

Comment 12 David Miller 2004-09-03 18:41:02 UTC
Not at all, there are cases where the structure size is
the same between 32-bit and 64-bit, but due to alignment
rules the actual layout is different.

You have to pass a flag down to the routines if you want
to do this.  See MSG_CMSG_COMPAT in net/*.c for an idea
about how we deal with this in other cases.

Comment 13 David Woodhouse 2004-09-08 08:30:39 UTC
Patch accepted upstream. Should propagate to our kernel soon.

Comment 14 David Woodhouse 2004-09-09 09:24:44 UTC
Hmm. MSG_CMSG_COMPAT seems to be required because that's not all
happening in the same process. But is_compat_task() should be trivial
to implement -- surely?

#define is_compat_task(tsk) (tsk->personality & PER_MASK == PER_LINUX32)

What was Andi's objection?

Comment 15 David Miller 2004-09-09 15:16:49 UTC
Just because you're PER_LINUX32 doesn't mean you can't
invoke the 64-bit system calls.

And likewise, a 64-bit native task could use one of the
32-bit system calls for some reason.

So compat'ness is an attribute of the code path we're in,
not the overall state of the process.

Frankly I think Andi's right.  And that's why you have to
pass flags around down into the call to implement stuff
like this.

Comment 16 Jay Turner 2005-01-14 09:46:13 UTC
Is everyone happy with how this ended up in the RHEL4 kernel?

Comment 17 Joe Orton 2005-01-14 10:48:21 UTC
Yes, this is fixed.

Note You need to log in before you can comment on or make changes to this bug.