<html><body>
<p>I realize that address translation will be replaced shortly. However, here are a few things that<br>
I observed which I believe are important. I recently saw an e-mail thread about compilation problems and <br>
data structure padding; this is in line with that.<br>
<br>
So that new incarnation does not face the same pitfalls of address translation, I will describe them here.<br>
<br>
When I tried running uatt it fails with -EFAULT. Debug revealed that it fails. The following <br>
copy_from_user() fails.<br>
<br>
ib_route = kmalloc(sizeof *ib_route, GFP_KERNEL);<br>
if (!ib_route) {<br>
result = -ENOMEM;<br>
goto err1;<br>
}<br>
<br>
if (copy_from_user(ib_route, cmd.ib_route, sizeof(ib_route))) {<br>
result = -EFAULT;<br>
goto err2;<br>
}<br>
<br>
In fact I believe this copy_from_user() is unnecessary since this will be actually filled in by "address translation" and <br>
passed back to user space later on. So, if I eliminate this copy_from_user(), uatt again fails with EFAULT in:<br>
<br>
if (copy_to_user((void __user *)(unsigned long)cmd.response,<br>
&resp, sizeof(resp))) {<br>
result = -EFAULT;<br>
goto err4;<br>
}<br>
<br>
The environment I was using a 32-bit app and 64-bit kernel on Power. The reason is <br>
struct ib_uat_route_by_ip_req has pointers in them (LP64 vs ILP32).<br>
<br>
I am told a 64-bit app succeeded on a 64-bit kernel which confirmed my suspicions.<br>
<br>
Given that I took a quick look at all the places that copy_from_user() is used (I did not<br>
do this exercise for copy_to_user(), which would be the complete thing to do) and found <br>
that this (data structure size mismatch) potentially also occurs in user_mad,c. I did not see any anomalies<br>
in ucm and uverbs. <br>
<br>
Comments from people who are more familair with the code?<br>
<br>
Pradeep<br>
pradeep@us.ibm.com</body></html>