public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Roland Dreier <roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: [Patch libibverbs-1.1.5] Fix broken compat assumption on ppc arch
Date: Tue, 02 Aug 2011 15:15:11 -0400	[thread overview]
Message-ID: <4E384CBF.6080905@redhat.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

In the compat-1.0 wrapper, the post_send wrapper assumes that the layout 
of the tail end of the ibv_send_wr struct is the same in version 1.0 and 
1.1.  Unfortunately, padding of the struct makes this untrue depending 
on the architecture.  In my case, it was ppc that was failing to compile 
because we were triggering the gcc built in memcpy check.  We were 
scribbling past the end of the structure of the new structure because 
the old structure has alignment padding that the new one doesn't.  There 
are two spots that are padded in the version 1.0 ibv_send_wr struct, 4 
bytes before sg_list, and 4 more bytes before wr.

So this patch conditionalizes whether or not we use memcpy on the basis 
of data that will be reduced to constants at compile time, so even 
though there is an if statement, it gets reduced to just the proper 
method for the given arch at compile time.  And the patch will attempt a 
simple memcpy if possible, or two memcpy's in the case that wr needed 
padding to be aligned (as is the case on ppc), and fall back to field 
based copy just in case this is compiled on some arch with really odd 
field alignment characteristics.

Signed-off-by: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

[-- Attachment #2: libibverbs-1.1.5-memcpy.patch --]
[-- Type: text/plain, Size: 2062 bytes --]

diff -up libibverbs-1.1.5/src/compat-1_0.c.memcpy libibverbs-1.1.5/src/compat-1_0.c
--- libibverbs-1.1.5/src/compat-1_0.c.memcpy	2011-06-28 17:13:45.000000000 -0400
+++ libibverbs-1.1.5/src/compat-1_0.c	2011-08-02 12:07:20.114511405 -0400
@@ -350,8 +350,46 @@ static int post_send_wrapper_1_0(struct 
 		real_wr->wr_id = w->wr_id;
 		real_wr->next  = NULL;
 
-		memcpy(&real_wr->sg_list, &w->sg_list,
-		       sizeof *w - offsetof(struct ibv_send_wr, sg_list));
+#define TEST_SIZE_2_POINT(f1, f2) \
+((offsetof(struct ibv_send_wr, f1) - offsetof(struct ibv_send_wr, f2)) \
+== offsetof(struct ibv_send_wr_1_0, f1) - offsetof(struct ibv_send_wr_1_0, f2))
+#define TEST_SIZE_TO_END(f1) \
+((sizeof(struct ibv_send_wr) - offsetof(struct ibv_send_wr, f1)) == \
+ (sizeof(struct ibv_send_wr_1_0) - offsetof(struct ibv_send_wr_1_0, f1)))
+
+		if (TEST_SIZE_TO_END (sg_list))
+			memcpy(&real_wr->sg_list, &w->sg_list, sizeof *real_wr
+			       - offsetof(struct ibv_send_wr, sg_list));
+		else if (TEST_SIZE_2_POINT (imm_data, sg_list) &&
+			 TEST_SIZE_TO_END (wr)) {
+			/* we have alignment up to wr, but padding between
+			 * imm_data and wr, and we know wr itself is the
+			 * same size */
+			memcpy(&real_wr->sg_list, &w->sg_list,
+			       offsetof(struct ibv_send_wr, imm_data) -
+			       offsetof(struct ibv_send_wr, sg_list) +
+			       sizeof real_wr->imm_data);
+			memcpy(&real_wr->wr, &w->wr, sizeof real_wr->wr);
+		} else {
+			real_wr->sg_list = w->sg_list;
+			real_wr->num_sge = w->num_sge;
+			real_wr->opcode = w->opcode;
+			real_wr->send_flags = w->send_flags;
+			real_wr->imm_data = w->imm_data;
+			if (TEST_SIZE_TO_END (wr))
+				memcpy(&real_wr->wr, &w->wr,
+				       sizeof real_wr->wr);
+			else {
+				real_wr->wr.atomic.remote_addr = 
+					w->wr.atomic.remote_addr;
+				real_wr->wr.atomic.compare_add = 
+					w->wr.atomic.compare_add;
+				real_wr->wr.atomic.swap = 
+					w->wr.atomic.swap;
+				real_wr->wr.atomic.rkey = 
+					w->wr.atomic.rkey;
+			}
+		}
 
 		if (is_ud)
 			real_wr->wr.ud.ah = w->wr.ud.ah->real_ah;

                 reply	other threads:[~2011-08-02 19:15 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=4E384CBF.6080905@redhat.com \
    --to=dledford-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox