netdev - Re: [PATCH] net/flow: remove sleeping and deferral mechanism from flow_cache

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:	Tue, 20 Dec 2011 10:41:40 +0200
From:	Timo Teräs <timo.teras@....fi>
To:	Steffen Klassert <steffen.klassert@...unet.com>
CC:	David Miller <davem@...emloft.net>, madalin.bucur@...escale.com,
	eric.dumazet@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH] net/flow: remove sleeping and deferral mechanism from
 flow_cache_flush

On 12/20/2011 10:23 AM, Steffen Klassert wrote:
> On Tue, Sep 27, 2011 at 03:31:32PM -0400, David Miller wrote:
>> From: David Miller <davem@...emloft.net>
>> Date: Tue, 27 Sep 2011 15:28:36 -0400 (EDT)
>>
>>> afinfo->garbage_collect is the only other place __xfrm_garbage_collect
>>> is referenced, and that is completely unused and should thus be deleted
>>> (I'll take care of that in net-next).
>>
>> Nevermind I see how these are referenced directly via xfrm4_policy.c
>> and xfrm6_policy.c, sigh...
> 
> Is there any progress in fixing this issue? I've seen this occasionally
> on some of our production systems, so I fixed it for us in the meantime
> with the patch below. I could submit this for inclusion if noone else
> wants to fix it in a different manner.
> 
> ------
> net: Add a flow_cache_flush_deferred function
> 
> flow_cach_flush() might sleep but can be called from
> atomic context via the xfrm garbage collector. So add
> a flow_cache_flush_deferred() function and use this if
> the xfrm garbage colector is invoked from within the
> packet path.
> 
> Signed-off-by: Steffen Klassert <steffen.klassert@...unet.com>

Acked-by: Timo Teräs <timo.teras@....fi>

I was first thinking if it made sense to run the local CPUs task
immediately on gc. But since all it does is queue the removed nodes to
the second gc that actually frees the dst's, it doesn't really make a
difference.

So this is probably as good as it gets.
--
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