linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@hammerspace.com>
To: "bcodding@redhat.com" <bcodding@redhat.com>,
	"Anna.Schumaker@netapp.com" <Anna.Schumaker@netapp.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"jamespharvey20@gmail.com" <jamespharvey20@gmail.com>
Subject: Re: [PATCH] SUNRPC: fix race to sk_err after xs_error_report
Date: Tue, 1 Oct 2019 19:38:31 +0000	[thread overview]
Message-ID: <d9bf3f1092ed0361cc344e04a915ea337a3aa9e8.camel@hammerspace.com> (raw)
In-Reply-To: <9796ba15d926f65923965c2aedf777aaa59861e8.1569954618.git.bcodding@redhat.com>

On Tue, 2019-10-01 at 14:30 -0400, Benjamin Coddington wrote:
> Since commit 4f8943f80883 ("SUNRPC: Replace direct task wakeups from
> softirq context") there has been a race to the value of the sk_err if
> both
> XPRT_SOCK_WAKE_ERROR and XPRT_SOCK_WAKE_DISCONNECT are set.  In that
> case,
> we may end up losing the sk_err value that existed when
> xs_error_report was
> called.
> 
> Fix this by reverting to the previous behavior: instead of using
> SO_ERROR
> to retrieve the value at a later time (which might also return
> sk_err_soft),
> copy the sk_err value onto struct sock_xprt, and use that value to
> wake
> pending tasks.
> 
> Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
> Fixes: 4f8943f80883 ("SUNRPC: Replace direct task wakeups from
> softirq context")
> ---
>  include/linux/sunrpc/xprtsock.h |  1 +
>  net/sunrpc/xprtsock.c           | 13 +++++--------
>  2 files changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/include/linux/sunrpc/xprtsock.h
> b/include/linux/sunrpc/xprtsock.h
> index 7638dbe7bc50..8ffae73dea6c 100644
> --- a/include/linux/sunrpc/xprtsock.h
> +++ b/include/linux/sunrpc/xprtsock.h
> @@ -56,6 +56,7 @@ struct sock_xprt {
>  	 */
>  	unsigned long		sock_state;
>  	struct delayed_work	connect_worker;
> +	int			xprt_err;

Perhaps move this down just after srcport so we don't create an
unnecessary hole in the structure?

>  	struct work_struct	error_worker;
>  	struct work_struct	recv_worker;
>  	struct mutex		recv_mutex;
> diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
> index e2176c167a57..7fe77eef7080 100644
> --- a/net/sunrpc/xprtsock.c
> +++ b/net/sunrpc/xprtsock.c
> @@ -1250,12 +1250,12 @@ static void xs_error_report(struct sock *sk)
>  		goto out;
>  
>  	transport = container_of(xprt, struct sock_xprt, xprt);
> -	err = -sk->sk_err;
> -	if (err == 0)
> +	transport->xprt_err = -sk->sk_err;

Doesn't this need a smp write barrier to ensure it isn't reordered with
the set_bit() in xs_run_error_worker()?

> +	if (transport->xprt_err == 0)
>  		goto out;
>  	dprintk("RPC:       xs_error_report client %p, error=%d...\n",
> -			xprt, -err);
> -	trace_rpc_socket_error(xprt, sk->sk_socket, err);
> +			xprt, -transport->xprt_err);
> +	trace_rpc_socket_error(xprt, sk->sk_socket, transport-
> >xprt_err);
>  	xs_run_error_worker(transport, XPRT_SOCK_WAKE_ERROR);
>   out:
>  	read_unlock_bh(&sk->sk_callback_lock);
> @@ -2470,7 +2470,6 @@ static void xs_wake_write(struct sock_xprt
> *transport)
>  static void xs_wake_error(struct sock_xprt *transport)
>  {
>  	int sockerr;
> -	int sockerr_len = sizeof(sockerr);
>  
>  	if (!test_bit(XPRT_SOCK_WAKE_ERROR, &transport->sock_state))
>  		return;
> @@ -2479,9 +2478,7 @@ static void xs_wake_error(struct sock_xprt
> *transport)
>  		goto out;
>  	if (!test_and_clear_bit(XPRT_SOCK_WAKE_ERROR, &transport-
> >sock_state))
>  		goto out;
> -	if (kernel_getsockopt(transport->sock, SOL_SOCKET, SO_ERROR,
> -				(char *)&sockerr, &sockerr_len) != 0)
> -		goto out;
> +	sockerr = xchg(&transport->xprt_err, 0);
>  	if (sockerr < 0)
>  		xprt_wake_pending_tasks(&transport->xprt, sockerr);
>  out:
-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com



  reply	other threads:[~2019-10-01 19:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-01 18:30 [PATCH] SUNRPC: fix race to sk_err after xs_error_report Benjamin Coddington
2019-10-01 19:38 ` Trond Myklebust [this message]
2019-10-02 10:41   ` Benjamin Coddington

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=d9bf3f1092ed0361cc344e04a915ea337a3aa9e8.camel@hammerspace.com \
    --to=trondmy@hammerspace.com \
    --cc=Anna.Schumaker@netapp.com \
    --cc=bcodding@redhat.com \
    --cc=jamespharvey20@gmail.com \
    --cc=linux-nfs@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;
as well as URLs for NNTP newsgroup(s).