Re: [PATCH] sunrpc: make warning in svc_check_conn_limits() more generic

["NeilBrown" <neilb@suse.de>]

On Thu, October 16, 2008 11:51 am, Jeff Layton wrote:
> On Wed, 15 Oct 2008 16:21:02 -0400
> "J. Bruce Fields" <bfields@fieldses.org> wrote:
>
>> On Wed, Oct 15, 2008 at 08:14:57AM -0400, Jeff Layton wrote:
>> > From the descriptions in those commits, it looks like the check
>> > in svc_check_conn_limits was intended to prevent messages from too
>> > many sockets overloading the receive buffers.
>>
>> Aren't the receive buffers per-connection?
>>
>> --b.
>>
>
> Oof...you're quite right. I misunderstood the code earlier. Thinking
> this through a bit more...
>
> I suppose the main worry is that we have a service with too few
> threads and a ton of sockets. We end up in a situation where the
> receive buffers aren't getting processed quickly enough and connections
> start stalling out.
>
> I suppose the only real remedy for that is to increase the number of
> threads, but that's not an option for services like lockd. So maybe
> ignoring this check on single-threaded services is the way to go after
> all? I don't see a way to make this auto-tuning based on memory since
> that doesn't seem to be what the check is intended to help...

Don't expect too much of the "intent" of this limit.
I think it just "seemed like a good idea at the time" with some idea that
a denial of service attack could swamp the NFS server with connections
if we didn't actively close some when there was a large number of them.

The patch which added the test is
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=afdb4fa2b04a7e90e0746bc3d031a552656c7709

which says nothing about why.

I found an old Email with a list of things I needed to do to be happy
with TCP support and it included:


- Guard against denial of service - impose some limit on the number of
  incoming connections, and start randomly dropping connections when
  this limit is exceeded.

Which again isn't very helpful.

I certainly wasn't thinking about the possibility of lockd getting
lots of connections despite being a single-thread service.

Maybe we should use
 current->signal->rlim[RLIMIT_NOFILE].rlim_cur
as a minimum limit.  i.e if the number of connections is below this,
allow the connection.  If the number of connections is below the
currently calculated value, also allow the connection.
Only reject if the number is greater than both of these limits.

One problem there is that I don't think you can adjust the RLIMIT_NOFILE
limit for nfsd. It (it think) shares this number with init and all other
kernel threads.

NeilBrown