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] [day] [month] [year] [list]
Date:	Mon, 21 Jul 2014 18:52:45 -0700
From:	Pravin Shelar <pshelar@...ira.com>
To:	David Miller <davem@...emloft.net>
Cc:	David Laight <David.Laight@...lab.com>,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v6 04/11] net: Export xmit_recursion

On Mon, Jul 21, 2014 at 2:30 PM, David Miller <davem@...emloft.net> wrote:
> From: Pravin Shelar <pshelar@...ira.com>
> Date: Mon, 21 Jul 2014 10:01:52 -0700
>
>> On Mon, Jul 21, 2014 at 1:52 AM, David Laight <David.Laight@...lab.com> wrote:
>>> From: Pravin B Shelar
>>>> Next patch adds re-circulation action to OVS. This is recursive
>>>> action needs to be limited to safe number recursions to
>>>> avoid overflowing kernel stack space.  This patch export
>>>> xmit_recursion so that OVS can increment and check the value
>>>> before executing recirc action.
>>> ...
>>>> +#define NET_RECURSION_LIMIT 10
>>>
>>> I'm not entirely sure that any amount of recursion is a good idea
>>> inside the kernel.
>>> If the nested call frame is small enough so that your 10 nestings
>>> are valid it must also be reasonably easy to arrange for the code
>>> to be converted to a loop.
>>>
>>> Remember that the highest stack use is likely to be inside some
>>> error path (probably inside printk) so any experiments that seem
>>> to imply that that stack use is ok are doomed.
>>>
>>> Static analysis is possible (indirect calls make it tricky) provided
>>> there is no recursion.
>>> I did some static stack use analysis for an embedded system many
>>> years ago. It showed that we needed much larger stacks that we'd
>>> allowed for.
>>
>> I am using same recursion counter as networking stack does. Recursion
>> in OVS has lesser cost compared to recursion in networking stack, So
>> it is conservative to use same counter to track recursion in OVS as
>> networking stack recursion.
>
> The networking core uses it is to prevent untenable configurations.
>
> I was going to bring this issue up the other day but I've been
> to busy to do so.  I really want you to seriously look into using
> an iterative algorithm, it can't be so hard inside of openvswitch
> itself.
>
> Any time you go into openvswitch from "somewhere else" you initialize
> a per-cpu structure that keeps track of work to do, if you need to pop
> an MPLS header or whatever and recurse, record it in that structure
> and just return.
>
> This both eliminates recursion, and is faster, since you'll be reusing
> the same stack frame that's fresh and hot in the caches already.
>
OK, since recirc needs more work, I will post the series without recirc patches.

Thanks,
Pravin.

> I want to do this in the core networking at some point too.
--
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