All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anders Gustafsson <andersg@0x63.nu>
To: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
Cc: "David S. Miller" <davem@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] /proc/net/tcp + ipv6 hang
Date: Mon, 23 Dec 2002 04:08:12 +0100	[thread overview]
Message-ID: <20021223030812.GA18409@gagarin> (raw)
In-Reply-To: <20021223024017.GO4942@conectiva.com.br>

On Mon, Dec 23, 2002 at 12:40:17AM -0200, Arnaldo Carvalho de Melo wrote:
> 
> Anders, if you're feeling brave, from the top of my head, think about what
> happens if somebody only reads the first, say, 10 bytes of /proc/net/tcp, will
> we unlocking a not held lock at tcp_seq_stop, no? :-)

Yes, I was just looking into the locking... But it's rather messy with locks
between calls and goto's and I think I'd better get some sleep before saying
anything for certain. Is there any reason holding the lock between
listening_get_first() and the first call to listening_get_next(), but not
between consecutive calls to listening_get_next()? Otherwise we could just
always release the lock in listening_get_first.

(All this applies to established_get_first/next too.)

OOPS, I just realizes we might be talking about different locks :)

I was talking about 
read_[un]lock_bh(&tp->syn_wait_lock); in listening_get_first/next

What lock are you talking about?
As far as I can see, in TCP_SEQ_STATE_OPENREQ tp->syn_wait_lock is always
held and in TCP_SEQ_STATE_LISTENING the tcp_listen_lock and so on?

-- 
Anders Gustafsson - andersg@0x63.nu - http://0x63.nu/

  reply	other threads:[~2002-12-23  3:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-23  1:57 [PATCH] /proc/net/tcp + ipv6 hang Anders Gustafsson
2002-12-23  2:03 ` Arnaldo Carvalho de Melo
2002-12-23  2:40 ` Arnaldo Carvalho de Melo
2002-12-23  3:08   ` Anders Gustafsson [this message]
2002-12-23  3:27     ` Arnaldo Carvalho de Melo
2002-12-23  7:20   ` David S. 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=20021223030812.GA18409@gagarin \
    --to=andersg@0x63.nu \
    --cc=acme@conectiva.com.br \
    --cc=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.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 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.