All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aaron Straus <aaron-bYFJunmd+ZV8UrSeD/g0lQ@public.gmane.org>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Ben Myers <bpm@sgi.com>,
	bfields@fieldses.org, linux-nfs@vger.kernel.org, neilb@suse.de
Subject: Re: [PATCH] sunrpc: xprt is not connected until after sock is set
Date: Fri, 27 Feb 2009 17:34:57 -0800	[thread overview]
Message-ID: <20090228013457.GF7706@merfinllc.com> (raw)
In-Reply-To: <1235781463.20549.33.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>

Hi Trond,

On Feb 27 07:37 PM, Trond Myklebust wrote:
> NACK. If you need a memory barrier, put it in the UDP case only (and
> justify why). The TCP case sets and clears the above in the
> connect/disconnect softirqs and so does not require them.
> 
> I certainly see no reason whatsoever for adding memory barriers to
> xprt_connected() or xprt_clear_connected().
> 
> >  static inline int xprt_test_and_set_connected(struct rpc_xprt *xprt)
> > Index: linux-2.6.27.15-2/net/sunrpc/xprtsock.c
> > ===================================================================
> > --- linux-2.6.27.15-2.orig/net/sunrpc/xprtsock.c
> > +++ linux-2.6.27.15-2/net/sunrpc/xprtsock.c
> > @@ -1512,14 +1512,13 @@ static void xs_udp_finish_connecting(str
> >  		sk->sk_no_check = UDP_CSUM_NORCV;
> >  		sk->sk_allocation = GFP_ATOMIC;
> >  
> > -		xprt_set_connected(xprt);
> > -
> >  		/* Reset to new socket */
> >  		transport->sock = sock;
> >  		transport->inet = sk;
> >  
> >  		xs_set_memalloc(xprt);
> >  
> > +		xprt_set_connected(xprt);
> >  		write_unlock_bh(&sk->sk_callback_lock);
> >  	}
> >  	xs_udp_do_set_buffer_size(xprt);
> 
> Please move that call to xprt_set_connected() outside the if statement.
> We want to set the connected flag unconditionally here.

FYI, I've been digging a bit.  This commit adds the clearing of the
bits:

commit b6ddf64ffe9d59577a9176856bb6fe69a539f573
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Thu Apr 17 18:52:19 2008 -0400

    SUNRPC: Fix up xprt_write_space()
    
<snip>

@@ -588,19 +603,20 @@ static int xs_udp_send_request(struct rpc_task *task)
 	}
 
 	switch (status) {
+	case -EAGAIN:
+		xs_nospace(task);
+		break;
 	case -ENETUNREACH:
 	case -EPIPE:
 	case -ECONNREFUSED:
 		/* When the server has died, an ICMP port unreachable message
 		 * prompts ECONNREFUSED. */
-		break;
-	case -EAGAIN:
-		xs_nospace(task);
+		clear_bit(SOCK_ASYNC_NOSPACE, &transport->sock->flags);
 		break;
 	default:
+		clear_bit(SOCK_ASYNC_NOSPACE, &transport->sock->flags);
 		dprintk("RPC:       sendmsg returned unrecognized error %d\n",
 			-status);
-		break;
 	}
 
 	return status;


This went in to 2.6.26 which was the first time we saw the bug
(2.6.26.3) on kerneloops.

I don't know if *this* is a bad commit or some other locking changed in
2.6.26 which tickles the bug.

Hope it helps.  Have a good weekend all!

				=a=

-- 
===================
Aaron Straus
aaron-bYFJunmd+ZV8UrSeD/g0lQ@public.gmane.org

  parent reply	other threads:[~2009-02-28  1:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-23 20:11 BUG NULL pointer dereference in SUNRPC xs_udp_send_request Aaron Straus
2009-02-23 20:11 ` Aaron Straus
     [not found] ` <20090223201108.GB3308-bYFJunmd+ZV8UrSeD/g0lQ@public.gmane.org>
2009-02-25  2:39   ` Ben Myers
2009-02-25  2:39     ` Ben Myers
2009-02-26  0:17     ` Aaron Straus
2009-02-26  0:17       ` Aaron Straus
     [not found]       ` <20090226001744.GB7613-bYFJunmd+ZV8UrSeD/g0lQ@public.gmane.org>
2009-02-27 23:54         ` [PATCH] sunrpc: xprt is not connected until after sock is set Ben Myers
2009-02-28  0:37           ` Trond Myklebust
     [not found]             ` <1235781463.20549.33.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-02-28  1:34               ` Aaron Straus [this message]
     [not found]                 ` <20090228013457.GF7706-bYFJunmd+ZV8UrSeD/g0lQ@public.gmane.org>
2009-02-28  1:40                   ` Trond Myklebust
     [not found]                     ` <1235785237.20549.51.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-02-28  4:57                       ` Aaron Straus
2009-02-28  5:07                       ` Aaron Straus
     [not found]                         ` <20090228050707.GB22330-bYFJunmd+ZV8UrSeD/g0lQ@public.gmane.org>
2009-02-28 18:09                           ` Trond Myklebust
     [not found]                             ` <1235844568.7677.9.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-03-02 16:36                               ` Ben Myers
2009-03-02 16:39                                 ` Chuck Lever

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=20090228013457.GF7706@merfinllc.com \
    --to=aaron-byfjunmd+zv8ursed/g0lq@public.gmane.org \
    --cc=Trond.Myklebust@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=bpm@sgi.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    /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.