Re: BUG NULL pointer dereference in SUNRPC xs_udp_send_request

[Aaron Straus <aaron-bYFJunmd+ZV8UrSeD/g0lQ@public.gmane.org>]

Hi Ben,

Thanks for the response.

On Feb 24 08:39 PM, Ben Myers wrote:
> >   If I'm reading the trace correctly, it looks like this line of
> > xs_udp_send_request:
> > 
> >    clear_bit(SOCK_ASYNC_NOSPACE, &transport->sock->flags);
> 
> That's a coincidence.  I looked at a similar bug today that crashed on
> the same line but a different stack.  My suggestion is:
> 
> Index: linux/net/sunrpc/xprtsock.c
> ===================================================================
> --- linux.orig/net/sunrpc/xprtsock.c
> +++ linux/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);
> 
> Looks like xs_sendpages() returned -ENOTCONN.  The above should sort
> that out by returning earlier in xprt_prepare_transmit() and the rpc
> would be retried by __rpc_execute().

I'll start running with it tonight to see if I can trigger the BUG
again (it was hard to hit).

Quick question, do we need a barrier between setting the transport->sock
and the xprt_set_connected(xprt)?  I don't really understand the locking
on the reader side, so I cannot say...

Also, out of curiosity, do you know what changed to introduce the BUG?

Kerneloops doesn't seem to know about it before 2.6.26.3:

  http://www.kerneloops.org/search.php?search=xs_udp_send_request&btnG=Function+Search

Anyway, thanks!

					=a=



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