Re: [RFC PATCH] accounting for socket backlog

[Zhu Yi <yi.zhu@intel.com>]

On Mon, 2010-03-01 at 10:29 +0800, Eric Dumazet wrote:
> 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.

Agreed. Unless you or someone else provides a better idea solves them
both, I'd only fix one problem at a time.

> - 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.

This is my original plan. But davem just mentioned we have to prevent
from maliciously send frames, that means all protocols using backlog.
That makes me consider if I should put the check to the generic path.

Thanks,
-yi