On Sun, 6 Mar 2011 13:40:43 +0100 (CET) "Rafael J. Wysocki" <[email protected]> wrote:
> This message has been generated automatically as a part of a report > of regressions introduced between 2.6.36 and 2.6.37. > > The following bug entry is on the current list of known regressions > introduced between 2.6.36 and 2.6.37. Please verify if it still should > be listed and let the tracking team know (either way). > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=30322 > Subject : BUG in xs_tcp_setup_socket > Submitter : Ben Hutchings <[email protected]> > Date : 2011-03-01 20:34 (6 days old) > Patch : http://article.gmane.org/gmane.linux.nfs/38949 > Ben's patch is a no-brainer but it is not yet in mainline or linux-next. I'm not on linux-nfs so I recreated it as below. Subject: sunrpc: propagate errors from xs_bind() through xs_create_sock() From: Ben Hutchings <[email protected]> xs_create_sock() is supposed to return a pointer or an ERR_PTR-encoded error, but it currently returns 0 if xs_bind() fails. This causes the kernel to go BUG, as described in https://bugzilla.kernel.org/show_bug.cgi?id=30322. Signed-off-by: Ben Hutchings <[email protected]> Cc: David Miller <[email protected]> Cc: Trond Myklebust <[email protected]> Cc: "J. Bruce Fields" <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Maciej Rutecki <[email protected]> Signed-off-by: Andrew Morton <[email protected]> --- net/sunrpc/xprtsock.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN net/sunrpc/xprtsock.c~sunrpc-propagate-errors-from-xs_bind-through-xs_create_sock net/sunrpc/xprtsock.c --- a/net/sunrpc/xprtsock.c~sunrpc-propagate-errors-from-xs_bind-through-xs_create_sock +++ a/net/sunrpc/xprtsock.c @@ -1631,7 +1631,8 @@ static struct socket *xs_create_sock(str } xs_reclassify_socket(family, sock); - if (xs_bind(transport, sock)) { + err = xs_bind(transport, sock); + if (err) { sock_release(sock); goto out; } _ -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
