[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 10 Oct 2013 15:02:14 +0800
From: Fan Du <fan.du@...driver.com>
To: Steffen Klassert <steffen.klassert@...unet.com>
CC: <netdev@...r.kernel.org>
Subject: Re: [PATCH RFC 0/2] xfrm: Remove ancient sleeping code
On 2013年10月10日 14:33, Steffen Klassert wrote:
> Does anyone still rely on the ancient sleeping when the SA is in
> acquire state? It is disabled by default since more that five years,
> but can cause indefinite task hangs if enabled and the needed state
> does not get resolved.
I saw that "can_sleep" is set true in ip_route_connect which upper layer
protocol relies on it, which ensure not dropping *any* skb.
And acquire timer will make sure the task will not hangs indefinitely.
In xfrm policy queue, XFRM_MAX_QUEUE_LEN is 100, which means 101th skb
will be dropped, how about make it configurable? If CAN_SLEEP flags is
removed, user could adjust this knob if needed in any circumstance.
> We now queue packets to the policy if the states are not yet resolved
> if we are in a code path that can not sleep. We could do this even in
> the case we can sleep. As a bonus, we can remove the FLOWI_FLAG_CAN_SLEEP
> flag because the only thing this flag does, is to notify xfrm that we are
> in a codepath that can sleep.
>
> The two RFC patches to remove the sleeping code are in reply to this
> mail. I'd add this to the ipsec-next tree if there are no objections.
> --
> 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
>
--
浮沉随浪只记今朝笑
--fan
--
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