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.
next prev parent 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).