* Re: [PATCH] net: ipv4: add IPPROTO_ICMP socket kind
From: Vasiliy Kulikov @ 2011-03-18 19:59 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, netdev, peak, solar, kees.cook, dan.j.rosenberg,
eugene, nelhage, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20110318.124711.116396341.davem@davemloft.net>
On Fri, Mar 18, 2011 at 12:47 -0700, David Miller wrote:
> I kindly asked the other day for people to not submit new feature
> patches while we are amidst the merge window:
Sorry, I should have grepped the archives before sending the patch
(I'm not a subscriber of netdev@). I'll wait for .39-rc1.
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* Re: [PATCH net-2.6] ethtool: Compat handling for struct ethtool_rxnfc
From: Alexander Duyck @ 2011-03-18 20:01 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev@vger.kernel.org, Santwona Behera
In-Reply-To: <1300383272.2569.13.camel@bwh-desktop>
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.
In order to support flow extensions there will end up being a couple of
minor changes needed to the patch but I will just make sure to add them
when flow extensions are added.
Thanks,
Alex
Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>
^ permalink raw reply
* Re: [PATCH 20/36] net,rcu: convert call_rcu(netlbl_unlhsh_free_addr4) to kfree_rcu()
From: Paul Moore @ 2011-03-18 20:05 UTC (permalink / raw)
To: David Miller; +Cc: laijs, paulmck, mingo, netdev, linux-kernel
In-Reply-To: <20110318.123651.245394297.davem@davemloft.net>
On Friday, March 18, 2011 3:36:51 PM David Miller wrote:
> From: Lai Jiangshan <laijs@cn.fujitsu.com>
> Date: Fri, 18 Mar 2011 12:03:56 +0800
>
> > The rcu callback netlbl_unlhsh_free_addr4() just calls a kfree(),
> > so we use kfree_rcu() instead of the call_rcu(netlbl_unlhsh_free_addr4).
> >
> > Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
>
> Acked-by: David S. Miller <davem@davemloft.net>
Me too ...
Acked-by: Paul Moore <paul.moore@hp.com>
--
paul moore
linux @ hp
^ permalink raw reply
* Re: [PATCH 21/36] net,rcu: convert call_rcu(netlbl_unlhsh_free_addr6) to kfree_rcu()
From: Paul Moore @ 2011-03-18 20:06 UTC (permalink / raw)
To: Lai Jiangshan
Cc: Paul E. McKenney, Ingo Molnar, David S. Miller, netdev,
linux-kernel
In-Reply-To: <4D82D9E2.4000408@cn.fujitsu.com>
On Friday, March 18, 2011 12:04:50 AM Lai Jiangshan wrote:
> The rcu callback netlbl_unlhsh_free_addr6() just calls a kfree(),
> so we use kfree_rcu() instead of the call_rcu(netlbl_unlhsh_free_addr6).
>
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Acked-by: Paul Moore <paul.moore@hp.com>
> ---
> net/netlabel/netlabel_unlabeled.c | 22 +---------------------
> 1 files changed, 1 insertions(+), 21 deletions(-)
>
> diff --git a/net/netlabel/netlabel_unlabeled.c
> b/net/netlabel/netlabel_unlabeled.c index 4e5ad90..9c38658 100644
> --- a/net/netlabel/netlabel_unlabeled.c
> +++ b/net/netlabel/netlabel_unlabeled.c
> @@ -153,26 +153,6 @@ static const struct nla_policy
> netlbl_unlabel_genl_policy[NLBL_UNLABEL_A_MAX + 1 * Unlabeled Connection
> Hash Table Functions
> */
>
> -#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> -/**
> - * netlbl_unlhsh_free_addr6 - Frees an IPv6 address entry from the hash
> table - * @entry: the entry's RCU field
> - *
> - * Description:
> - * This function is designed to be used as a callback to the call_rcu()
> - * function so that memory allocated to a hash table address entry can be
> - * released safely.
> - *
> - */
> -static void netlbl_unlhsh_free_addr6(struct rcu_head *entry)
> -{
> - struct netlbl_unlhsh_addr6 *ptr;
> -
> - ptr = container_of(entry, struct netlbl_unlhsh_addr6, rcu);
> - kfree(ptr);
> -}
> -#endif /* IPv6 */
> -
> /**
> * netlbl_unlhsh_free_iface - Frees an interface entry from the hash table
> * @entry: the entry's RCU field
> @@ -611,7 +591,7 @@ static int netlbl_unlhsh_remove_addr6(struct net *net,
> if (entry == NULL)
> return -ENOENT;
>
> - call_rcu(&entry->rcu, netlbl_unlhsh_free_addr6);
> + kfree_rcu(entry, rcu);
> return 0;
> }
> #endif /* IPv6 */
--
paul moore
linux @ hp
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/6] be2net: fix to not drop unfiltered vlan pkts
From: Jesse Gross @ 2011-03-18 20:35 UTC (permalink / raw)
To: Sathya Perla; +Cc: netdev
In-Reply-To: <e340379d-68e1-42af-b7b7-94e07e729884@exht1.ad.emulex.com>
On Fri, Mar 18, 2011 at 6:20 AM, Sathya Perla <sathya.perla@emulex.com> wrote:
> When the device is in promiscuous mode, the driver can receive vlan packets
> (tag is always stripped by card) even when there is no vlan configuration.
> Such packets must be sent to the stack and not dropped.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
> ---
> drivers/net/benet/be_main.c | 9 ++-------
> 1 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
> index 97c5167..18c6da4 100644
> --- a/drivers/net/benet/be_main.c
> +++ b/drivers/net/benet/be_main.c
> @@ -1013,15 +1013,10 @@ static void be_rx_compl_process(struct be_adapter *adapter,
> skb->truesize = skb->len + sizeof(struct sk_buff);
> skb->protocol = eth_type_trans(skb, adapter->netdev);
>
> - if (unlikely(rxcp->vlanf)) {
> - if (!adapter->vlan_grp || adapter->vlans_added == 0) {
> - kfree_skb(skb);
> - return;
> - }
> + if (unlikely(rxcp->vlanf))
> vlan_hwaccel_receive_skb(skb, adapter->vlan_grp, rxcp->vid);
It would be better to use __vlan_hwaccel_put_tag() here - it's
equivalent but at least moves in the right direction. Under the old
vlan model (which vlan_hwaccel_receive_skb() is left over from)
passing in a NULL vlan group is illegal, so it's inconsistent anyways.
Of course even better would be to fully convert over to the new vlan
model. A quick skim through the code shows that there might be
similar issue with vlan_gro_frags() as above, so it could help catch
some of that.
^ permalink raw reply
* Re: [PATCH] net: drop NETIF_F_GSO from hw_features without NETIF_F_SG
From: Michał Mirosław @ 2011-03-18 20:43 UTC (permalink / raw)
To: Roger Luethi; +Cc: netdev
In-Reply-To: <20110318195030.GA22350@core.hellgate.ch>
2011/3/18 Roger Luethi <rl@hellgate.ch>:
> register_netdevice() removes NETIF_F_GSO from dev->features and
> dev->wanted_features for hardware without NETIF_F_SG to "avoid warning from
> netdev_fix_features()".
>
> However, as the flag remains set in dev->hw_features, users trying to
> enable GSO via ethtool will still end up with NETIF_F_GSO stuck in
> wanted_features, resulting in a warning every time they try to change any
> feature (until they use ethtool to "disable" GSO):
That's expected, as it allows the user to debug why his request didn't
work as expected. I think that those messages should get demoted to
DEBUG if that's too noisy. The network core imposed conditions could
be explained in Documentation/ or ethtool manpage instead.
Best Regards,
Michał Mirosław
^ permalink raw reply
* [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
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