[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOrHB_DKMW6VoVbu1yvHRQRk92w-uUZWaGQURyRxhO=GaOPXsg@mail.gmail.com>
Date: Mon, 11 Jan 2016 16:36:11 -0800
From: pravin shelar <pshelar@....org>
To: Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net] net: reduce RECURSION_LIMIT to 8
On Mon, Jan 11, 2016 at 4:24 AM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
> On 11.01.2016 07:38, pravin shelar wrote:
>>
>> On Thu, Jan 7, 2016 at 9:40 AM, Hannes Frederic Sowa
>> <hannes@...essinduktion.org> wrote:
>>>
>>> When RECURSION_LIMIT was first introduced, Eric proposed a limit of 3.
>>> This limit was later raised to 10 by DaveM. Nowadays it is observed that
>>> configuraion errors in openvswitch cause the STACK_END_MAGIC to be
>>> overwritten shortly after 9 recursion.
>>>
>> Major user of stack space in OVS is sw_flow_key in
>> ovs_vport_receive(). With recent features like IPv6 tunnel support we
>> have increased the size of the flow-key which could have caused the
>> stack overflow sooner.
>> One way to avoid using stack in subsequent recursive call is to use
>> per-cpu storage for the sw_flow_key object. This is already done for
>> OVS recursive actions, so we can expand on that facility.
>
>
> Hmmm. This already came up. I think the difficulty is that ovs_vport_receive
> can be called from actions again with skb_cloned skb before the original's
> skb callstack is actually finished. Data in the percpu area would be
> overwritten while still being used. It would need some more logic IMHO.
>
You can have stack of flow-keys and allocate a flow-key for each recursive call.
> What are recursive actions in ovs? I couldn't find any use of pcpu data in
> there? Thanks! :)
>
There are couple of recursive actions in OVS, e.g.
OVS_ACTION_ATTR_RECIRC. But it is implemented by using per-cpu
flow-key stack to avoid recursive function call.
Powered by blists - more mailing lists