From: Alex Elder <elder@inktank.com>
To: ceph-devel <ceph-devel@vger.kernel.org>
Subject: [PATCH 4/9] libceph: don't close socket in OPENING state
Date: Fri, 22 Jun 2012 17:48:30 -0500 [thread overview]
Message-ID: <4FE4F63E.6040902@inktank.com> (raw)
In-Reply-To: <4FE4F534.1000009@inktank.com>
The only way a socket enters OPENING state is via ceph_con_open().
The only times ceph_con_open() is called are:
- In fs/ceph/mds_client.c:register_session(), where it occurs
soon after a call to ceph_con_init().
- In fs/ceph/mds_client.c:send_mds_reconnect(). This is
called in two places.
- In fs/ceph/mds_client.c:check_new_map(), it is called
after a call to ceph_con_close()
- Or in fs/ceph/mds_client.c:peer_reset(), which is also only
called after reset_connection, which includes a call to
ceph_con_close().
- In net/ceph/mon_client.c:__open_session(), where it's called
right after a call to ceph_con_init().
- In net/ceph/osd_client.c:__reset_osd(), right after a call
to ceph_con_close().
- In net/ceph/osd_client.c:__map_request(), shortly after a call
to create_osd(), which includes a call to ceph_con_init().
After a call to ceph_con_init(), the state of a ceph connection is
CLOSED, and its socket pointer is null.
Similarly, after a call to ceph_con_close(), the state of the
connection is CLOSED, the underlying socket is closed, and the
connection's socket pointer is null.
Therefore, there is no reason to call con_close_socket() when a
connection is found to be in OPENING state in con_work(), because
the socket will already be closed, and the connection will already
be in CLOSED state.
Signed-off-by: Alex Elder <elder@inktank.com>
---
net/ceph/messenger.c | 1 -
1 file changed, 1 deletion(-)
Index: b/net/ceph/messenger.c
===================================================================
--- a/net/ceph/messenger.c
+++ b/net/ceph/messenger.c
@@ -2387,7 +2387,6 @@ restart:
if (test_and_clear_bit(OPENING, &con->state)) {
/* reopen w/ new peer */
dout("con_work OPENING\n");
- con_close_socket(con);
}
ret = try_read(con);
next prev parent reply other threads:[~2012-06-22 22:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-22 22:44 [PATCH 0/9] another batch of messenger patches Alex Elder
2012-06-22 22:48 ` [PATCH 1/9] libceph: encapsulate and document connect sequence Alex Elder
2012-06-22 22:48 ` [PATCH 2/9] libceph: encapsulate and document negotiation phase Alex Elder
2012-06-22 22:48 ` [PATCH 3/9] libceph: close the connection's socket on reset Alex Elder
2012-06-22 22:48 ` Alex Elder [this message]
2012-06-22 22:48 ` [PATCH 5/9] libceph: change TAG_CLOSE handling Alex Elder
2012-06-22 22:48 ` [PATCH 6/9] libceph: kill fail_protocol() Alex Elder
2012-06-22 22:48 ` [PATCH 7/9] libceph: close connection on reset tag Alex Elder
2012-06-22 22:48 ` [PATCH 8/9] libceph: close connection on connect failure Alex Elder
2012-06-22 22:49 ` [PATCH 9/9] libceph: set CONNECTING state even earlier Alex Elder
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=4FE4F63E.6040902@inktank.com \
--to=elder@inktank.com \
--cc=ceph-devel@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.