On Mon, 2009-04-27 at 12:37 -0500, Steve Wise wrote: > Tom Talpey wrote: > > At 02:57 PM 4/26/2009, Steve Wise wrote: > > > >> Hey Trond, > >> > >> Turns out the server side is fine. So this patch is good to go. > >> > > > > I'll ACK the patch, but I do wonder if the code will compile cleanly on all > > platforms. The iova_start is a u64, whereas the mr_dma is a dma_addr_t, > > which is variable sized, depending on platform. Would a (u64) cast be a > > safer patch, warning-wise? > > > > > > Well, if dma_addr_t is smaller, I don't think you'll get a warning, will > you? And if its larger than 64b, then you _want_ the warning, because > nothing will work. :) > > Its up to you and/or Trond. It looks looks as though the bug is really that the IB code is using a u64 to store dma handles. As an external user of the IB api, we really shouldn't have to perform this sort of transformation. If it is absolutely necessary, then it should be done by means of specialised accessor functions to initialise/read iova_start value when given a dma_addr_t. I'd therefore prefer the no-cast version (with eventual compiler warnings), in the hope that eventually the IB folks will fix their interface. Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
