All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: David Miller <davem@davemloft.net>
Cc: weid@np.css.fujitsu.com, netdev@vger.kernel.org
Subject: Re: Fix bugs in "Whether sock accept queue is full" checking
Date: Thu, 22 Feb 2007 13:09:46 -0500	[thread overview]
Message-ID: <45DDDC6A.6080205@hp.com> (raw)
In-Reply-To: <20070222.031310.85405859.davem@davemloft.net>

David Miller wrote:
> From: weidong <weid@np.css.fujitsu.com>
> Date: Wed, 14 Feb 2007 11:30:57 -0500
> 
>> 	when I use linux TCP socket, and find there is a bug in function
>> sk_acceptq_is_full(). 
>  ...
>> Consider an example:
>>
>>  After listen(sockfd, 1) system call, sk->sk_max_ack_backlog is set to
>> 1. As we know, sk->sk_ack_backlog is initialized to 0. Assuming accept()
>> system call is not invoked now.
>>
>> 1. 1st connection comes. invoke sk_acceptq_is_full(). sk-
>>> sk_ack_backlog=0 sk->sk_max_ack_backlog=1, function return 0 accept
>> this connection. Increase the sk->sk_ack_backlog
>> 2. 2nd connection comes. invoke sk_acceptq_is_full(). sk-
>>> sk_ack_backlog=1 sk->sk_max_ack_backlog=1, function return 0 accept
>> this connection. Increase the sk->sk_ack_backlog
>> 3. 3rd connection comes. invoke sk_acceptq_is_full(). sk-
>>> sk_ack_backlog=2 sk->sk_max_ack_backlog=1, function return 1. Refuse
>> this connection.
>>
>> I think it has bugs. after listen system call. sk->sk_max_ack_backlog=1
>> but now it can accept 2 connections. The following patch can fix this
>> problem.
>>
>> signed-off-by: Wei Dong <weid@np.css.fujitsu.com>
> 
> Thank you very much for the detailed analysis and fix.
> 
> Actually, this bug exists all over the tree I believe, not just
> in TCP.  I would like to audit all uses of sk_ack_backlog and
> sk_max_ack_backlog before applying your patch, so please give
> me some time to perform a quick audit.
> 
> Thank you.

Hi David

I can confirm the same problem exists in SCTP because of the use of sk_acceptq_is_full().

-vlad

  reply	other threads:[~2007-02-22 18:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-14 16:30 Fix bugs in "Whether sock accept queue is full" checking weidong
2007-02-22 11:13 ` David Miller
2007-02-22 18:09   ` Vlad Yasevich [this message]
2007-03-02 20:51 ` David Miller

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=45DDDC6A.6080205@hp.com \
    --to=vladislav.yasevich@hp.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=weid@np.css.fujitsu.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.