Re: [RFC PATCH] accounting for socket backlog

[Eric Dumazet <eric.dumazet@gmail.com>]

Le vendredi 26 février 2010 à 10:34 +0800, Zhu Yi a écrit :
> On Thu, 2010-02-25 at 19:24 +0800, Eric Dumazet wrote:
> > - What about other protocols that also use a backlog ?
> 
> I don't think protocols with flow/congestion control capability have
> such issue. We have tested TCP is immune. Other current backlog users
> are dccp, sctp, tipc, x.25 and llc. We didn't test all of them. But
> looks like only llc here is possible but unlikely?
> 

I looked again for TCP case and I see same problem than UDP. If socket
is locked by user, and a softirq flood happens, you can fill backlog too
with frames (any frame with correct tuple, even with bad sequences), and
exhaust memory.


> > - __release_sock() could run forever with no preemption, even with a
> > limit on backlog. 
> 
> Yes, but there is no critical impact like memory exhausted for this
> case.
> 

Well, if you have one processor, and a process doesnt want to yield the
cpu (apart of sofirq of course that is filling the backlog while your
process tries to empty it), your machine is dead. This is critical
too :)