[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALnjE+r7BaX1C1X5=9mz4LUQhZZ9B13prukwh0x5_vBsesZYEA@mail.gmail.com>
Date: Mon, 21 Jul 2014 10:01:52 -0700
From: Pravin Shelar <pshelar@...ira.com>
To: David Laight <David.Laight@...lab.com>
Cc: "davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v6 04/11] net: Export xmit_recursion
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.
--
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