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/
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox