* 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
* [PATCH v2] net: implement dev_disable_lro() hw_features compatibility
From: Michał Mirosław @ 2011-03-19 2:56 UTC (permalink / raw)
To: netdev; +Cc: Ben Hutchings, David S. Miller
In-Reply-To: <1300471986.2589.26.camel@bwh-desktop>
Implement compatibility with new hw_features for dev_disable_lro().
This is a transition path - dev_disable_lro() should be later
integrated into netdev_fix_features() after all drivers are converted.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
Changes from v1:
- moved __ethtool_set_flags() prototype to ethtool.h
include/linux/ethtool.h | 3 +++
net/core/dev.c | 19 +++++++++++--------
net/core/ethtool.c | 2 +-
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index aac3e2e..c9bfe2d 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -614,6 +614,9 @@ enum ethtool_sfeatures_retval_bits {
#include <linux/rculist.h>
+/* needed by dev_disable_lro() */
+extern int __ethtool_set_flags(struct net_device *dev, u32 flags);
+
struct ethtool_rx_ntuple_flow_spec_container {
struct ethtool_rx_ntuple_flow_spec fs;
struct list_head list;
diff --git a/net/core/dev.c b/net/core/dev.c
index 0b88eba..f453370 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1353,14 +1353,17 @@ EXPORT_SYMBOL(dev_close);
*/
void dev_disable_lro(struct net_device *dev)
{
- if (dev->ethtool_ops && dev->ethtool_ops->get_flags &&
- dev->ethtool_ops->set_flags) {
- u32 flags = dev->ethtool_ops->get_flags(dev);
- if (flags & ETH_FLAG_LRO) {
- flags &= ~ETH_FLAG_LRO;
- dev->ethtool_ops->set_flags(dev, flags);
- }
- }
+ u32 flags;
+
+ if (dev->ethtool_ops && dev->ethtool_ops->get_flags)
+ flags = dev->ethtool_ops->get_flags(dev);
+ else
+ flags = ethtool_op_get_flags(dev);
+
+ if (!(flags & ETH_FLAG_LRO))
+ return;
+
+ __ethtool_set_flags(dev, flags & ~ETH_FLAG_LRO);
WARN_ON(dev->features & NETIF_F_LRO);
}
EXPORT_SYMBOL(dev_disable_lro);
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index c1a71bb..7371177 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -513,7 +513,7 @@ static int ethtool_set_one_feature(struct net_device *dev,
}
}
-static int __ethtool_set_flags(struct net_device *dev, u32 data)
+int __ethtool_set_flags(struct net_device *dev, u32 data)
{
u32 changed;
--
1.7.2.3
^ permalink raw reply related
* Re: ipv6 secondary ips and default ipv6 ip for new outbound connections
From: Jim Westfall @ 2011-03-19 3:35 UTC (permalink / raw)
To: Brian Haley; +Cc: netdev
In-Reply-To: <4D8413BE.5000305@hp.com>
Brian Haley <brian.haley@hp.com> wrote [03.18.11]:
> 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;
> }
>
Hi
Your patch fixes it for me.
# ip addr add 2600:c00:0:1::1101/64 dev eth0
~# 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 eth0
~# 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::1103/64 dev eth0
~# 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 -6 addr show dev eth0
3: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qlen 1000
inet6 2600:c00:0:1::1101/64 scope global
valid_lft forever preferred_lft forever
inet6 2600:c00:0:1::1102/64 scope global
valid_lft forever preferred_lft forever
inet6 2600:c00:0:1::1103/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::21a:64ff:fe12:54bd/64 scope link
valid_lft forever preferred_lft forever
thanks
Jim
^ permalink raw reply
* Re: [PATCH 2/4] slub,rcu: don't assume the size of struct rcu_head
From: Hugh Dickins @ 2011-03-19 3:58 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Lai Jiangshan, Ingo Molnar, Paul E. McKenney,
Eric Dumazet, David S. Miller, Matt Mackall, linux-mm,
linux-kernel, netdev
In-Reply-To: <alpine.DEB.2.00.1103171006270.12540@router.home>
On Thu, 17 Mar 2011, Christoph Lameter wrote:
> On Sun, 6 Mar 2011, Hugh Dickins wrote:
>
> > >> That was so for a long time, but I stopped it just over a year ago
> > >> with commit a70caa8ba48f21f46d3b4e71b6b8d14080bbd57a, stop ptlock
> > >> enlarging struct page.
> > >
> > > Strange. I just played around with in in January and the page struct size
> > > changes when I build kernels with full debugging. I have some
> > > cmpxchg_double patches here that depend on certain alignment in the page
> > > struct. Debugging causes all that stuff to get out of whack so that I had
> > > to do some special patches to make sure fields following the spinlock are
> > > properly aligned when the sizes change.
> >
> > That puzzles me, it's not my experience and I don't have an
> > explanation: do you have time to investigate?
> >
> > Uh oh, you're going to tell me you're working on an out-of-tree
> > architecture with a million cpus ;) In that case, yes, I'm afraid
> > I'll have to update the SPLIT_PTLOCK_CPUS defaulting (for a million -
> > 1 even).
>
> No I am not working on any out of tree structure. Just regular dual socket
> server boxes with 24 processors (which is a normal business machine
> configuration these days).
>
> But then there is also CONFIG_GENERIC_LOCKBREAK. That does not affect
> things?
CONFIG_GENERIC_LOCKBREAK adds an unsigned int break_lock after the
int-sized arch_spinlock_t: which would make no difference on 64-bit
anyway (the two ints fitting into one long), and makes no difference
on 32-bit because we have put
struct {
unsigned long private;
struct address_space *mapping;
};
into the union with spinlock_t ptl - the arch_spinlock_t then
overlays private and the break_lock overlays mapping.
I'd much rather have had simple elements in that union, but it's
precisely because of 32-bit CONFIG_GENERIC_LOCKBREAK that we need
that structure in there.
(It is important to the KSM assumption about page->mapping that
what goes into break_lock is either 0 or 1: in neither case could
page->mapping look like a kmem address + 3.)
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] Add useful per-connection TCP stats for diagnosis purpose.
From: Jerry Chu @ 2011-03-19 4:33 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, netdev
In-Reply-To: <1300428324.2881.5.camel@edumazet-laptop>
On Thu, Mar 17, 2011 at 11:05 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> Le jeudi 17 mars 2011 à 21:33 -0700, Jerry Chu a écrit :
>
> > Yes I'm familiar with ss and how inet_csk_diag_fill() calls into
> > tcp_diag_get_info(),..., etc. Like I mentioned previously the netlink
> > interface
> > requires a new version of reader app (e.g., ss) to ship every time a new
> > counter is added and exported by the kernel, whereas /proc/net/tcp does
> > not have such a problem.
> >
> > Anyway I can add a INET_DIAG_INFO_EXT of some sort to netlink in
> > addition to /proc/net/tcp. That's easy to do.
> >
>
> I suggest adding a getsockopt() or something to gather stats for one
> socket. On a loaded machine, /proc/net/tcp is damn slow.
I'm well aware of the past, hideous O(n**2) problem of reading
/proc/net/tcp but I
thought the problem has been fixed by Tom Herbert a while back, no?
(See http://marc.info/?l=linux-netdev&m=127588123429437&w=2)
>
> We have TCP_INFO, we could add TCP_INFO_EXT, but taking care of choosing
> an interface allowing for extension of the structure.
Ok.
Jerry
^ permalink raw reply
* [patch] ftmac100: use resource_size()
From: Dan Carpenter @ 2011-03-19 4:39 UTC (permalink / raw)
To: Po-Yu Chuang; +Cc: Eric Dumazet, David S. Miller, netdev, kernel-janitors
The calculation is off-by-one. It should be "end - start + 1". This
patch fixes it to use resource_size() instead. Oddly, the code already
uses resource size correctly a couple lines earlier when it calls
request_mem_region() for this memory.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/ftmac100.c b/drivers/net/ftmac100.c
index 1d6f4b8..a316619 100644
--- a/drivers/net/ftmac100.c
+++ b/drivers/net/ftmac100.c
@@ -1102,7 +1102,7 @@ static int ftmac100_probe(struct platform_device *pdev)
goto err_req_mem;
}
- priv->base = ioremap(res->start, res->end - res->start);
+ priv->base = ioremap(res->start, resource_size(res));
if (!priv->base) {
dev_err(&pdev->dev, "Failed to ioremap ethernet registers\n");
err = -EIO;
^ permalink raw reply related
* Re: [patch] ftmac100: use resource_size()
From: David Miller @ 2011-03-19 4:53 UTC (permalink / raw)
To: error27; +Cc: ratbert, eric.dumazet, netdev, kernel-janitors
In-Reply-To: <20110319043915.GB2008@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Sat, 19 Mar 2011 07:39:15 +0300
> The calculation is off-by-one. It should be "end - start + 1". This
> patch fixes it to use resource_size() instead. Oddly, the code already
> uses resource size correctly a couple lines earlier when it calls
> request_mem_region() for this memory.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied, thanks for fixing this Dan.
^ permalink raw reply
* Re: [PATCH 2/4] ipv4: fix route deletion for IPs on many subnets
From: David Miller @ 2011-03-19 4:57 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1103190113420.1678@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Sat, 19 Mar 2011 01:17:01 +0200 (EET)
> + 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
...
> + /* Ignore ifa1 if it uses different primary IP (prefsrc) */
> + if (ifa1->ifa_flags & IFA_F_SECONDARY) {
> + /* Another address from our subnet? */
...
> + 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);
Julian there exists all kinds of incorrect indentation in this patch,
could you please fix it up?
Thank you.
^ permalink raw reply
* Re: [PATCH] Add useful per-connection TCP stats for diagnosis purpose.
From: Eric Dumazet @ 2011-03-19 5:02 UTC (permalink / raw)
To: Jerry Chu; +Cc: Stephen Hemminger, netdev
In-Reply-To: <AANLkTikrJ7A-ygc9JnkvfBpRaKjL0fKeta+9ASLDr0rg@mail.gmail.com>
Le vendredi 18 mars 2011 à 21:33 -0700, Jerry Chu a écrit :
> I'm well aware of the past, hideous O(n**2) problem of reading
> /proc/net/tcp but I
> thought the problem has been fixed by Tom Herbert a while back, no?
> (See http://marc.info/?l=linux-netdev&m=127588123429437&w=2)
>
O(N) is still too slow, to gather stats for your socket, if you want to
gather stats once per second for example.
AFAIK, I am not sure we want to allow any user to access all these data
for all tcp sockets on the machine. This might have security impacts.
^ permalink raw reply
* Re: [patch] ftmac100: use resource_size()
From: Po-Yu Chuang @ 2011-03-19 5:05 UTC (permalink / raw)
To: Dan Carpenter
Cc: Po-Yu Chuang, Eric Dumazet, David S. Miller, netdev,
kernel-janitors
In-Reply-To: <20110319043915.GB2008@bicker>
Hi Dan,
On Sat, Mar 19, 2011 at 12:39 PM, Dan Carpenter <error27@gmail.com> wrote:
> The calculation is off-by-one. It should be "end - start + 1". This
> patch fixes it to use resource_size() instead. Oddly, the code already
> uses resource size correctly a couple lines earlier when it calls
> request_mem_region() for this memory.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> diff --git a/drivers/net/ftmac100.c b/drivers/net/ftmac100.c
> index 1d6f4b8..a316619 100644
> --- a/drivers/net/ftmac100.c
> +++ b/drivers/net/ftmac100.c
> @@ -1102,7 +1102,7 @@ static int ftmac100_probe(struct platform_device *pdev)
> goto err_req_mem;
> }
>
> - priv->base = ioremap(res->start, res->end - res->start);
> + priv->base = ioremap(res->start, resource_size(res));
> if (!priv->base) {
> dev_err(&pdev->dev, "Failed to ioremap ethernet registers\n");
> err = -EIO;
Ah, I incautiously missed that line when code review.
Thanks,
Po-Yu Chuang
^ permalink raw reply
* Re: [PATCH] Add useful per-connection TCP stats for diagnosis purpose.
From: Jerry Chu @ 2011-03-19 5:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, netdev
In-Reply-To: <1300510960.2831.2.camel@edumazet-laptop>
On Fri, Mar 18, 2011 at 10:02 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 18 mars 2011 à 21:33 -0700, Jerry Chu a écrit :
>
>> I'm well aware of the past, hideous O(n**2) problem of reading
>> /proc/net/tcp but I
>> thought the problem has been fixed by Tom Herbert a while back, no?
>> (See http://marc.info/?l=linux-netdev&m=127588123429437&w=2)
>>
>
> O(N) is still too slow, to gather stats for your socket, if you want to
> gather stats once per second for example.
I don't see anyway around O(n). The netlink/inet_diag_dump() will take at
best O(n) too.
>
> AFAIK, I am not sure we want to allow any user to access all these data
> for all tcp sockets on the machine. This might have security impacts.
This seems to be an orthogonal issue to netlink or /proc/net/tcp.
Jerry
>
>
>
>
^ 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