* [RFC] ethtool: Display reg dump length via get driver info.
From: Ajit Khaparde @ 2011-03-18 21:06 UTC (permalink / raw)
To: netdev; +Cc: bhutchings, ajit.khaparde
Devices like BE store Reg Dump Data in the hardware.
This change will allow to just peek into the hardware
to see if any data is available for a dump and analysis,
without actually dumping the register data.
Patch:
----
Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
---
ethtool.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index e9cb2c9..a0c7c99 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -1423,11 +1423,13 @@ static int dump_drvinfo(struct ethtool_drvinfo *info)
"driver: %s\n"
"version: %s\n"
"firmware-version: %s\n"
- "bus-info: %s\n",
+ "bus-info: %s\n"
+ "regdump-len: %d\n",
info->driver,
info->version,
info->fw_version,
- info->bus_info);
+ info->bus_info,
+ info->regdump_len);
return 0;
}
--
1.7.1
^ permalink raw reply related
* Re: [RFC] ethtool: Display reg dump length via get driver info.
From: Ben Hutchings @ 2011-03-18 21:32 UTC (permalink / raw)
To: Ajit Khaparde; +Cc: netdev
In-Reply-To: <ae232d9a-90c7-47ae-856d-bc5a2b3a8037@exht1.ad.emulex.com>
On Fri, 2011-03-18 at 16:06 -0500, Ajit Khaparde wrote:
> Devices like BE store Reg Dump Data in the hardware.
Where else would it be?
> This change will allow to just peek into the hardware
> to see if any data is available for a dump and analysis,
> without actually dumping the register data.
[...]
This is wrong. ethtool_ops::get_regs_len really should return a
constant, otherwise ethtool (and the kernel) cannot allocate a buffer of
the right size. If the size of a dump really does vary then make it
return the maximum possible size for the device.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: [RFC] ethtool: Display reg dump length via get driver info.
From: Ajit.Khaparde @ 2011-03-18 21:52 UTC (permalink / raw)
To: bhutchings; +Cc: netdev
In-Reply-To: <1300483939.2589.46.camel@bwh-desktop>
______________________________________
From: Ben Hutchings [bhutchings@solarflare.com]
Sent: Friday, March 18, 2011 4:32 PM
To: Khaparde, Ajit
Cc: netdev@vger.kernel.org
Subject: Re: [RFC] ethtool: Display reg dump length via get driver info.
On Fri, 2011-03-18 at 16:06 -0500, Ajit Khaparde wrote:
>> Devices like BE store Reg Dump Data in the hardware.
> Where else would it be?
Well yes. That's true.
>> This change will allow to just peek into the hardware
>> to see if any data is available for a dump and analysis,
>> without actually dumping the register data.
> [...]
> This is wrong. ethtool_ops::get_regs_len really should return a
> constant, otherwise ethtool (and the kernel) cannot allocate a buffer of
> the right size. If the size of a dump really does vary then make it
> return the maximum possible size for the device.
Yes, it is a constant size. And will always be the max size possible.
I just want to see if I can get the length, without really making the ethtoool -d call.
Because that will trigger the dump too.
At that moment, I may not be interested in the data itself.
-Ajit
> Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: [RFC] ethtool: Display reg dump length via get driver info.
From: Ben Hutchings @ 2011-03-18 22:00 UTC (permalink / raw)
To: Ajit.Khaparde; +Cc: netdev
In-Reply-To: <49395329523DD64492581B505F80C86D5A5BCD38EA@EXMAIL.ad.emulex.com>
On Fri, 2011-03-18 at 14:52 -0700, Ajit.Khaparde@Emulex.Com wrote:
> ______________________________________
> From: Ben Hutchings [bhutchings@solarflare.com]
> Sent: Friday, March 18, 2011 4:32 PM
> To: Khaparde, Ajit
> Cc: netdev@vger.kernel.org
> Subject: Re: [RFC] ethtool: Display reg dump length via get driver info.
>
> On Fri, 2011-03-18 at 16:06 -0500, Ajit Khaparde wrote:
> >> Devices like BE store Reg Dump Data in the hardware.
>
> > Where else would it be?
>
> Well yes. That's true.
>
> >> This change will allow to just peek into the hardware
> >> to see if any data is available for a dump and analysis,
> >> without actually dumping the register data.
> > [...]
>
> > This is wrong. ethtool_ops::get_regs_len really should return a
> > constant, otherwise ethtool (and the kernel) cannot allocate a buffer of
> > the right size. If the size of a dump really does vary then make it
> > return the maximum possible size for the device.
>
> Yes, it is a constant size. And will always be the max size possible.
> I just want to see if I can get the length, without really making the ethtoool -d call.
> Because that will trigger the dump too.
> At that moment, I may not be interested in the data itself.
OK, so what you're really interested in is 'does this version of the
driver support register dump'?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-dev2.6] bxn2x: Fix location of PCI-ids defines
From: David Miller @ 2011-03-18 22:13 UTC (permalink / raw)
To: eilong; +Cc: ariele, netdev
In-Reply-To: <1300367613.31873.0.camel@lb-tlvb-eilong.il.broadcom.com>
From: "Eilon Greenstein" <eilong@broadcom.com>
Date: Thu, 17 Mar 2011 15:13:33 +0200
> On Thu, 2011-03-17 at 06:06 -0700, David Miller wrote:
>> From: "Ariel Elior" <ariele@broadcom.com>
>> Date: Thu, 17 Mar 2011 14:27:04 +0200
>>
>> > Signed-off-by: Ariel Elior <ariele@broadcom.com>
>> > Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
>>
>> Unless you intend to reference these symbols elsewhere in the
>> kernel, they should stay private in your driver.
>>
>
> The bnx2i will need it as well. Isn't it better to keep all the PCI IDs
> in the same global location?
It looks like this change propagated to Linus via the scsi tree or
similar, so I don't need to apply it.
^ permalink raw reply
* Re: [PATCH v2] gianfar: Fall back to software tcp/udp checksum on older controllers
From: David Miller @ 2011-03-18 22:15 UTC (permalink / raw)
To: oakad; +Cc: linux-kernel, galak, cbouatmailru, mlcreech, linuxppc-dev, netdev
In-Reply-To: <598461.73809.qm@web37603.mail.mud.yahoo.com>
From: Alex Dubov <oakad@yahoo.com>
Date: Wed, 16 Mar 2011 20:57:13 -0700 (PDT)
> As specified by errata eTSEC49 of MPC8548 and errata eTSEC12 of MPC83xx,
> older revisions of gianfar controllers will be unable to calculate a TCP/UDP
> packet checksum for some alignments of the appropriate FCB. This patch checks
> for FCB alignment on such controllers and falls back to software checksumming
> if the alignment is known to be bad.
>
> Signed-off-by: Alex Dubov <oakad@yahoo.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ethtool: __ethtool_set_sg: check for function pointer before using it
From: David Miller @ 2011-03-18 22:15 UTC (permalink / raw)
To: bhutchings; +Cc: rl, mirq-linux, netdev
In-Reply-To: <1300380733.2569.3.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 17 Mar 2011 16:52:13 +0000
> On Thu, 2011-03-17 at 17:37 +0100, Roger Luethi wrote:
>> __ethtool_set_sg does not check if dev->ethtool_ops->set_sg is defined
>> which can result in a NULL pointer dereference when ethtool is used to
>> change SG settings for drivers without SG support.
>>
>> Signed-off-by: Roger Luethi <rl@hellgate.ch>
> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
Applied.
^ permalink raw reply
* Re: [PATCH] econet: 4 byte infoleak to the network
From: David Miller @ 2011-03-18 22:15 UTC (permalink / raw)
To: philb; +Cc: segoon, linux-kernel, security, eric.dumazet, tj, nelhage, netdev
In-Reply-To: <1300362601.2132.14721.camel@phil-desktop>
From: Phil Blundell <philb@gnu.org>
Date: Thu, 17 Mar 2011 11:50:01 +0000
> On Thu, 2011-03-17 at 14:40 +0300, Vasiliy Kulikov wrote:
>> struct aunhdr has 4 padding bytes between 'pad' and 'handle' fields on
>> x86_64. These bytes are not initialized in the variable 'ah' before
>> sending 'ah' to the network. This leads to 4 bytes kernel stack
>> infoleak.
>>
>> This bug was introduced before the git epoch.
>>
>> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
>
> Well spotted. Thanks for the patch.
>
> Acked-by: Phil Blundell <philb@gnu.org>
Applied.
^ permalink raw reply
* RE: [RFC] ethtool: Display reg dump length via get driver info.
From: Ajit.Khaparde @ 2011-03-18 22:07 UTC (permalink / raw)
To: bhutchings; +Cc: netdev
In-Reply-To: <1300485636.2589.48.camel@bwh-desktop>
________________________________________
From: Ben Hutchings [bhutchings@solarflare.com]
Sent: Friday, March 18, 2011 5:00 PM
To: Khaparde, Ajit
Cc: netdev@vger.kernel.org
Subject: RE: [RFC] ethtool: Display reg dump length via get driver info.
> On Fri, 2011-03-18 at 14:52 -0700, Ajit.Khaparde@Emulex.Com wrote:
>> ______________________________________
>> From: Ben Hutchings [bhutchings@solarflare.com]
>> Sent: Friday, March 18, 2011 4:32 PM
>> To: Khaparde, Ajit
>> Cc: netdev@vger.kernel.org
>> Subject: Re: [RFC] ethtool: Display reg dump length via get driver info.
>>
>> On Fri, 2011-03-18 at 16:06 -0500, Ajit Khaparde wrote:
>> >> Devices like BE store Reg Dump Data in the hardware.
>>
> >> Where else would it be?
>>
>> Well yes. That's true.
>>
>> >> This change will allow to just peek into the hardware
>> >> to see if any data is available for a dump and analysis,
>> >> without actually dumping the register data.
>> > [...]
>>
>> > This is wrong. ethtool_ops::get_regs_len really should return a
>> > constant, otherwise ethtool (and the kernel) cannot allocate a buffer of
>> > the right size. If the size of a dump really does vary then make it
>> > return the maximum possible size for the device.
>>
>> Yes, it is a constant size. And will always be the max size possible.
>> I just want to see if I can get the length, without really making the ethtoool -d call.
>> Because that will trigger the dump too.
>> At that moment, I may not be interested in the data itself.
> OK, so what you're really interested in is 'does this version of the
> driver support register dump'?
Yes. I did not want to add another option in ethtool to get this info out.
> Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: VLAN over GRE segfault
From: David Miller @ 2011-03-18 22:16 UTC (permalink / raw)
To: herbert; +Cc: eric.dumazet, diddi, netdev, kaber
In-Reply-To: <20110318192859.GA26156@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 18 Mar 2011 14:28:59 -0500
> On Fri, Mar 18, 2011 at 11:27:27AM +0100, Eric Dumazet wrote:
>>
>> This uncover a bug in vlan code.
>>
>> We should make sure vlan devices take into account their
>> real_dev->needed_headroom or we risk a crash in ipgre_header(), because
>> we dont have enough room to push IP header in skb.
>>
>> Reported-by: Diddi Oscarsson <diddi@diddi.se>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> Cc: Patrick McHardy <kaber@trash.net>
>> Cc: Herbert Xu <herbert@gondor.apana.org.au>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: [Bug 16572] random panics in bridging on 2.6.34+
From: David Miller @ 2011-03-18 22:17 UTC (permalink / raw)
To: shemminger; +Cc: herbert, netdev, bugzilla-daemon
In-Reply-To: <20110318090338.2f6dcb5d@nehalam>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Fri, 18 Mar 2011 09:03:38 -0700
> On Fri, 18 Mar 2011 10:27:28 -0500
> Herbert Xu <herbert@gondor.hengli.com.au> wrote:
>
>> On Fri, Mar 18, 2011 at 08:10:52AM -0700, Stephen Hemminger wrote:
>> > On Fri, 18 Mar 2011 13:49:03 GMT
>> > bugzilla-daemon@bugzilla.kernel.org wrote:
>> >
>> > > https://bugzilla.kernel.org/show_bug.cgi?id=16572
>> >
>> > Herbert hasn't submitted the patch upstream.
>>
>> Oops! Thanks for reminding me.
>>
>> bridge: Reset IPCB when entering IP stack on NF_FORWARD
>>
>> Whenever we enter the IP stack proper from bridge netfilter we
>> need to ensure that the skb is in a form the IP stack expects
>> it to be in.
>>
>> The entry point on NF_FORWARD did not meet the requirements of
>> the IP stack, therefore leading to potential crashes/panics.
>>
>> This patch fixes the problem.
>>
>> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH] headers: use __aligned_xx types for userspace
From: David Miller @ 2011-03-18 22:17 UTC (permalink / raw)
To: vapier; +Cc: akpm, linux-kernel, netdev
In-Reply-To: <1300474237-10980-1-git-send-email-vapier@gentoo.org>
From: Mike Frysinger <vapier@gentoo.org>
Date: Fri, 18 Mar 2011 14:50:37 -0400
> Now that we finally have __aligned_xx exported to userspace, convert
> the headers that get exported over to the proper type.
>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6] ethtool: Compat handling for struct ethtool_rxnfc
From: David Miller @ 2011-03-18 22:17 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: bhutchings, netdev, santwona.behera
In-Reply-To: <4D83BA36.8020301@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Fri, 18 Mar 2011 13:01:58 -0700
> On 3/17/2011 10:34 AM, Ben Hutchings wrote:
>> This structure was accidentally defined such that its layout can
>> differ between 32-bit and 64-bit processes. Add compat structure
>> definitions and an ioctl wrapper function.
>>
>> Signed-off-by: Ben Hutchings<bhutchings@solarflare.com>
>> Cc: stable@kernel.org [2.6.30+]
>> ---
>> David,
>>
>> I still haven't received any response on whether the
>> ETHTOOL_GRXCLSRLALL
>> wrapping works with a real driver, but perhaps you could test it
>> against
>> niu? I think sparc32 and sparc64 have the same alignment for u64 so
>> this wrapper isn't strictly necessary, but it would still be used.
>> (Or
>> we can arrange to disable the conversion when compat_ethtool_rxnfc is
>> equivalent to ethtool_rxnfc.)
>>
>> Ben.
>
> I've done a bit of testing this morning and verified GRXRINGS,
> GRCLSRLCNT, GRXCLSRULE, SRXCLSRLDEL, and SRXCLSRLINS all seem to be
> working for 32bit and 64bit ethtool user space on a x86_64 kernel with
> the patch. I also verified the original issue was present by running
> 32bit ethtool on a x86_64 kernel without the patch applied.
...
> Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>
Applied, thanks.
^ permalink raw reply
* [PATCH ethtool] ethtool: Report driver features described in struct ethtool_drvinfo
From: Ben Hutchings @ 2011-03-18 22:44 UTC (permalink / raw)
To: Ajit.Khaparde; +Cc: netdev
In-Reply-To: <49395329523DD64492581B505F80C86D5A5BCD38EB@EXMAIL.ad.emulex.com>
On Fri, 2011-03-18 at 15:07 -0700, Ajit.Khaparde@Emulex.Com wrote:
> ________________________________________
> From: Ben Hutchings [bhutchings@solarflare.com]
> Sent: Friday, March 18, 2011 5:00 PM
> To: Khaparde, Ajit
> Cc: netdev@vger.kernel.org
> Subject: RE: [RFC] ethtool: Display reg dump length via get driver info.
>
> > On Fri, 2011-03-18 at 14:52 -0700, Ajit.Khaparde@Emulex.Com wrote:
> >> ______________________________________
> >> From: Ben Hutchings [bhutchings@solarflare.com]
> >> Sent: Friday, March 18, 2011 4:32 PM
> >> To: Khaparde, Ajit
> >> Cc: netdev@vger.kernel.org
> >> Subject: Re: [RFC] ethtool: Display reg dump length via get driver info.
> >>
> >> On Fri, 2011-03-18 at 16:06 -0500, Ajit Khaparde wrote:
> >> >> Devices like BE store Reg Dump Data in the hardware.
> >>
> > >> Where else would it be?
> >>
> >> Well yes. That's true.
> >>
> >> >> This change will allow to just peek into the hardware
> >> >> to see if any data is available for a dump and analysis,
> >> >> without actually dumping the register data.
> >> > [...]
> >>
> >> > This is wrong. ethtool_ops::get_regs_len really should return a
> >> > constant, otherwise ethtool (and the kernel) cannot allocate a buffer of
> >> > the right size. If the size of a dump really does vary then make it
> >> > return the maximum possible size for the device.
> >>
> >> Yes, it is a constant size. And will always be the max size possible.
> >> I just want to see if I can get the length, without really making the ethtoool -d call.
> >> Because that will trigger the dump too.
> >> At that moment, I may not be interested in the data itself.
>
> > OK, so what you're really interested in is 'does this version of the
> > driver support register dump'?
>
> Yes. I did not want to add another option in ethtool to get this info out.
So, how about this?
Ben.
---
ETHTOOL_GDRVINFO fills out struct ethtool_drvinfo with the size of the
data returned by various other operations. The size should be non-zero
if and only if the driver implements that operation. Therefore, we can
report whether the driver supports certain operations without actually
trying them (which may be expensive and disruptive).
Do this in dump_drvinfo() rather than adding a separation operation.
---
ethtool.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index e9cb2c9..32df0ee 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -1423,11 +1423,19 @@ static int dump_drvinfo(struct ethtool_drvinfo *info)
"driver: %s\n"
"version: %s\n"
"firmware-version: %s\n"
- "bus-info: %s\n",
+ "bus-info: %s\n"
+ "supports-statistics: %s\n"
+ "supports-test: %s\n"
+ "supports-eeprom-access: %s\n"
+ "supports-register-dump: %s\n",
info->driver,
info->version,
info->fw_version,
- info->bus_info);
+ info->bus_info,
+ info->n_stats ? "yes" : "no",
+ info->testinfo_len ? "yes" : "no",
+ info->eedump_len ? "yes" : "no",
+ info->regdump_len ? "yes" : "no");
return 0;
}
---
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: Stale entries in RT_TABLE_LOCAL
From: Julian Anastasov @ 2011-03-18 22:57 UTC (permalink / raw)
To: Jiri Bohac; +Cc: Alex Sidorenko, David Miller, netdev@vger.kernel.org
In-Reply-To: <20110317161129.GA6384@midget.suse.cz>
Hello,
On Thu, 17 Mar 2011, Jiri Bohac wrote:
>>>> IP2: 192.168.142.109/23, primary
>>>> IP3: 192.168.142.109/22, secondary for primary IP1
>>>>
>>>> It is the route for IP3 that is leaked, with prefsrc=IP1.
>>>> We create local route for secondary IPs with prefsrc=ItsPrimaryIP.
>>>> Both local routes for 109 differ in prefsrc (fa_info)
>
> Is there any reason to set the prefsrc of a local route to the
> primary IP address of the subnet?
>
> I tried the following patch:
>
> diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
> index 1d2cdd4..2046b21 100644
> --- a/net/ipv4/fib_frontend.c
> +++ b/net/ipv4/fib_frontend.c
> @@ -751,7 +751,7 @@ void fib_add_ifaddr(struct in_ifaddr *ifa)
> }
> }
>
> - fib_magic(RTM_NEWROUTE, RTN_LOCAL, addr, 32, prim);
> + fib_magic(RTM_NEWROUTE, RTN_LOCAL, addr, 32, ifa);
>
> if (!(dev->flags & IFF_UP))
> return;
>
>
> The result with the teststcase mentioned previously is that only
> one local route is created per IP address. The local routes are
> correctly deleted after both identical IP addresses are removed
> from the interface.
It is a problem also for the broadcast addresses.
> Furthemore, the testcase uncovers another weirdness with the
> prefsrc of the local routes. When a primary IP address is deleted
> and a secondary IP address is promoted to primary, its prefsrc is
> not updated.
Yes, I see the same when the deleted primary is
also in another subnet or device.
> What is the prefrc of a local route good for?
To prefer this src when talking to local IP :)
You can always add local IPs with /32 mask but currently
you must add it first, i.e. fib_magic does not remove
the NLM_F_APPEND flag for /32 local routes when dst is
same as ifa->ifa_local. So, the order of IP adding
will determine the order of local routes:
ip addr add 1.2.3.4/24 brd + dev eth1
# secondary
ip addr add 1.2.3.5/24 brd + dev eth1
# primary:
ip addr add 1.2.3.5/32 brd + dev eth1
when talking to 1.2.3.5 you will use 1.2.3.4 because
the secondary is added first.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [PATCH 0/4] ipv4: fix problems with same IPs in many subnets
From: Julian Anastasov @ 2011-03-18 23:12 UTC (permalink / raw)
To: netdev; +Cc: David Miller
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4554 bytes --]
Here are some changes for the IPv4 addresses and
the routes we delete for setups using same primary or
secondary IPs in many subnets on device. They are made for
net-next from March 13.
Attached is a test script that tests the kernel
for the observed problems and validates some operations.
The same script should be available here:
http://www.ssi.bg/~ja/test_ipdel.sh
Can be run before and after patching to compare results.
Usage:
# Tune script: device, etc
# Run test with generating sorted listings, useful for diff -u
./test_ipdel.sh list > out1
# Run test with brief output
./test_ipdel.sh
As there some questions on using same IPs in
different subnets, here is some info and the current
problems I'm seeing.
__inet_insert_ifa() considers IPs as secondary when
they use same prefixlen (mask) as existing primary IP. So, it is
perfectly valid for some device:
- to have two primary IFAs for same IP "P1" but with different
masks "M1" and "M2", probably with different scope (visibility
for the defined subnet):
IFA1: P1/M1
IFA2: P1/M2
- when adding secondary IPs the same rule applies:
IFA3: S1/M1, can use primary P1 from IFA1
IFA4: S1/M2, can use primary P1 from IFA2
inet_ifa_byprefix() can correctly match IFA1 or IFA2
by address (P1) and mask (M1 or M2).
To summarize for IPs: the combination of device, IP address
and prefixlen (mask) should be unique. Same IPs can be used
in many overlapping subnets. The IPs for device are always
saved in sorted form: all primaries before all secondaries, the
primaries are sorted by decreasing scope, primaries with
same scope are in order of adding, the secondaries are in
random (adding) order but with same scope as their primary.
When addresses are converted to local or
broadcast routes we have:
- All routes are added with prefsrc. The prefsrc is the primary
address. As the combination of local IP and its primary address
is unique only for its subnet if we use the same IPs in another
subnet it is possible to try to add the same routes twice
resulting in duplication. But only one route is created in such case
and on deletion we should be careful not to delete routes that
are also required for the same IPs in different subnet.
- When creating local or broadcast route for the added address we
ignore the prefixlen. As result, the combination of address
(FIB node=IP/32), primary IP (fib_prefsrc) and device (fib_info, NH)
should be unique. The above IFA1 and IFA2 will try to create same
local route:
local P1/32 via dev DEV ... src P1
and the result will be single route.
IFA3 and IFA4 will add single route too:
local S1/32 via dev DEV ... src P1
When addresses are deleted we should remove exactly the
routes that were created for our IFA but with checks for
duplication in another subnet.
The problems in current code:
- fib_del_ifaddr() unconditionally tries to remove the subnet
route when deleting primary IFA. The problem is that if
prefixlen is 32 we need more checks, eg. if this IP is
still used in another subnet.
- fib_del_ifaddr() forgets to match the primary address for
every IFA that is checked. As result, routes for deleted
secondary IFAs can remain until their primary IFA is deleted
just because the same address is used in another subnet
but with different primary IP.
- fib_table_delete() does not match the prefsrc, so if there
are many routes that differ in prefsrc, always the first
route is deleted. By this way, we can not remove the right
route for the deleted IFAs.
- On secondary address promotion, when deleting the primary
address all routes with such prefsrc are currently expected to
be deleted by fib_sync_down_addr without sending events for
the remaining secondaries. But as fib_sync_down_addr calling
depends on other subnets and even on other devices we can leak
the routes.
The following patches fix the above problems.
I don't try to forbid same IPs to be used in multiple
subnets because it is perfectly valid subnets to overlap.
As patch 2 needs to know the primary IP (but not its IFA)
for every secondary address, another implementation is possible
where new field ifa_primary can cache the primary IP used
for the IFA. Then we will avoid the inet_ifa_byprefix calls
when we walk secondaries from different subnets.
For now I'm using a 'same_prefsrc' flag that detects if
multiple subnets use same primary IP, so such lookups are
avoided later for the secondaries for the common case when
same IPs are not used in more than one subnet.
Regards
--
Julian Anastasov <ja@ssi.bg>
[-- Attachment #2: test_ipdel.sh --]
[-- Type: APPLICATION/x-sh, Size: 3655 bytes --]
^ permalink raw reply
* [PATCH 1/4] ipv4: match prefsrc when deleting routes
From: Julian Anastasov @ 2011-03-18 23:13 UTC (permalink / raw)
To: netdev; +Cc: David Miller
fib_table_delete forgets to match the routes by prefsrc.
Callers can specify known IP in fc_prefsrc and we should remove
the exact route. This is needed for cases when same local or
broadcast addresses are used in different subnets and the
routes differ only in prefsrc. All callers that do not provide
fc_prefsrc will ignore the route prefsrc as before and will
delete the first occurence. That is how the ip route del default
magic works.
Current callers are:
- ip_rt_ioctl where rtentry_to_fib_config provides fc_prefsrc only
when the provided device name matches IP label with colon.
- inet_rtm_delroute where RTA_PREFSRC is optional too
- fib_magic which deals with routes when deleting addresses
and where the fc_prefsrc is always set with the primary IP
for the concerned IFA.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
diff -urp net-next-2.6-bef55ae/linux/net/ipv4/fib_trie.c linux/net/ipv4/fib_trie.c
--- net-next-2.6-bef55ae/linux/net/ipv4/fib_trie.c 2011-03-13 01:08:55.000000000 +0200
+++ linux/net/ipv4/fib_trie.c 2011-03-16 09:53:26.824191983 +0200
@@ -1665,6 +1665,8 @@ int fib_table_delete(struct fib_table *t
if ((!cfg->fc_type || fa->fa_type == cfg->fc_type) &&
(cfg->fc_scope == RT_SCOPE_NOWHERE ||
fa->fa_scope == cfg->fc_scope) &&
+ (!cfg->fc_prefsrc ||
+ fi->fib_prefsrc == cfg->fc_prefsrc) &&
(!cfg->fc_protocol ||
fi->fib_protocol == cfg->fc_protocol) &&
fib_nh_match(cfg, fi) == 0) {
^ permalink raw reply
* [PATCH 2/4] ipv4: fix route deletion for IPs on many subnets
From: Julian Anastasov @ 2011-03-18 23:17 UTC (permalink / raw)
To: netdev; +Cc: David Miller
Alex Sidorenko reported for problems with local
routes left after IP addresses are deleted. It happens
when same IPs are used in more than one subnet for the
device.
Fix fib_del_ifaddr to restrict the checks for duplicate
local and broadcast addresses only to the IFAs that use
our primary IFA or another primary IFA with same address.
And we expect the prefsrc to be matched when the routes
are deleted because it is possible they to differ only by
prefsrc. This patch prevents local and broadcast routes
to be leaked until their primary IP is deleted finally
from the box.
As the secondary address promotion needs to delete
the routes for all secondaries that used the old primary IFA,
add option to ignore these secondaries from the checks and
to assume they are already deleted, so that we can safely
delete the route while these IFAs are still on the device list.
Reported-by: Alex Sidorenko <alexandre.sidorenko@hp.com>
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
diff -urp net-next-2.6-bef55ae/linux/include/net/route.h linux/include/net/route.h
--- net-next-2.6-bef55ae/linux/include/net/route.h 2011-03-13 01:08:55.000000000 +0200
+++ linux/include/net/route.h 2011-03-16 03:08:36.135967550 +0200
@@ -207,6 +207,7 @@ extern int ip_rt_dump(struct sk_buff *s
struct in_ifaddr;
extern void fib_add_ifaddr(struct in_ifaddr *);
+extern void fib_del_ifaddr(struct in_ifaddr *, struct in_ifaddr *);
static inline void ip_rt_put(struct rtable * rt)
{
diff -urp net-next-2.6-bef55ae/linux/net/ipv4/fib_frontend.c linux/net/ipv4/fib_frontend.c
--- net-next-2.6-bef55ae/linux/net/ipv4/fib_frontend.c 2011-03-13 01:08:55.000000000 +0200
+++ linux/net/ipv4/fib_frontend.c 2011-03-16 03:32:13.816970273 +0200
@@ -722,12 +722,17 @@ void fib_add_ifaddr(struct in_ifaddr *if
}
}
-static void fib_del_ifaddr(struct in_ifaddr *ifa)
+/* Delete primary or secondary address.
+ * Optionally, on secondary address promotion consider the addresses
+ * from subnet iprim as deleted, even if they are in device list.
+ * In this case the secondary ifa can be in device list.
+ */
+void fib_del_ifaddr(struct in_ifaddr *ifa, struct in_ifaddr *iprim)
{
struct in_device *in_dev = ifa->ifa_dev;
struct net_device *dev = in_dev->dev;
struct in_ifaddr *ifa1;
- struct in_ifaddr *prim = ifa;
+ struct in_ifaddr *prim = ifa, *prim1 = NULL;
__be32 brd = ifa->ifa_address | ~ifa->ifa_mask;
__be32 any = ifa->ifa_address & ifa->ifa_mask;
#define LOCAL_OK 1
@@ -735,17 +740,26 @@ static void fib_del_ifaddr(struct in_ifa
#define BRD0_OK 4
#define BRD1_OK 8
unsigned ok = 0;
+ int subnet = 0; /* Primary network */
+ int gone = 1; /* Address is missing */
+ int same_prefsrc = 0; /* Another primary with same IP */
- if (!(ifa->ifa_flags & IFA_F_SECONDARY))
- fib_magic(RTM_DELROUTE,
- dev->flags & IFF_LOOPBACK ? RTN_LOCAL : RTN_UNICAST,
- any, ifa->ifa_prefixlen, prim);
- else {
+ if (ifa->ifa_flags & IFA_F_SECONDARY) {
prim = inet_ifa_byprefix(in_dev, any, ifa->ifa_mask);
if (prim == NULL) {
printk(KERN_WARNING "fib_del_ifaddr: bug: prim == NULL\n");
return;
}
+ if (iprim && iprim != prim) {
+ printk(KERN_WARNING "fib_del_ifaddr: bug: iprim != prim\n");
+ return;
+ }
+ } else if (!ipv4_is_zeronet(any) &&
+ (any != ifa->ifa_local || ifa->ifa_prefixlen < 32)) {
+ fib_magic(RTM_DELROUTE,
+ dev->flags & IFF_LOOPBACK ? RTN_LOCAL : RTN_UNICAST,
+ any, ifa->ifa_prefixlen, prim);
+ subnet = 1;
}
/* Deletion is more complicated than add.
@@ -755,6 +769,49 @@ static void fib_del_ifaddr(struct in_ifa
*/
for (ifa1 = in_dev->ifa_list; ifa1; ifa1 = ifa1->ifa_next) {
+ if (ifa1 == ifa) {
+ /* promotion, keep the IP */
+ gone = 0;
+ continue;
+ }
+ /* Ignore IFAs from our subnet */
+ if (iprim && ifa1->ifa_mask == iprim->ifa_mask &&
+ inet_ifa_match(ifa1->ifa_address, iprim))
+ continue;
+
+ /* Ignore ifa1 if it uses different primary IP (prefsrc) */
+ if (ifa1->ifa_flags & IFA_F_SECONDARY) {
+ /* Another address from our subnet? */
+ if (ifa1->ifa_mask == prim->ifa_mask &&
+ inet_ifa_match(ifa1->ifa_address, prim))
+ prim1 = prim;
+ else {
+ /* We reached the secondaries, so
+ * same_prefsrc should be determined.
+ */
+ if (!same_prefsrc)
+ continue;
+ /* Search new prim1 if ifa1 is not
+ * using the current prim1
+ */
+ if (!prim1 ||
+ ifa1->ifa_mask != prim1->ifa_mask ||
+ !inet_ifa_match(ifa1->ifa_address, prim1))
+ prim1 = inet_ifa_byprefix(in_dev,
+ ifa1->ifa_address,
+ ifa1->ifa_mask);
+ if (!prim1)
+ continue;
+ if (prim1->ifa_local != prim->ifa_local)
+ continue;
+ }
+ } else {
+ if (prim->ifa_local != ifa1->ifa_local)
+ continue;
+ prim1 = ifa1;
+ if (prim != prim1)
+ same_prefsrc = 1;
+ }
if (ifa->ifa_local == ifa1->ifa_local)
ok |= LOCAL_OK;
if (ifa->ifa_broadcast == ifa1->ifa_broadcast)
@@ -763,19 +820,37 @@ static void fib_del_ifaddr(struct in_ifa
ok |= BRD1_OK;
if (any == ifa1->ifa_broadcast)
ok |= BRD0_OK;
+ /* primary has network specific broadcasts */
+ if (prim1 == ifa1 && ifa1->ifa_prefixlen < 31) {
+ __be32 brd1 = ifa1->ifa_address | ~ifa1->ifa_mask;
+ __be32 any1 = ifa1->ifa_address & ifa1->ifa_mask;
+
+ if (!ipv4_is_zeronet(any1)) {
+ if (ifa->ifa_broadcast == brd1 ||
+ ifa->ifa_broadcast == any1)
+ ok |= BRD_OK;
+ if (brd == brd1 || brd == any1)
+ ok |= BRD1_OK;
+ if (any == brd1 || any == any1)
+ ok |= BRD0_OK;
+ }
+ }
}
if (!(ok & BRD_OK))
fib_magic(RTM_DELROUTE, RTN_BROADCAST, ifa->ifa_broadcast, 32, prim);
- if (!(ok & BRD1_OK))
- fib_magic(RTM_DELROUTE, RTN_BROADCAST, brd, 32, prim);
- if (!(ok & BRD0_OK))
- fib_magic(RTM_DELROUTE, RTN_BROADCAST, any, 32, prim);
+ if (subnet && ifa->ifa_prefixlen < 31) {
+ if (!(ok & BRD1_OK))
+ fib_magic(RTM_DELROUTE, RTN_BROADCAST, brd, 32, prim);
+ if (!(ok & BRD0_OK))
+ fib_magic(RTM_DELROUTE, RTN_BROADCAST, any, 32, prim);
+ }
if (!(ok & LOCAL_OK)) {
fib_magic(RTM_DELROUTE, RTN_LOCAL, ifa->ifa_local, 32, prim);
/* Check, that this local address finally disappeared. */
- if (inet_addr_type(dev_net(dev), ifa->ifa_local) != RTN_LOCAL) {
+ if (gone &&
+ inet_addr_type(dev_net(dev), ifa->ifa_local) != RTN_LOCAL) {
/* And the last, but not the least thing.
* We must flush stray FIB entries.
*
@@ -896,7 +971,7 @@ static int fib_inetaddr_event(struct not
rt_cache_flush(dev_net(dev), -1);
break;
case NETDEV_DOWN:
- fib_del_ifaddr(ifa);
+ fib_del_ifaddr(ifa, NULL);
fib_update_nh_saddrs(dev);
if (ifa->ifa_dev->ifa_list == NULL) {
/* Last address was deleted from this interface.
^ permalink raw reply
* ipv6 secondary ips and default ipv6 ip for new outbound connections
From: Jim Westfall @ 2011-03-18 23:03 UTC (permalink / raw)
To: netdev
Hi
On ipv4 the first ip added to a nic will be used as the source ip for
new outbound connections. Any additional ips, in the same netblock,
will be added as secondaries.
ipv6 seems to have the opposite behavior. The last ipv6 ip added to a
nic is be used for new outbound connections.
~# ip -6 addr list br0
11: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500
inet6 fe80::21a:64ff:fe12:54bd/64 scope link
valid_lft forever preferred_lft forever
~# ip addr add 2600:c00:0:1::1101/64 dev br0
~# traceroute6 www.kame.net | head -0
traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1101, 30 hops max, 16 byte packets
~# ip addr add 2600:c00:0:1::1102/64 dev br0
~# traceroute6 www.kame.net | head -0
traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1102, 30 hops max, 16 byte packets
~# ip -6 addr list br0
11: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500
inet6 2600:c00:0:1::1102/64 scope global
valid_lft forever preferred_lft forever
inet6 2600:c00:0:1::1101/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::21a:64ff:fe12:54bd/64 scope link
valid_lft forever preferred_lft forever
This makes things a bit of a pita when dealing with floater ipv6 ips for
HA.
This there some way to change this behavior to be like ipv4 or force
a specific ipv6 ip to be the default used for new outbound connections?
thanks
Jim Westfall
^ permalink raw reply
* [PATCH 3/4] ipv4: remove the routes on secondary promotion
From: Julian Anastasov @ 2011-03-18 23:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller
The secondary address promotion relies on fib_sync_down_addr
to remove all routes created for the secondary addresses when
the old primary address is deleted. It does not happen for cases
when the primary address is also in another subnet. Fix that
by deleting local and broadcast routes for all secondaries while
they are on device list and by faking that all addresses from
this subnet are to be deleted. It relies on fib_del_ifaddr being
able to ignore the IPs from the concerned subnet while checking
for duplication.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
diff -urp net-next-2.6-bef55ae/linux/net/ipv4/devinet.c linux/net/ipv4/devinet.c
--- net-next-2.6-bef55ae/linux/net/ipv4/devinet.c 2011-03-13 01:08:55.000000000 +0200
+++ linux/net/ipv4/devinet.c 2011-03-16 10:54:42.669192601 +0200
@@ -345,6 +345,17 @@ static void __inet_del_ifa(struct in_dev
}
}
+ /* On promotion all secondaries from subnet are changing
+ * the primary IP, we must remove all their routes silently
+ * and later to add them back with new prefsrc. Do this
+ * while all addresses are on the device list.
+ */
+ for (ifa = promote; ifa; ifa = ifa->ifa_next) {
+ if (ifa1->ifa_mask == ifa->ifa_mask &&
+ inet_ifa_match(ifa1->ifa_address, ifa))
+ fib_del_ifaddr(ifa, ifa1);
+ }
+
/* 2. Unlink it */
*ifap = ifa1->ifa_next;
^ permalink raw reply
* [PATCH 4/4] ipv4: optimize route adding on secondary promotion
From: Julian Anastasov @ 2011-03-18 23:21 UTC (permalink / raw)
To: netdev; +Cc: David Miller
Optimize the calling of fib_add_ifaddr for all
secondary addresses after the promoted one to start from
their place, not from the new place of the promoted
secondary. It will save some CPU cycles because we
are sure the promoted secondary was first for the subnet
and all next secondaries do not change their place.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
diff -urp net-next-2.6-bef55ae/linux/net/ipv4/devinet.c linux/net/ipv4/devinet.c
--- net-next-2.6-bef55ae/linux/net/ipv4/devinet.c 2011-03-18 00:57:39.000000000 +0200
+++ linux/net/ipv4/devinet.c 2011-03-18 10:40:08.135271482 +0200
@@ -375,6 +375,7 @@ static void __inet_del_ifa(struct in_dev
blocking_notifier_call_chain(&inetaddr_chain, NETDEV_DOWN, ifa1);
if (promote) {
+ struct in_ifaddr *next_sec = promote->ifa_next;
if (prev_prom) {
prev_prom->ifa_next = promote->ifa_next;
@@ -386,7 +387,7 @@ static void __inet_del_ifa(struct in_dev
rtmsg_ifa(RTM_NEWADDR, promote, nlh, pid);
blocking_notifier_call_chain(&inetaddr_chain,
NETDEV_UP, promote);
- for (ifa = promote->ifa_next; ifa; ifa = ifa->ifa_next) {
+ for (ifa = next_sec; ifa; ifa = ifa->ifa_next) {
if (ifa1->ifa_mask != ifa->ifa_mask ||
!inet_ifa_match(ifa1->ifa_address, ifa))
continue;
^ permalink raw reply
* Re: [PATCH] headers: use __aligned_xx types for userspace
From: Andrew Morton @ 2011-03-18 23:28 UTC (permalink / raw)
To: Mike Frysinger; +Cc: linux-kernel, netdev, David S. Miller
In-Reply-To: <1300474237-10980-1-git-send-email-vapier@gentoo.org>
On Fri, 18 Mar 2011 14:50:37 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> Now that we finally have __aligned_xx exported to userspace, convert
> the headers that get exported over to the proper type.
>
Sob. Please don't assume that because you're on top of an issue, all
the rest of us are.
A bit of git-log grovelling turns up
: commit 79b5dc0c64d88cda3da23b2e22a5cec0964372ac
: Author: Eric Paris <eparis@redhat.com>
: Date: Fri Oct 15 14:34:14 2010 -0700
: types.h: define __aligned_u64 and expose to userspace
:
: We currently have a kernel internal type called aligned_u64 which aligns
: __u64's on 8 bytes boundaries even on systems which would normally align
: them on 4 byte boundaries. This patch creates a new type __aligned_u64
: which does the same thing but which is exposed to userspace rather than
: being kernel internal.
but that really doesn't tell us why it was merged either. Perhaps that
came out in the followup discussion and I failed to fix the changelog.
Still, it doesn't hurt to educate people. Please explain why we are
making this change?
> include/linux/if_ppp.h | 16 ++++++++--------
> include/linux/netfilter/nfnetlink_log.h | 4 ++--
> include/linux/netfilter/nfnetlink_queue.h | 4 ++--
> include/linux/netfilter/xt_connbytes.h | 4 ++--
> include/linux/netfilter/xt_quota.h | 2 +-
> 5 files changed, 15 insertions(+), 15 deletions(-)
davem stuff :)
^ permalink raw reply
* Re: [PATCH] headers: use __aligned_xx types for userspace
From: David Miller @ 2011-03-18 23:29 UTC (permalink / raw)
To: akpm; +Cc: vapier, linux-kernel, netdev
In-Reply-To: <20110318162826.5295f130.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Fri, 18 Mar 2011 16:28:26 -0700
> davem stuff :)
Already applied hours ago.
^ permalink raw reply
* Re: [PATCH 2/2] virtio_net: remove send completion interrupts and avoid TX queue overrun through packet drop
From: Shirley Ma @ 2011-03-19 1:41 UTC (permalink / raw)
To: Herbert Xu; +Cc: mst, rusty, davem, kvm, netdev
In-Reply-To: <20110318133311.GA20623@gondor.apana.org.au>
On Fri, 2011-03-18 at 08:33 -0500, Herbert Xu wrote:
> Shirley Ma <mashirle@us.ibm.com> wrote:
> >
> > + /* Drop packet instead of stop queue for better performance
> */
>
> I would like to see some justification as to why this is the right
> way to go and not just papering over the real problem.
Fair. KVM guest virtio_net TX queue stop/restart is pretty expensive,
which involves:
1. Guest enable callback: one memory barrier, interrupt flag set
2. Host signals guest: one memory barrier, and a TX interrupt from host
to KVM guest through evenfd_signal.
Most of the workload so far we barely see TX over run, except for small
messages TCP_STREAM.
For small message size TCP_STREAM workload, no matter how big the TX
queue size is, it always causes overrun. I even re-enable the TX queue
when it's empty, it still hits TX overrun again and again.
Somehow KVM guest and host is not in pace on processing small packets. I
tried to pin each thread to different CPU, it didn't help. So it didn't
seem to be scheduling related.
>From the performance results, we can see dramatically performance gain
with this patch.
I would like to dig out the real reason why host can't in pace with
guest, but haven't figured it out in month, that's the reason I held
this patch for a while. However if anyone can give me any ideas on how
to debug the real problem, I am willing to try it out.
Thanks
Shirley
^ permalink raw reply
* Re: ipv6 secondary ips and default ipv6 ip for new outbound connections
From: Brian Haley @ 2011-03-19 2:23 UTC (permalink / raw)
To: Jim Westfall; +Cc: netdev
In-Reply-To: <20110318230312.GX13831@surrealistic.net>
On 03/18/2011 07:03 PM, Jim Westfall wrote:
> Hi
>
> On ipv4 the first ip added to a nic will be used as the source ip for
> new outbound connections. Any additional ips, in the same netblock,
> will be added as secondaries.
>
> ipv6 seems to have the opposite behavior. The last ipv6 ip added to a
> nic is be used for new outbound connections.
>
> ~# ip -6 addr list br0
> 11: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500
> inet6 fe80::21a:64ff:fe12:54bd/64 scope link
> valid_lft forever preferred_lft forever
>
> ~# ip addr add 2600:c00:0:1::1101/64 dev br0
> ~# traceroute6 www.kame.net | head -0
> traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1101, 30 hops max, 16 byte packets
>
> ~# ip addr add 2600:c00:0:1::1102/64 dev br0
> ~# traceroute6 www.kame.net | head -0
> traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1102, 30 hops max, 16 byte packets
>
> ~# ip -6 addr list br0
> 11: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500
> inet6 2600:c00:0:1::1102/64 scope global
> valid_lft forever preferred_lft forever
> inet6 2600:c00:0:1::1101/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::21a:64ff:fe12:54bd/64 scope link
> valid_lft forever preferred_lft forever
>
> This makes things a bit of a pita when dealing with floater ipv6 ips for
> HA.
>
> This there some way to change this behavior to be like ipv4 or force
> a specific ipv6 ip to be the default used for new outbound connections?
According to commit 8a6ce0c083f5736e90dabe6d8ce077e7dd0fa35f it's done this
way for backward-compatibility - we used to always put new addresses at the
front, then we started sorting them by scope. I couldn't find in the archives
who needed the backward-compatible behavior (it was way back in 2006), but
Yoshifuji proposed it and I Acked it.
You could see if this patch helps you out, but I'm not sure if changing this
would break someone else, you'd have to see about putting a knob to control
this.
-Brian
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 3daaf3c..8c7d5a5 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -577,7 +577,7 @@ ipv6_link_dev_addr(struct inet6_dev *idev, struct inet6_ifaddr *ifp)
list_for_each(p, &idev->addr_list) {
struct inet6_ifaddr *ifa
= list_entry(p, struct inet6_ifaddr, if_list);
- if (ifp_scope >= ipv6_addr_src_scope(&ifa->addr))
+ if (ifp_scope > ipv6_addr_src_scope(&ifa->addr))
break;
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox