netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: kuznet@ms2.inr.ac.ru
Cc: vgusev@openvz.org, mcmanus@ducksong.com, xemul@openvz.org,
	netdev@vger.kernel.org, ilpo.jarvinen@helsinki.fi, mingo@elte.hu,
	linux-kernel@vger.kernel.org
Subject: Re: [TCP]: TCP_DEFER_ACCEPT causes leak sockets
Date: Wed, 11 Jun 2008 16:52:55 -0700 (PDT)	[thread overview]
Message-ID: <20080611.165255.242691774.davem@davemloft.net> (raw)
In-Reply-To: <20080611135718.GA26914@ms2.inr.ac.ru>

From: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Date: Wed, 11 Jun 2008 17:57:18 +0400

> Major issue is that tcp_defer_accept_check() manipulates with not locked
> listening socket. And from all that I know it is impossible to take
> the lock in this context.
> 
> Also I see no accounting for those sockets. With this patch any server, which
> set deferred accept, can be flooded with sockets until memory exhausts.
> I did not test and would be glad to be mistaken.
> 
> 
> Issue with locking can be solved by adding a separate spinlock for
> manipulations with accept_queue. Apparently, accounting and killing
> sockets, which become stale after closing listening socket and
> are going to be alive for up to 65535 seconds, also goes under this lock.
> 
> Frankly, cost looks too high for this feature.
> 
> Hiding from accept() sockets with only out-of-order data only
> is the only thing which is impossible with old approach. Is this really
> so valuable? My opinion: no, this is nothing but a new loophole
> to consume memory without control.

Yes, we discussed the locking issue over past few days.  See
the thread: "stuck localhost TCP connections, v2.6.26-rc3+"

More and more, the arguments are mounting to completely revert the
established code path changes, and frankly that is likely what I am
going to do by the end of today.

  reply	other threads:[~2008-06-11 23:52 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-11 12:58 [TCP]: TCP_DEFER_ACCEPT causes leak sockets Vitaliy Gusev
2008-06-11 13:57 ` Alexey Kuznetsov
2008-06-11 23:52   ` David Miller [this message]
2008-06-12 23:32     ` David Miller
2008-06-13  6:30       ` Ingo Molnar
2008-06-13  9:32         ` David Miller
2008-06-13 11:09           ` Ingo Molnar
2008-06-13 11:47             ` Ingo Molnar
2008-06-13 21:10               ` Ingo Molnar
2008-06-16 23:59               ` David Miller
2008-06-17  7:26                 ` Ingo Molnar
2008-06-17  7:38                   ` David Miller
2008-06-17  8:09                     ` Ingo Molnar
2008-06-17  8:32                       ` Ingo Molnar
2008-06-17  9:08                         ` David Miller
2008-06-17  9:27                           ` Ingo Molnar
2008-06-17  9:29                             ` David Miller
2008-06-17  9:39                               ` Ingo Molnar
2008-06-18 18:50                                 ` [E1000-devel] " Kok, Auke
2008-06-18 20:08                                   ` Ingo Molnar
2008-06-18 21:25                                     ` [E1000-devel] " Kok, Auke
2008-06-18 22:12                                       ` David Miller
2008-06-19  7:06                                         ` Jarek Poplawski
2008-06-18 21:32                                     ` Ingo Molnar
2008-06-18 21:41                                       ` Denys Fedoryshchenko
2008-06-18 22:05                                         ` Ingo Molnar
2008-06-18 22:44                                           ` Denys Fedoryshchenko
2008-06-18 23:14                                   ` Ingo Molnar
2008-06-17  8:43                       ` Vitaliy Gusev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080611.165255.242691774.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=ilpo.jarvinen@helsinki.fi \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcmanus@ducksong.com \
    --cc=mingo@elte.hu \
    --cc=netdev@vger.kernel.org \
    --cc=vgusev@openvz.org \
    --cc=xemul@openvz.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).