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 21:07:08 -0800 [thread overview]
Message-ID: <20090228050707.GB22330@merfinllc.com> (raw)
In-Reply-To: <1235785237.20549.51.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
On Feb 27 08:40 PM, Trond Myklebust wrote:
> > > > 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);
> > >
> >
> > @@ -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.
>
> It should be unrelated. If the client managed to get past the call to
> xs_sendpages(), then the UDP socket must obviously exist already.
PS just to repeat the previous discussion.
It seems like xs_sendpages does check if sock is NULL and returns
-ENOTCONN in that case.
The problem is that now in xs_udp_send_request falls into the default:
section of that switch statement and tries to do the:
> > + clear_bit(SOCK_ASYNC_NOSPACE, &transport->sock->flags);
but sock is NULL, so I think that's the oops.
Anyway, that's why Ben thinks we need to move xprt_set_connected() down
(past the setting of transport->sock) in xs_udp_finish_connecting().
I was worried without a barrier xprt_set_connected() could just move
back up before the setting of transport->sock again either by compiler
or CPU reordering.
Anyway that's where we are....
thanks!
=a=
--
===================
Aaron Straus
aaron-bYFJunmd+ZV8UrSeD/g0lQ@public.gmane.org
next prev parent reply other threads:[~2009-02-28 5:07 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
[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 [this message]
[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=20090228050707.GB22330@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.