Re: [PATCH RFC 0/2] xfrm: Remove ancient sleeping code

[Steffen Klassert <steffen.klassert@secunet.com>]

On Thu, Oct 10, 2013 at 03:02:14PM +0800, Fan Du wrote:
> 
> 
> 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.

'Any' means one per task in this context. Also, we can't ensure that
this packet reaches it's destination. So where is the difference
between dropping the packet locally or on the network?

> And acquire timer will make sure the task will not hangs indefinitely.
> 

Did you try that? It makes sure that the task wakes up from time to time,
but it goes immediately back to sleep if the needed state is not resolved.
The only terminating contition is when the task gets a signal to exit.

> In xfrm policy queue, XFRM_MAX_QUEUE_LEN is 100, which means 101th skb
> will be dropped, how about make it configurable?

IMO we would have yet another useless knob then. Currently we send all
packets by default to a blackhole as long as the state is not resolved
and most people are fine with it. The queueing is mostly to speed up
tcp handshakes, so 100 packets should be enough. If it really turnes
out that we need more that 100 packets in some cases, we can add a
sysctl then.