netdev - Re: weird problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 11 Jul 2009 08:24:55 +0200
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Paweł Staszewski <pstaszewski@...are.pl>
Cc:	Eric Dumazet <dada1@...mosbay.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Linux Network Development list <netdev@...r.kernel.org>
Subject: Re: weird problem

On Fri, Jul 10, 2009 at 04:47:54PM +0200, Jarek Poplawski wrote:
> On Fri, Jul 10, 2009 at 01:59:00AM +0200, Paweł Staszewski wrote:
> > Today i make other tests with change of  
> > /proc/sys/net/ipv4/rt_cache_rebuild_count and kernel 2.6.30.1
> >
> > And when rt_cache_rebuild_count is set to "-1" i have always load on  
> > x86_64 machine approx 40-50% of each cpu where network card is binded by  
> > irq_aff
> >
> > when rt_cache_rebuild_count is set to more than "-1" i have 15 to 20 sec  
> > of 1 to 3% cpu and after 40-50% cpu
> ...
> 
> Here is one more patch for testing (with caution!). It adds possibility
> to turn off cache disabling (so it should even more resemble 2.6.28)
> after setting: rt_cache_rebuild_count = 0
> 
> I'd like you to try this patch:
> 1) together with the previous patch and "rt_cache_rebuild_count = 0"
>    to check if there is still the difference wrt. 2.6.28; Btw., let
>    me know which /proc/sys/net/ipv4/route/* settings do you need to
>    change and why
> 
> 2) alone (without the previous patch) and "rt_cache_rebuild_count = 0"
> 
> 3) if it's possible to try 2.6.30.1 without these patches, but with
>    default /proc/sys/net/ipv4/route/* settings, and higher
>    rt_cache_rebuild_count, e.g. 100; I'm interested if/how long it
>    takes to trigger higher cpu load and the warning "... rebuilds is
>    over limit, route caching disabled"; (Btw., I wonder why you didn't
>    mention about these or maybe also other route caching warnings?)

Here is take 2 to respect setting "rt_cache_rebuild_count = 0" even
after cache rebuild counter has been increased earlier. (Btw, don't
forget about this setting after going back to vanilla kernel.)

Jarek P.
--- (debugging patch #2 take 2; apply to 2.6.30.1 or 2.6.29.6)


 net/ipv4/route.c |   21 ++++++++++++++-------
 1 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 278f46f..f74db20 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -678,8 +678,9 @@ static inline u32 rt_score(struct rtable *rt)
 
 static inline bool rt_caching(const struct net *net)
 {
-	return net->ipv4.current_rt_cache_rebuild_count <=
-		net->ipv4.sysctl_rt_cache_rebuild_count;
+	return (net->ipv4.current_rt_cache_rebuild_count <=
+		net->ipv4.sysctl_rt_cache_rebuild_count) ||
+	       net->ipv4.sysctl_rt_cache_rebuild_count == 0;
 }
 
 static inline bool compare_hash_inputs(const struct flowi *fl1,
@@ -1181,12 +1182,18 @@ restart:
 	} else {
 		if (chain_length > rt_chain_length_max) {
 			struct net *net = dev_net(rt->u.dst.dev);
-			int num = ++net->ipv4.current_rt_cache_rebuild_count;
-			if (!rt_caching(dev_net(rt->u.dst.dev))) {
-				printk(KERN_WARNING "%s: %d rebuilds is over limit, route caching disabled\n",
-					rt->u.dst.dev->name, num);
+
+			if (net->ipv4.sysctl_rt_cache_rebuild_count > 0) {
+				int num = ++net->ipv4.current_rt_cache_rebuild_count;
+
+				if (!rt_caching(net))
+					printk(KERN_WARNING
+					       "%s: %d rebuilds is over limit, "
+					       "route caching disabled\n",
+					       rt->u.dst.dev->name, num);
+
+				rt_emergency_hash_rebuild(net);
 			}
-			rt_emergency_hash_rebuild(dev_net(rt->u.dst.dev));
 		}
 	}
 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html