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  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:	Tue, 12 Aug 2014 17:46:21 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	hannes@...essinduktion.org
Cc:	hannes@...hat.com, eric.dumazet@...il.com, mleitner@...hat.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH stable 3.4 1/2] ipv4: move route garbage collector to
 work queue

From: Hannes Frederic Sowa <hannes@...essinduktion.org>
Date: Wed, 13 Aug 2014 01:11:14 +0200

> On Wed, Aug 13, 2014, at 00:42, David Miller wrote:
>> Just bite the bullet and put a spinlock around the GC operation.
> 
> We had a spinlock around the GC operation at first but still were
> capable to cause softlockups, I don't remember if a complete lockup
> happend.

This much I understand.

What I'm saying is retain this patch #1, in order to make the normal
GCs run asynchronously via a work queue, but on top of that put a
spinlock around the GC function.

> Should be no problem to conditional synchronize with the neighbour
> overflow path.

Once you have the spinlock around the GC it should be just fine.

If we hit the neighbour table overflow condition when an async GC is
operating, the direct GC call from the neighbour table overflow path
will just spin on the lock waiting for the async GC to complete.
--
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

Powered by blists - more mailing lists