[lkml]   [2009]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2] bonding: move IPv6 support into a separate kernel module
Vlad Yasevich <> wrote:

>Jay Vosburgh wrote:
>> Brian Haley <> wrote:
>>> David Miller wrote:
>>>> From: Jay Vosburgh <>
>>>> Date: Wed, 25 Feb 2009 14:10:58 -0800
>>>>> I've been fooling with the disable_ipv6 sysctl, and one issue is
>>>>> that, at least on the distro I'm testing on (SLES), it's not picked up
>>>>> from /etc/sysctl.conf at boot time (presumably because ipv6 isn't loaded
>>>>> yet, although I haven't really checked).
>>>> Correct, that's the problem.
>>>> We could create a blocker bitmap. Two sysctls, "block_af" and
>>>> "unblock_af". You write the AF_foo value for the protocol there and
>>>> it sets or clears the assosciated bit in the internal blocker bitmap.
>>>> Things like sys_socket() et al. key off of this.
>>> I'm open to suggestions at this point in time, I just don't see how this
>>> will solve the bonding problem since it still wouldn't load, right?
>> It would permit users to load ipv6 (thus allowing bonding to
>> load), but prevent ipv6 from actually doing anything. (because
>> sys_socket, e.g., won't open an ipv6 socket if block_af includes ipv6).
>> Actually, __sock_create might be the better place to put the
>> hook for "create a socket"; there would probably need to be a check
>> within the protocol code as well, so that, e.g., ipv6 addrconf won't run
>> if AF_INET6 is disabled.
>But addrconf_init doesn't care about AF_INET6 sockets...
>Additionally, why is it absolutely necessary to block AF_INET6 sockets.
>I never understood that requirement?

I don't know that it is, but it's the current behavior if ipv6
is prevented from loading.

>I can see people blocking IPv6 from loading because the module automatically
>configures IPv6 addresses and thus opens another communication channel that
>may not be monitored/controlled. AF_INET6 sockets, on the other hand, are
>simply relegated to IPv4 protocol, when there are no IPv6 addresses.

I believe that's only true if the ipv6 module is loaded. If
ipv6 is not loaded, then socket(AF_INET6, ...) returns failure with
EAFNOSUPPORT. If ipv6 is loaded, socket(AF_INET6, ...) succeeds
(apparently no matter if there are ipv6 addresses configured or not).

>>> Dave - do you feel I need to fix this regression? If not I can try to
>>> work on this AF blocker thing. My only other thought if we want to fix
>>> this is to have the IPv6 module register these five functions into an ops
>>> structure that bonding can call. It doesn't fix SCTP, qeth, etc, but it
>>> gets these "blacklist ipv6" configs working again, and gets me out of the
>>> crosshairs :)
>> I think the problem (customers want to disable ipv6 and use
>> bonding, sctp, qeth, whatever) needs to be fixed. If it's not, I'm sure
>> I'll be getting lots of cards and letters from customers.
>> I don't think the solution needs to preserve the current
>> solution (preventing the ipv6 module from loading). Ipv6 being unusable
>> should be sufficient. Except perhaps in an embedded environment, but
>> they're probably in a position to compile their kernel without ipv6.
>Yes. The system must not be reachable using IPv6.
>> Another possible resolution is to modify the initscripts in the
>> distros to perform sysctl -p (read sysctls from /etc/sysctl.conf) after
>> ipv6 is loaded, so that the disable_ipv6 sysctl can be set. That seems
>> like more work, and is limited to ipv6, so I don't see it as being
>> better than a "kernel shut off AF_xxx" type of solution.
>This not enough. You need to disable parts of IPv6 at module initiation
>time and the only way to do that is with a parameter. Otherwise, you will
>have a small window of time when the system has ipv6 configured and is potentially
>We can have our own sysfs parameter calls that can turn the functionality
>back on to get back to a fully functional ipv6 implementation.


-Jay Vosburgh, IBM Linux Technology Center,

 \ /
  Last update: 2009-02-26 20:51    [W:0.078 / U:7.132 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site