[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140812.174621.1935425856781215649.davem@davemloft.net>
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