| Message ID | 5851501.PBMrs03XFb@wuerfel (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Oct 06, 2015 at 10:37:11PM +0200, Arnd Bergmann wrote: > Compiling the nvme driver on 32-bit warns about a cast from a __u64 > variable to a pointer: > > drivers/block/nvme-core.c: In function 'nvme_submit_io': > drivers/block/nvme-core.c:1847:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] > (void __user *)io.addr, length, NULL, 0); > > The cast here is intentional and safe, so we can shut up the > gcc warning by adding an intermediate cast to 'unsigned long'. It really should be a uintptr_t, which would also avoid the > 80 character lines. I wonder if we need a u64_to_ptr helper given these ioctl ABIs that pass pointers as a u64 seems to be everywhere these days.
On Friday 09 October 2015 07:42:21 Christoph Hellwig wrote: > On Tue, Oct 06, 2015 at 10:37:11PM +0200, Arnd Bergmann wrote: > > Compiling the nvme driver on 32-bit warns about a cast from a __u64 > > variable to a pointer: > > > > drivers/block/nvme-core.c: In function 'nvme_submit_io': > > drivers/block/nvme-core.c:1847:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] > > (void __user *)io.addr, length, NULL, 0); > > > > The cast here is intentional and safe, so we can shut up the > > gcc warning by adding an intermediate cast to 'unsigned long'. > > It really should be a uintptr_t, which would also avoid the > 80 > character lines. I wonder if we need a u64_to_ptr helper given these > ioctl ABIs that pass pointers as a u64 seems to be everywhere these > days. I'll send a new version with uintptr_t for now, but having a proper interface for this sounds like a good idea. I've seen a couple of cases like this, and most but not all actually want a __user pointer like this one. That seems similar to the common ioctl use case where we want a user pointer from an 'unsigned long', so we could use the same function for both, like static inline void __user *get_uptr(unsigned long arg) { return (void __user *)arg; } With this definition, you can pass any scalar type (u64 or unsigned long normally) and get the pointer, and we can put that into include/linux/uaccess.h. Arnd
diff --git a/drivers/block/nvme-core.c b/drivers/block/nvme-core.c index e917cf304ad0..f9faf276ce74 100644 --- a/drivers/block/nvme-core.c +++ b/drivers/block/nvme-core.c @@ -1844,7 +1844,7 @@ static int nvme_submit_io(struct nvme_ns *ns, struct nvme_user_io __user *uio) c.rw.metadata = cpu_to_le64(meta_dma); status = __nvme_submit_sync_cmd(ns->queue, &c, NULL, - (void __user *)io.addr, length, NULL, 0); + (void __user *)(unsigned long)io.addr, length, NULL, 0); unmap: if (meta) { if (status == NVME_SC_SUCCESS && !write) { @@ -1886,7 +1886,7 @@ static int nvme_user_cmd(struct nvme_dev *dev, struct nvme_ns *ns, timeout = msecs_to_jiffies(cmd.timeout_ms); status = __nvme_submit_sync_cmd(ns ? ns->queue : dev->admin_q, &c, - NULL, (void __user *)cmd.addr, cmd.data_len, + NULL, (void __user *)(unsigned long)cmd.addr, cmd.data_len, &cmd.result, timeout); if (status >= 0) { if (put_user(cmd.result, &ucmd->result))
Compiling the nvme driver on 32-bit warns about a cast from a __u64 variable to a pointer: drivers/block/nvme-core.c: In function 'nvme_submit_io': drivers/block/nvme-core.c:1847:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] (void __user *)io.addr, length, NULL, 0); The cast here is intentional and safe, so we can shut up the gcc warning by adding an intermediate cast to 'unsigned long'. I had previously submitted a patch to fix this problem in the nvme driver, but it was accepted on the same day that two new warnings got added. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: d29ec8241c10e ("nvme: submit internal commands through the block layer")