From: Tom Tucker <tom@opengridcomputing.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [RFC,PATCH 0/8] RDMA Transport Provider
Date: Fri, 30 Nov 2007 09:59:28 -0600 [thread overview]
Message-ID: <1196438368.5432.10.camel@trinity.ogc.int> (raw)
In-Reply-To: <20071130044553.GA29851@fieldses.org>
On Thu, 2007-11-29 at 23:45 -0500, J. Bruce Fields wrote:
> On Thu, Nov 29, 2007 at 04:44:12PM -0600, Tom Tucker wrote:
> > This patchset implements the RDMA Transport Driver for the=20
[...snip...]
I resent the two offending patches with fixes as required.
> I still need the following to get it to compile. Also, I'm getting
> these warnings:
>=20
> net/sunrpc/svc_rdma_transport.c: In function =E2=80=98dto_tasklet_fun=
c=E2=80=99:
> net/sunrpc/svc_rdma_transport.c:232: warning: passing argument 2 of =E2=
=80=98test_and_clear_bit=E2=80=99 from incompatible pointer type
> net/sunrpc/svc_rdma_transport.c:241: warning: passing argument 2 of =E2=
=80=98constant_test_bit=E2=80=99 from incompatible pointer type
> net/sunrpc/svc_rdma_transport.c:241: warning: passing argument 2 of =E2=
=80=98variable_test_bit=E2=80=99 from incompatible pointer type
> net/sunrpc/svc_rdma_transport.c:245: warning: passing argument 2 of =E2=
=80=98test_and_clear_bit=E2=80=99 from incompatible pointer type
> net/sunrpc/svc_rdma_transport.c: In function =E2=80=98rq_comp_handler=
=E2=80=99:
> net/sunrpc/svc_rdma_transport.c:271: warning: passing argument 2 of =E2=
=80=98set_bit=E2=80=99 from incompatible pointer type
> net/sunrpc/svc_rdma_transport.c: In function =E2=80=98sq_comp_handler=
=E2=80=99:
> net/sunrpc/svc_rdma_transport.c:382: warning: passing argument 2 of =E2=
=80=98set_bit=E2=80=99 from incompatible pointer type
> net/sunrpc/svc_rdma_transport.c: In function =E2=80=98rdma_cma_handle=
r=E2=80=99:
> net/sunrpc/svc_rdma_transport.c:617: warning: passing argument 2 of =E2=
=80=98clear_bit=E2=80=99 from incompatible pointer type
> net/sunrpc/svc_rdma_transport.c: In function =E2=80=98svc_rdma_accept=
=E2=80=99:
> net/sunrpc/svc_rdma_transport.c:848: warning: passing argument 2 of =E2=
=80=98set_bit=E2=80=99 from incompatible pointer type
>=20
I'm mystified as to why I didn't get these warnings. I built on a 64 bi=
t
machine. It seems like that would give the warning since unsigned long
isn't even the same size as int.
> --b.
>=20
>=20
> commit d128e461892e6aa5332e1b87d0f94eba4728ee90
> Author: akpm@linux-foundation.org <akpm@linux-foundation.org>
> Date: Tue Nov 20 01:10:43 2007 -0800
>=20
> git-nfsd build fix
> =20
> From: Andrew Morton <akpm@linux-foundation.org>
> =20
> net/sunrpc/svcsock.c: In function 'svc_reclassify_socket':
> net/sunrpc/svcsock.c:100: error: 'struct sock' has no member name=
d 'sk_xprt'
> =20
> Cc: "J. Bruce Fields" <bfields@fieldses.org>
> Cc: Neil Brown <neilb@suse.de>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>=20
> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> index 03207c9..2d0405a 100644
> --- a/net/sunrpc/svcsock.c
> +++ b/net/sunrpc/svcsock.c
> @@ -97,7 +97,6 @@ static struct lock_class_key svc_slock_key[2];
> static inline void svc_reclassify_socket(struct socket *sock)
> {
> struct sock *sk =3D sock->sk;
> - BUG_ON(sk->sk_xprt.xpt_lock.owner !=3D NULL);
Somehow when I merged up to 2.6.24, this got merged incorrectly. The ne=
w
version still has the bug_on, but with the original argument.
> switch (sk->sk_family) {
> case AF_INET:
> sock_lock_init_class_and_name(sk, "slock-AF_INET-NFSD",
> -
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" =
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2007-11-30 15:55 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-29 22:44 [RFC,PATCH 0/8] RDMA Transport Provider Tom Tucker
[not found] ` <20071129224412.14887.14136.stgit-gUwIgmpLGaKNDNWfRnPdfg@public.gmane.org>
2007-11-29 22:45 ` [RFC,PATCH 1/8] rdma: SVCRMDA Header File Tom Tucker
2007-11-29 22:45 ` [RFC,PATCH 2/8] rdma: SVCRDMA Transport Module Tom Tucker
2007-11-29 22:45 ` [RFC,PATCH 3/8] rdma: SVCRDMA Core Transport Services Tom Tucker
2007-11-29 22:45 ` [RFC,PATCH 4/8] rdma: SVCRDMA recvfrom Tom Tucker
2007-11-29 22:45 ` [RFC,PATCH 5/8] rdma: SVCRDMA sendto Tom Tucker
2007-11-29 22:45 ` [RFC,PATCH 6/8] rdma: ONCRPC RDMA protocol marshalling Tom Tucker
2007-11-29 22:45 ` [RFC,PATCH 7/8] rdma: makefile Tom Tucker
[not found] ` <20071129224513.14887.8074.stgit-gUwIgmpLGaKNDNWfRnPdfg@public.gmane.org>
2007-12-03 17:00 ` Chuck Lever
2007-12-03 17:24 ` Tom Tucker
[not found] ` <1196702699.5811.0.camel-SMNkleLxa3ZimH42XvhXlA@public.gmane.org>
2007-12-03 17:25 ` J. Bruce Fields
2007-12-03 17:26 ` Tom Tucker
2007-12-03 17:08 ` [RFC,PATCH 7/8] rdma: makefile (second thread) Chuck Lever
2007-12-03 20:29 ` James Lentini
[not found] ` <Pine.LNX.4.64.0712031524250.7142-5zmYZXM8ymTNoO61VEKW3MYxy48AqY0ZOQ4dku92ua4@public.gmane.org>
2007-12-03 20:52 ` Chuck Lever
2007-12-03 22:29 ` James Lentini
[not found] ` <Pine.LNX.4.64.0712031656150.7142-5zmYZXM8ymTNoO61VEKW3MYxy48AqY0ZOQ4dku92ua4@public.gmane.org>
2007-12-04 0:52 ` Chuck Lever
2007-12-04 23:04 ` James Lentini
[not found] ` <Pine.LNX.4.64.0712041800270.7142-5zmYZXM8ymTNoO61VEKW3MYxy48AqY0ZOQ4dku92ua4@public.gmane.org>
2007-12-05 3:08 ` Chuck Lever
2007-11-29 22:45 ` [RFC,PATCH 8/8] rdma: Kconfig Tom Tucker
2007-11-30 4:45 ` [RFC,PATCH 0/8] RDMA Transport Provider J. Bruce Fields
2007-11-30 15:59 ` Tom Tucker [this message]
[not found] ` <1196438368.5432.10.camel-SMNkleLxa3ZimH42XvhXlA@public.gmane.org>
2007-11-30 17:16 ` J. Bruce Fields
2007-11-30 19:41 ` Tom Tucker
[not found] ` <1196451693.5432.35.camel-SMNkleLxa3ZimH42XvhXlA@public.gmane.org>
2007-11-30 20:48 ` Chuck Lever
2007-11-30 20:50 ` Tom Tucker
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=1196438368.5432.10.camel@trinity.ogc.int \
--to=tom@opengridcomputing.com \
--cc=bfields@fieldses.org \
--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 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.