Re: [RFC PATCH] accounting for socket backlog

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

Le lundi 01 mars 2010 à 10:17 +0800, Zhu Yi a écrit :
> On Fri, 2010-02-26 at 21:12 +0800, Eric Dumazet wrote:
> > 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 :) 
> 
> If you only have one CPU, this won't happen. Because while the receiver
> is busy processing the backlog, no senders will have the chance to be
> scheduled to Tx more. And with the limited backlog, it won't take long
> for the receiver to finish processing all the frames in the backlog.
> 

You focus on the case you Intel guys discovered the flaw, using loopback
interface. I am concerned with a DOS situation, when some bad guys on
your LAN sends a flood on your machine, using a real 10Gb NIC.

I was concerned by two things :

- One process being stuck forever in the __release_sock(), basically
stopping an application from performing progress. This is a DOS problem.
Our kernel is potentially affected. We probably should do something to
avoid this problem. But I am _not_ saying this should be done by your
patch, it is probably possible to address it in an independant patch.

- One process being stuck in __release_sock() and not yield to other
processes. This is not the case since we call the cond_resched_sofirq()
function that permits other high priority task to get the CPU.


One more point :

If you remember my previous mail, I suggested cleaning the len field in
__release_sock(). This way, you can provide a first patch, protocol
agnostic, then provide further patch for UDP V4, another patch for UDP
V6, etc... to have a clean path and make the resolution of the bugs more
self explaining and not as a whole and big patch.
 
Thanks