[openib-general] Data structure size mismatch

[Hal Rosenstock]

On Fri, 2005-11-04 at 17:06, Pradeep Satyanarayana wrote:
> I realize that address translation will be replaced shortly. However,
> here are a few things that
> I observed which I believe are important. 

Important to fix in what time frame ?

> 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.

Not always. If I recall correctly, there is a case where this copy is
needed. It is not in the mode that uatt uses AT right now though.

>  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).

This needs to be replaced by the port GID. Another alternative is the
name. This has been discussed before on the list.

-- Hal

> 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
> 
> ______________________________________________________________________
> 
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general