netdev - Re: [PATCH net-next] net: only run neigh_forced

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]

Message-ID: <20120919105038.GA12352@hmsreliant.think-freely.org>
Date:	Wed, 19 Sep 2012 06:50:38 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Maciej Żenczykowski <maze@...gle.com>,
	Tom Herbert <therbert@...gle.com>,
	Lorenzo Colitti <lorenzo@...gle.com>
Subject: Re: [PATCH net-next] net: only run neigh_forced_gc() from one cpu

On Wed, Sep 19, 2012 at 11:27:07AM +0200, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@...gle.com>
> 
> With multiqueue NIC or RPS, we can have situation where all cpus are
> spending huge amount of cycles in neigh_forced_gc(), and machine can
> crash.
> 
> Since we are under probable attack, its better to let only one cpu
> do the scan, and other cpus immediately return from neigh_forced_gc()
> 
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> Cc: Lorenzo Colitti <lorenzo@...gle.com>
> Cc: Maciej Żenczykowski <maze@...gle.com>
> Cc: Tom Herbert <therbert@...gle.com>
> ---
> Google-Bug-Id: 7121897
> 
>  include/net/neighbour.h |    1 +
>  net/core/neighbour.c    |    9 +++++++--
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/include/net/neighbour.h b/include/net/neighbour.h
> index 0dab173..ba21e93 100644
> --- a/include/net/neighbour.h
> +++ b/include/net/neighbour.h
> @@ -178,6 +178,7 @@ struct neigh_table {
>  	struct neigh_statistics	__percpu *stats;
>  	struct neigh_hash_table __rcu *nht;
>  	struct pneigh_entry	**phash_buckets;
> +	spinlock_t		forced_gc_lock;
>  };
>  
>  #define NEIGH_PRIV_ALIGN	sizeof(long long)
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index c160adb..1f7d8fa 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -134,9 +134,12 @@ static int neigh_forced_gc(struct neigh_table *tbl)
>  	int i;
>  	struct neigh_hash_table *nht;
>  
> +	if (!spin_trylock_bh(&tbl->forced_gc_lock))
> +		return 0;
> +
This is going to cause callers in neigh_alloc to immediately fail their
allocation attempts.  Would it be a good idea to modify that call site so that
instead of returning NULL, instead reread tbl->entries before comparing to
gc_thresh3, on the hope that the cpu in the garbage collecting routine has freed
some entries?

Neil

--
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