From: Ian Kent <ikent@redhat.com>
To: Paulo Andrade <paulo.cesar.pereira.de.andrade@gmail.com>,
libtirpc-devel@lists.sourceforge.net
Cc: linux-nfs@vger.kernel.org, Paulo Andrade <pcpa@gnu.org>
Subject: Re: [Libtirpc-devel] [PATCH 3/3] Do not hold a global mutex during connect
Date: Fri, 20 May 2016 10:00:36 +0800 [thread overview]
Message-ID: <1463709636.3034.55.camel@redhat.com> (raw)
In-Reply-To: <1463672110-10026-4-git-send-email-pcpa@gnu.org>
On Thu, 2016-05-19 at 12:35 -0300, Paulo Andrade wrote:
> A multi-threaded application, connecting to multiple rpc servers,
> may dead lock if the connect call stalls on a non responsive server.
It's occurred to me that the mutex may be held over the connect(2) call to
prevent concurrent calls to connect(2) using the same fd.
That's a race and is a lot harder to deal with.
Comments, thoughts anyone?
I guess it's time to have a look at the connect(2) source ....
>
> Signed-off-by: Paulo Andrade <pcpa@gnu.org>
> ---
> src/clnt_vc.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/src/clnt_vc.c b/src/clnt_vc.c
> index 0da18ca..0f018d5 100644
> --- a/src/clnt_vc.c
> +++ b/src/clnt_vc.c
> @@ -233,15 +233,16 @@ clnt_vc_create(fd, raddr, prog, vers, sendsz, recvsz)
> assert(vc_cv != (cond_t *) NULL);
>
> /*
> - * XXX - fvdl connecting while holding a mutex?
> + * Do not hold mutex during connect
> */
> + mutex_unlock(&clnt_fd_lock);
> +
> slen = sizeof ss;
> if (getpeername(fd, (struct sockaddr *)&ss, &slen) < 0) {
> if (errno != ENOTCONN) {
> struct rpc_createerr *ce = &get_rpc_createerr();
> ce->cf_stat = RPC_SYSTEMERROR;
> ce->cf_error.re_errno = errno;
> - mutex_unlock(&clnt_fd_lock);
> thr_sigsetmask(SIG_SETMASK, &(mask), NULL);
> goto err;
> }
> @@ -249,12 +250,10 @@ clnt_vc_create(fd, raddr, prog, vers, sendsz, recvsz)
> struct rpc_createerr *ce = &get_rpc_createerr();
> ce->cf_stat = RPC_SYSTEMERROR;
> ce->cf_error.re_errno = errno;
> - mutex_unlock(&clnt_fd_lock);
> thr_sigsetmask(SIG_SETMASK, &(mask), NULL);
> goto err;
> }
> }
> - mutex_unlock(&clnt_fd_lock);
> if (!__rpc_fd2sockinfo(fd, &si))
> goto err;
> thr_sigsetmask(SIG_SETMASK, &(mask), NULL);
next prev parent reply other threads:[~2016-05-20 2:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1463593885-1179-1-git-send-email-pcpa@gnu.org>
2016-05-19 15:35 ` [PATCH v2 0/3] Do not hold clnt_fd_lock mutex during connect Paulo Andrade
2016-05-19 15:35 ` [PATCH 1/3] Make it clear rpc_createerr is thread safe Paulo Andrade
2016-05-19 23:51 ` [Libtirpc-devel] " Ian Kent
2016-06-02 14:50 ` Steve Dickson
2016-05-19 15:35 ` [PATCH 2/3] Record errno value before calling syslog Paulo Andrade
2016-06-02 14:51 ` [Libtirpc-devel] " Steve Dickson
2016-05-19 15:35 ` [PATCH 3/3] Do not hold a global mutex during connect Paulo Andrade
2016-05-20 2:00 ` Ian Kent [this message]
2016-06-02 14:51 ` [Libtirpc-devel] " Steve Dickson
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=1463709636.3034.55.camel@redhat.com \
--to=ikent@redhat.com \
--cc=libtirpc-devel@lists.sourceforge.net \
--cc=linux-nfs@vger.kernel.org \
--cc=paulo.cesar.pereira.de.andrade@gmail.com \
--cc=pcpa@gnu.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.