[openib-general] Data structure size mismatch

[Pradeep Satyanarayana]

I realize that address translation will be replaced shortly. However, here
are a few things that
I observed which I believe are important. I recently saw an e-mail thread
about compilation problems and
data structure padding; this is in line with that.

So that new incarnation does not face the same pitfalls of address
translation, I will describe them here.

When I tried running uatt it fails with -EFAULT. Debug revealed that it
fails. The following
copy_from_user() fails.

ib_route = kmalloc(sizeof *ib_route, GFP_KERNEL);
if (!ib_route) {
      result = -ENOMEM;
       goto err1;
}

if (copy_from_user(ib_route, cmd.ib_route, sizeof(ib_route))) {
      result = -EFAULT;
      goto err2;
}

In fact I believe this copy_from_user() is unnecessary since this will be
actually filled in by "address translation" and
passed back to user space later on. So, if I eliminate this
copy_from_user(), uatt again fails with EFAULT in:

if (copy_to_user((void __user *)(unsigned long)cmd.response,
        &resp, sizeof(resp))) {
        result = -EFAULT;
        goto err4;
}

The environment I was using a 32-bit app and 64-bit kernel on Power. The
reason is
struct ib_uat_route_by_ip_req has pointers in them (LP64 vs ILP32).

I am told a 64-bit app succeeded on a 64-bit kernel which confirmed my
suspicions.

Given that I took a quick look at all the places that copy_from_user() is
used (I did not
do this exercise for copy_to_user(), which would be the complete thing to
do) and found
that this (data structure size mismatch) potentially also occurs in
user_mad,c. I did not see any anomalies
in ucm and uverbs.

Comments from people who are more familair with the code?

Pradeep
pradeep at us.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051104/c92fe664/attachment.html>