From: Gustavo Padovan <[email protected]>
struct sync_merge_data already have documentation on top of the
struct definition. No need to duplicate it.
Signed-off-by: Gustavo Padovan <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
---
drivers/staging/android/uapi/sync.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
index a0cf357..4467c76 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -21,9 +21,9 @@
* @fence: returns the fd of the new fence to userspace
*/
struct sync_merge_data {
- __s32 fd2; /* fd of second fence */
- char name[32]; /* name of new fence */
- __s32 fence; /* fd on newly created fence */
+ __s32 fd2;
+ char name[32];
+ __s32 fence;
};
/**
--
2.5.0
From: Gustavo Padovan <[email protected]>
This function had copies in 3 different files. Unify them in kernel.h.
Cc: Andrew Morton <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Rob Clark <[email protected]>
Signed-off-by: Gustavo Padovan <[email protected]>
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 5 -----
drivers/gpu/drm/i915/i915_drv.h | 5 -----
drivers/gpu/drm/msm/msm_gem_submit.c | 5 -----
include/linux/kernel.h | 5 +++++
4 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 1aba01a..b1fafb6 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -28,11 +28,6 @@
#define BO_LOCKED 0x4000
#define BO_PINNED 0x2000
-static inline void __user *to_user_ptr(u64 address)
-{
- return (void __user *)(uintptr_t)address;
-}
-
static struct etnaviv_gem_submit *submit_create(struct drm_device *dev,
struct etnaviv_gpu *gpu, size_t nr)
{
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b0847b9..c446895 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3564,11 +3564,6 @@ static inline i915_reg_t i915_vgacntrl_reg(struct drm_device *dev)
return VGACNTRL;
}
-static inline void __user *to_user_ptr(u64 address)
-{
- return (void __user *)(uintptr_t)address;
-}
-
static inline unsigned long msecs_to_jiffies_timeout(const unsigned int m)
{
unsigned long j = msecs_to_jiffies(m);
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c
index 6d7cd3f..e9c8b96 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -28,11 +28,6 @@
#define BO_LOCKED 0x4000
#define BO_PINNED 0x2000
-static inline void __user *to_user_ptr(u64 address)
-{
- return (void __user *)(uintptr_t)address;
-}
-
static struct msm_gem_submit *submit_create(struct drm_device *dev,
struct msm_gpu *gpu, int nr)
{
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index f31638c..c0a6001 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -53,6 +53,11 @@
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
+static inline void __user *to_user_ptr(u64 address)
+{
+ return (void __user *)(uintptr_t)address;
+}
+
/*
* This looks more complex than it should be. But we need to
* get the type for the ~ right in round_down (it needs to be
--
2.5.0
From: Gustavo Padovan <[email protected]>
Change SYNC_IOC_FILE_INFO (former SYNC_IOC_FENCE_INFO) behaviour to avoid
future API breaks and optimize buffer allocation.
Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than zero info->sync_fence_info should point to a buffer with enough space
to fit all fences.
However if num_fences passed to the kernel is 0, the kernel will reply
with number of fences of the sync_file.
Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
in a first call with num_fences = 0 userspace will receive the actual
number of fences in the num_fences filed.
Then it can allocate a buffer with the correct size on sync_fence_info and
call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
in the sync_file.
info->sync_fence_info was converted to __u64 pointer to prevent 32bit
compatibility issues. And a flags member was added.
An example userspace code for the later would be:
struct sync_file_info *info;
int err, size, num_fences;
info = malloc(sizeof(*info));
info.flags = 0;
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
num_fences = info->num_fences;
if (num_fences) {
info.flags = 0;
size = sizeof(struct sync_fence_info) * num_fences;
info->num_fences = num_fences;
info->sync_fence_info = (uint64_t) calloc(num_fences,
sizeof(struct sync_fence_info));
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
}
Finally the IOCTLs numbers were changed to avoid any potential old
userspace running the old API to get weird errors. Changing the opcodes
will make them fail right away. This is just a precaution, there no
upstream users of these interfaces yet and the only user is Android, but
we don't expect anyone trying to run android userspace and all it
dependencies on top of upstream kernels.
Signed-off-by: Gustavo Padovan <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Acked-by: Greg Hackmann <[email protected]>
Acked-by: Rob Clark <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
---
v2: fix fence_info memory leak
v3: Comments from Emil Velikov
- improve commit message
- remove __u64 cast
- remove check for output fields in file_info
- clean up sync_fill_fence_info()
Comments from Maarten Lankhorst
- remove in.num_fences && !in.sync_fence_info check
- remove info->len and use only num_fences to calculate size
Comments from Dan Carpenter
- fix info->sync_fence_info documentation
v4: remove allocated struct sync_file_info (comment from Maarten)
v5: merge all commits that were changing the ABI
v6: fix -Wint-to-pointer-cast error on info.sync_fence_info
---
drivers/staging/android/sync.c | 75 ++++++++++++++++++++-----------------
drivers/staging/android/uapi/sync.h | 36 +++++++++++++-----
2 files changed, 66 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3a8f210..1d9c530 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file *sync_file,
goto err_put_fd;
}
+ if (data.flags || data.pad) {
+ err = -EINVAL;
+ goto err_put_fd;
+ }
+
fence2 = sync_file_fdget(data.fd2);
if (!fence2) {
err = -ENOENT;
@@ -479,13 +484,9 @@ err_put_fd:
return err;
}
-static int sync_fill_fence_info(struct fence *fence, void *data, int size)
+static void sync_fill_fence_info(struct fence *fence,
+ struct sync_fence_info *info)
{
- struct sync_fence_info *info = data;
-
- if (size < sizeof(*info))
- return -ENOMEM;
-
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
sizeof(info->obj_name));
strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
@@ -495,58 +496,62 @@ static int sync_fill_fence_info(struct fence *fence, void *data, int size)
else
info->status = 0;
info->timestamp_ns = ktime_to_ns(fence->timestamp);
-
- return sizeof(*info);
}
static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
unsigned long arg)
{
- struct sync_file_info *info;
+ struct sync_file_info info;
+ struct sync_fence_info *fence_info = NULL;
__u32 size;
- __u32 len = 0;
int ret, i;
- if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
+ if (copy_from_user(&info, (void __user *)arg, sizeof(info)))
return -EFAULT;
- if (size < sizeof(struct sync_file_info))
+ if (info.flags || info.pad)
return -EINVAL;
- if (size > 4096)
- size = 4096;
-
- info = kzalloc(size, GFP_KERNEL);
- if (!info)
- return -ENOMEM;
-
- strlcpy(info->name, sync_file->name, sizeof(info->name));
- info->status = atomic_read(&sync_file->status);
- if (info->status >= 0)
- info->status = !info->status;
-
- len = sizeof(struct sync_file_info);
+ /*
+ * Passing num_fences = 0 means that userspace doesn't want to
+ * retrieve any sync_fence_info. If num_fences = 0 we skip filling
+ * sync_fence_info and return the actual number of fences on
+ * info->num_fences.
+ */
+ if (!info.num_fences)
+ goto no_fences;
- for (i = 0; i < sync_file->num_fences; ++i) {
- struct fence *fence = sync_file->cbs[i].fence;
+ if (info.num_fences < sync_file->num_fences)
+ return -EINVAL;
- ret = sync_fill_fence_info(fence, (u8 *)info + len, size - len);
+ size = sync_file->num_fences * sizeof(*fence_info);
+ fence_info = kzalloc(size, GFP_KERNEL);
+ if (!fence_info)
+ return -ENOMEM;
- if (ret < 0)
- goto out;
+ for (i = 0; i < sync_file->num_fences; ++i)
+ sync_fill_fence_info(sync_file->cbs[i].fence, &fence_info[i]);
- len += ret;
+ if (copy_to_user(to_user_ptr(info.sync_fence_info), fence_info, size)) {
+ ret = -EFAULT;
+ goto out;
}
- info->len = len;
+no_fences:
+ strlcpy(info.name, sync_file->name, sizeof(info.name));
+ info.status = atomic_read(&sync_file->status);
+ if (info.status >= 0)
+ info.status = !info.status;
+
+ info.num_fences = sync_file->num_fences;
- if (copy_to_user((void __user *)arg, info, len))
+ if (copy_to_user((void __user *)arg, &info, sizeof(info)))
ret = -EFAULT;
else
ret = 0;
out:
- kfree(info);
+ kfree(fence_info);
return ret;
}
@@ -560,7 +565,7 @@ static long sync_file_ioctl(struct file *file, unsigned int cmd,
case SYNC_IOC_MERGE:
return sync_file_ioctl_merge(sync_file, arg);
- case SYNC_IOC_FENCE_INFO:
+ case SYNC_IOC_FILE_INFO:
return sync_file_ioctl_fence_info(sync_file, arg);
default:
diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
index 4467c76..fbadb8a 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -16,14 +16,18 @@
/**
* struct sync_merge_data - data passed to merge ioctl
- * @fd2: file descriptor of second fence
* @name: name of new fence
+ * @fd2: file descriptor of second fence
* @fence: returns the fd of the new fence to userspace
+ * @flags: merge_data flags
+ * @pad: padding for 64-bit alignment, should always be zero
*/
struct sync_merge_data {
- __s32 fd2;
char name[32];
+ __s32 fd2;
__s32 fence;
+ __u32 flags;
+ __u32 pad;
};
/**
@@ -31,42 +35,54 @@ struct sync_merge_data {
* @obj_name: name of parent sync_timeline
* @driver_name: name of driver implementing the parent
* @status: status of the fence 0:active 1:signaled <0:error
+ * @flags: fence_info flags
* @timestamp_ns: timestamp of status change in nanoseconds
*/
struct sync_fence_info {
char obj_name[32];
char driver_name[32];
__s32 status;
+ __u32 flags;
__u64 timestamp_ns;
};
/**
* struct sync_file_info - data returned from fence info ioctl
- * @len: ioctl caller writes the size of the buffer its passing in.
- * ioctl returns length of sync_file_info returned to
- * userspace including pt_info.
* @name: name of fence
* @status: status of fence. 1: signaled 0:active <0:error
- * @sync_fence_info: array of sync_fence_info for every fence in the sync_file
+ * @flags: sync_file_info flags
+ * @num_fences number of fences in the sync_file
+ * @pad: padding for 64-bit alignment, should always be zero
+ * @sync_fence_info: pointer to array of structs sync_fence_info with all
+ * fences in the sync_file
*/
struct sync_file_info {
- __u32 len;
char name[32];
__s32 status;
+ __u32 flags;
+ __u32 num_fences;
+ __u32 pad;
- __u8 sync_fence_info[0];
+ __u64 sync_fence_info;
};
#define SYNC_IOC_MAGIC '>'
/**
+ * Opcodes 0, 1 and 2 were burned during a API change to avoid users of the
+ * old API to get weird errors when trying to handling sync_files. The API
+ * change happened during the de-stage of the Sync Framework when there was
+ * no upstream users available.
+ */
+
+/**
* DOC: SYNC_IOC_MERGE - merge two fences
*
* Takes a struct sync_merge_data. Creates a new fence containing copies of
* the sync_pts in both the calling fd and sync_merge_data.fd2. Returns the
* new fence's fd in sync_merge_data.fence
*/
-#define SYNC_IOC_MERGE _IOWR(SYNC_IOC_MAGIC, 1, struct sync_merge_data)
+#define SYNC_IOC_MERGE _IOWR(SYNC_IOC_MAGIC, 3, struct sync_merge_data)
/**
* DOC: SYNC_IOC_FENCE_INFO - get detailed information on a fence
@@ -79,6 +95,6 @@ struct sync_file_info {
* pt_info is a buffer containing sync_pt_infos for every sync_pt in the fence.
* To iterate over the sync_pt_infos, use the sync_pt_info.len field.
*/
-#define SYNC_IOC_FENCE_INFO _IOWR(SYNC_IOC_MAGIC, 2, struct sync_file_info)
+#define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info)
#endif /* _UAPI_LINUX_SYNC_H */
--
2.5.0
On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote:
> This function had copies in 3 different files. Unify them in
> kernel.h.
This is only used by gpu/drm.
I think this is a poor name for a generic function
that would be in kernel.h.
Isn't there an include file in linux/drm that's
appropriate for this. ?Maybe drmP.h
Maybe prefix this function name with drm_ too.
Also, there's this that might conflict:
arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)??????????ptr_to_compat(p)
arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)??????????((unsigned long)(p))
2016-03-17 Joe Perches <[email protected]>:
> On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote:
> > This function had copies in 3 different files. Unify them in
> > kernel.h.
>
> This is only used by gpu/drm.
>
> I think this is a poor name for a generic function
> that would be in kernel.h.
>
> Isn't there an include file in linux/drm that's
> appropriate for this. ?Maybe drmP.h
>
> Maybe prefix this function name with drm_ too.
No, the next patch adds a user to drivers/staging (which will be moved
to drivers/dma-buf) soon. Maybe move to a different header in
include/linux/? not sure which one.
> Also, there's this that might conflict:
>
> arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)??????????ptr_to_compat(p)
> arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)??????????((unsigned long)(p))
Right, I'll figure out how to replace these two too.
Gustavo
2016-03-17 Gustavo Padovan <[email protected]>:
> 2016-03-17 Joe Perches <[email protected]>:
>
> > On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote:
> > > This function had copies in 3 different files. Unify them in
> > > kernel.h.
> >
> > This is only used by gpu/drm.
> >
> > I think this is a poor name for a generic function
> > that would be in kernel.h.
> >
> > Isn't there an include file in linux/drm that's
> > appropriate for this. ?Maybe drmP.h
> >
> > Maybe prefix this function name with drm_ too.
>
> No, the next patch adds a user to drivers/staging (which will be moved
> to drivers/dma-buf) soon. Maybe move to a different header in
> include/linux/? not sure which one.
>
> > Also, there's this that might conflict:
> >
> > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)??????????ptr_to_compat(p)
> > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)??????????((unsigned long)(p))
>
> Right, I'll figure out how to replace these two too.
The powerpc to_user_ptr has a different meaning from the one I'm adding
in this patch. I propose we just rename powerpc's to_user_ptr to
__to_user_ptr and leave the rest as is.
Gustavo
On Thu, 2016-03-17 at 15:43 -0300, Gustavo Padovan wrote:
> 2016-03-17 Gustavo Padovan <[email protected]>:
> > 2016-03-17 Joe Perches <[email protected]>:
> > > On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote:
> > > >
> > > > This function had copies in 3 different files. Unify them in
> > > > kernel.h.
> > > This is only used by gpu/drm.
> > >
> > > I think this is a poor name for a generic function
> > > that would be in kernel.h.
> > >
> > > Isn't there an include file in linux/drm that's
> > > appropriate for this. ?Maybe drmP.h
> > >
> > > Maybe prefix this function name with drm_ too.
> > No, the next patch adds a user to drivers/staging (which will be moved
> > to drivers/dma-buf) soon. Maybe move to a different header in
> > include/linux/? not sure which one.
> >
> > >
> > > Also, there's this that might conflict:
> > >
> > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)??????????ptr_to_compat(p)
> > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)??????????((unsigned long)(p))
> > Right, I'll figure out how to replace these two too.
> The powerpc to_user_ptr has a different meaning from the one I'm adding
> in this patch. I propose we just rename powerpc's to_user_ptr to
> __to_user_ptr and leave the rest as is.
I think that's not a good idea, and you should really check
this concept with the powerpc folk (added to to:s and cc:ed)
If it were really added, then the function meaning is incorrect.
This is taking a u64, casting that to (unsigned long/uint_ptr_t),
then converting that to a user pointer.
Does that naming and use make sense on x86-32 or arm32?
On Thu, Mar 17, 2016 at 4:22 PM, Joe Perches <[email protected]> wrote:
> On Thu, 2016-03-17 at 15:43 -0300, Gustavo Padovan wrote:
>> 2016-03-17 Gustavo Padovan <[email protected]>:
>> > 2016-03-17 Joe Perches <[email protected]>:
>> > > On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote:
>> > > >
>> > > > This function had copies in 3 different files. Unify them in
>> > > > kernel.h.
>> > > This is only used by gpu/drm.
>> > >
>> > > I think this is a poor name for a generic function
>> > > that would be in kernel.h.
>> > >
>> > > Isn't there an include file in linux/drm that's
>> > > appropriate for this. Maybe drmP.h
>> > >
>> > > Maybe prefix this function name with drm_ too.
>> > No, the next patch adds a user to drivers/staging (which will be moved
>> > to drivers/dma-buf) soon. Maybe move to a different header in
>> > include/linux/? not sure which one.
>> >
>> > >
>> > > Also, there's this that might conflict:
>> > >
>> > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p) ptr_to_compat(p)
>> > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p) ((unsigned long)(p))
>> > Right, I'll figure out how to replace these two too.
>> The powerpc to_user_ptr has a different meaning from the one I'm adding
>> in this patch. I propose we just rename powerpc's to_user_ptr to
>> __to_user_ptr and leave the rest as is.
>
> I think that's not a good idea, and you should really check
> this concept with the powerpc folk (added to to:s and cc:ed)
>
> If it were really added, then the function meaning is incorrect.
>
> This is taking a u64, casting that to (unsigned long/uint_ptr_t),
> then converting that to a user pointer.
>
> Does that naming and use make sense on x86-32 or arm32?
>
fwiw Gustavo's version of to_user_ptr() is in use on arm32 and arm64..
Not entirely sure what doesn't make sense about it
BR,
-R
On Thu, 2016-03-17 at 16:33 -0400, Rob Clark wrote:
> On Thu, Mar 17, 2016 at 4:22 PM, Joe Perches <[email protected]> wrote:
> > On Thu, 2016-03-17 at 15:43 -0300, Gustavo Padovan wrote:
> > > 2016-03-17 Gustavo Padovan <[email protected]>:
> > > > 2016-03-17 Joe Perches <[email protected]>:
> > > > > On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote:
> > > > > > This function had copies in 3 different files. Unify them in
> > > > > > kernel.h.
> > > > > This is only used by gpu/drm.
> > > > >
> > > > > I think this is a poor name for a generic function
> > > > > that would be in kernel.h.
> > > > >
> > > > > Isn't there an include file in linux/drm that's
> > > > > appropriate for this.??Maybe drmP.h
> > > > >
> > > > > Maybe prefix this function name with drm_ too.
> > > > No, the next patch adds a user to drivers/staging (which will be moved
> > > > to drivers/dma-buf) soon. Maybe move to a different header in
> > > > include/linux/? not sure which one.
> > > >
> > > > >
> > > > >
> > > > > Also, there's this that might conflict:
> > > > >
> > > > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)??????????ptr_to_compat(p)
> > > > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p)??????????((unsigned long)(p))
> > > > Right, I'll figure out how to replace these two too.
> > > The powerpc to_user_ptr has a different meaning from the one I'm adding
> > > in this patch. I propose we just rename powerpc's to_user_ptr to
> > > __to_user_ptr and leave the rest as is.
> > I think that's not a good idea, and you should really check
> > this concept with the powerpc folk (added to to:s and cc:ed)
> >
> > If it were really added, then the function meaning is incorrect.
> >
> > This is taking a u64, casting that to (unsigned long/uint_ptr_t),
> > then converting that to a user pointer.
> >
> > Does that naming and use make sense on x86-32 or arm32?
> >
> fwiw Gustavo's version of to_user_ptr() is in use on arm32 and arm64..
> Not entirely sure what doesn't make sense about it
It's a name that seems like it should be a straightforward
cast of a kernel pointer to a __user pointer like:
static inline void __user *to_user_ptr(void *p)
{
return (void __user *)p;
}
As a static function in a single file, it's not
great, but OK, fine, it's static.
As a global function in kernel.h, it's misleading.
On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches <[email protected]> wrote:
> On Thu, 2016-03-17 at 16:33 -0400, Rob Clark wrote:
>> On Thu, Mar 17, 2016 at 4:22 PM, Joe Perches <[email protected]> wrote:
>> > On Thu, 2016-03-17 at 15:43 -0300, Gustavo Padovan wrote:
>> > > 2016-03-17 Gustavo Padovan <[email protected]>:
>> > > > 2016-03-17 Joe Perches <[email protected]>:
>> > > > > On Thu, 2016-03-17 at 14:30 -0300, Gustavo Padovan wrote:
>> > > > > > This function had copies in 3 different files. Unify them in
>> > > > > > kernel.h.
>> > > > > This is only used by gpu/drm.
>> > > > >
>> > > > > I think this is a poor name for a generic function
>> > > > > that would be in kernel.h.
>> > > > >
>> > > > > Isn't there an include file in linux/drm that's
>> > > > > appropriate for this. Maybe drmP.h
>> > > > >
>> > > > > Maybe prefix this function name with drm_ too.
>> > > > No, the next patch adds a user to drivers/staging (which will be moved
>> > > > to drivers/dma-buf) soon. Maybe move to a different header in
>> > > > include/linux/? not sure which one.
>> > > >
>> > > > >
>> > > > >
>> > > > > Also, there's this that might conflict:
>> > > > >
>> > > > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p) ptr_to_compat(p)
>> > > > > arch/powerpc/kernel/signal_32.c:#define to_user_ptr(p) ((unsigned long)(p))
>> > > > Right, I'll figure out how to replace these two too.
>> > > The powerpc to_user_ptr has a different meaning from the one I'm adding
>> > > in this patch. I propose we just rename powerpc's to_user_ptr to
>> > > __to_user_ptr and leave the rest as is.
>> > I think that's not a good idea, and you should really check
>> > this concept with the powerpc folk (added to to:s and cc:ed)
>> >
>> > If it were really added, then the function meaning is incorrect.
>> >
>> > This is taking a u64, casting that to (unsigned long/uint_ptr_t),
>> > then converting that to a user pointer.
>> >
>> > Does that naming and use make sense on x86-32 or arm32?
>> >
>> fwiw Gustavo's version of to_user_ptr() is in use on arm32 and arm64..
>> Not entirely sure what doesn't make sense about it
>
> It's a name that seems like it should be a straightforward
> cast of a kernel pointer to a __user pointer like:
>
> static inline void __user *to_user_ptr(void *p)
> {
> return (void __user *)p;
> }
ahh, ok. I guess I was used to using it in the context of ioctl
structs.. in that context u64 -> (void __user *) made more sense.
Maybe uapi_to_ptr()? (ok, not super-creative.. maybe someone has a better idea)
BR,
-R
> As a static function in a single file, it's not
> great, but OK, fine, it's static.
>
> As a global function in kernel.h, it's misleading.
>
>
On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
> On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches <[email protected]> wrote:
[]
> > It's a name that seems like it should be a straightforward
> > cast of a kernel pointer to a __user pointer like:
> >
> > static inline void __user *to_user_ptr(void *p)
> > {
> > ????????return (void __user *)p;
> > }
> ahh, ok.??I guess I was used to using it in the context of ioctl
> structs..??in that context u64 -> (void __user *) made more sense.
>
> Maybe uapi_to_ptr()???(ok, not super-creative.. maybe someone has a
> better idea)
Maybe u64_to_user_ptr?
2016-03-17 Joe Perches <[email protected]>:
> On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
> > On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches <[email protected]> wrote:
> []
> > > It's a name that seems like it should be a straightforward
> > > cast of a kernel pointer to a __user pointer like:
> > >
> > > static inline void __user *to_user_ptr(void *p)
> > > {
> > > ????????return (void __user *)p;
> > > }
> > ahh, ok.??I guess I was used to using it in the context of ioctl
> > structs..??in that context u64 -> (void __user *) made more sense.
> >
> > Maybe uapi_to_ptr()???(ok, not super-creative.. maybe someone has a
> > better idea)
>
> Maybe u64_to_user_ptr?
That is a good name. If everyone agrees I can resend this patch
changing it to u64_to_user_ptr. Then should we still keep it on
kernel.h?
Gustavo
On Thu, Mar 17, 2016 at 5:19 PM, Gustavo Padovan <[email protected]> wrote:
> 2016-03-17 Joe Perches <[email protected]>:
>
>> On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
>> > On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches <[email protected]> wrote:
>> []
>> > > It's a name that seems like it should be a straightforward
>> > > cast of a kernel pointer to a __user pointer like:
>> > >
>> > > static inline void __user *to_user_ptr(void *p)
>> > > {
>> > > return (void __user *)p;
>> > > }
>> > ahh, ok. I guess I was used to using it in the context of ioctl
>> > structs.. in that context u64 -> (void __user *) made more sense.
>> >
>> > Maybe uapi_to_ptr()? (ok, not super-creative.. maybe someone has a
>> > better idea)
>>
>> Maybe u64_to_user_ptr?
>
> That is a good name. If everyone agrees I can resend this patch
> changing it to u64_to_user_ptr. Then should we still keep it on
> kernel.h?
works for me
BR,
-R
On Thu, 2016-03-17 at 18:19 -0300, Gustavo Padovan wrote:
> 2016-03-17 Joe Perches <[email protected]>:
> > On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
> > > On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches <[email protected]> wrote:
> > []
> > > > It's a name that seems like it should be a straightforward
> > > > cast of a kernel pointer to a __user pointer like:
> > > >
> > > > static inline void __user *to_user_ptr(void *p)
> > > > {
> > > > ????????return (void __user *)p;
> > > > }
> > > ahh, ok.??I guess I was used to using it in the context of ioctl
> > > structs..??in that context u64 -> (void __user *) made more sense.
> > >
> > > Maybe uapi_to_ptr()???(ok, not super-creative.. maybe someone has a
> > > better idea)
> > Maybe u64_to_user_ptr?
> That is a good name. If everyone agrees I can resend this patch
> changing it to u64_to_user_ptr. Then should we still keep it on
> kernel.h?
I've no particular opinion about location,
but maybe compat.h might be appropriate.
Maybe add all variants:
void __user *u32_to_user_ptr(u32 val)
void __user *u64_to_user_ptr(u64 val)
u32 user_ptr_to_u32(void __user *p)
u64 user_ptr_to_u64(void __user *p)
Maybe there's something about 32 bit userspace on
64 OS that should be done too.
2016-03-17 Joe Perches <[email protected]>:
> On Thu, 2016-03-17 at 18:19 -0300, Gustavo Padovan wrote:
> > 2016-03-17 Joe Perches <[email protected]>:
> > > On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
> > > > On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches <[email protected]> wrote:
> > > []
> > > > > It's a name that seems like it should be a straightforward
> > > > > cast of a kernel pointer to a __user pointer like:
> > > > >
> > > > > static inline void __user *to_user_ptr(void *p)
> > > > > {
> > > > > return (void __user *)p;
> > > > > }
> > > > ahh, ok. I guess I was used to using it in the context of ioctl
> > > > structs.. in that context u64 -> (void __user *) made more sense.
> > > >
> > > > Maybe uapi_to_ptr()? (ok, not super-creative.. maybe someone has a
> > > > better idea)
> > > Maybe u64_to_user_ptr?
> > That is a good name. If everyone agrees I can resend this patch
> > changing it to u64_to_user_ptr. Then should we still keep it on
> > kernel.h?
>
> I've no particular opinion about location,
> but maybe compat.h might be appropriate.
I don't think this is really related to compat. I'd keep kernel.h.
The problem I'm trying to solve here is:
CC drivers/dma-buf/sync_file.o
drivers/dma-buf/sync_file.c: In function ‘sync_file_ioctl_fence_info’:
drivers/dma-buf/sync_file.c:341:19: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]
if (copy_to_user((void __user *)info.sync_fence_info, fence_info,
where info.sync_fence_info is __u64.
Gustavo
On Thu, Mar 17, 2016 at 02:33:50PM -0700, Joe Perches wrote:
> On Thu, 2016-03-17 at 18:19 -0300, Gustavo Padovan wrote:
> > 2016-03-17 Joe Perches <[email protected]>:
> > > On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
> > > > On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches <[email protected]> wrote:
> > > []
> > > > > It's a name that seems like it should be a straightforward
> > > > > cast of a kernel pointer to a __user pointer like:
> > > > >
> > > > > static inline void __user *to_user_ptr(void *p)
> > > > > {
> > > > > ????????return (void __user *)p;
> > > > > }
> > > > ahh, ok.??I guess I was used to using it in the context of ioctl
> > > > structs..??in that context u64 -> (void __user *) made more sense.
> > > >
> > > > Maybe uapi_to_ptr()???(ok, not super-creative.. maybe someone has a
> > > > better idea)
> > > Maybe u64_to_user_ptr?
> > That is a good name. If everyone agrees I can resend this patch
> > changing it to u64_to_user_ptr. Then should we still keep it on
> > kernel.h?
>
> I've no particular opinion about location,
> but maybe compat.h might be appropriate.
>
> Maybe add all variants:
>
> void __user *u32_to_user_ptr(u32 val)
> void __user *u64_to_user_ptr(u64 val)
> u32 user_ptr_to_u32(void __user *p)
> u64 user_ptr_to_u64(void __user *p)
>
> Maybe there's something about 32 bit userspace on
> 64 OS that should be done too.
Tbh I really don't think we should add 32bit variants and encourage the
mispractice of having 32bit user ptrs in ioctl structs and stuff. Anyway,
just my bikeshed on top ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch