[PATCH v9 1/3] staging/android: remove redundant comments on sync_merge_data

[PATCH v9 1/3] staging/android: remove redundant comments on sync_merge_data

[Gustavo Padovan]

From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

struct sync_merge_data already have documentation on top of the
struct definition. No need to duplicate it.

Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
---
 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

[PATCH v9 2/3] kernel.h: add to_user_ptr()

[Gustavo Padovan]

From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

This function had copies in 3 different files. Unify them in kernel.h.

Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
---
 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

[PATCH v9 3/3] staging/android: refactor SYNC IOCTLs

[Gustavo Padovan]

From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>

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 <gustavo.padovan@collabora.co.uk>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Greg Hackmann <ghackmann@google.com>
Acked-by: Rob Clark <robdclark@gmail.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

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

Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()

[Joe Perches]

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

Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()

[Gustavo Padovan]

2016-03-17 Joe Perches <joe@perches.com>:

> 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

Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()

[Gustavo Padovan]

2016-03-17 Gustavo Padovan <gustavo.padovan@collabora.co.uk>:

> 2016-03-17 Joe Perches <joe@perches.com>:
> 
> > 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

Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()

[Joe Perches]

On Thu, 2016-03-17 at 15:43 -0300, Gustavo Padovan wrote:
> 2016-03-17 Gustavo Padovan <gustavo.padovan@collabora.co.uk>:
> > 2016-03-17 Joe Perches <joe@perches.com>:
> > > 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?

Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()

[Rob Clark]

On Thu, Mar 17, 2016 at 4:22 PM, Joe Perches <joe@perches.com> wrote:
> On Thu, 2016-03-17 at 15:43 -0300, Gustavo Padovan wrote:
>> 2016-03-17 Gustavo Padovan <gustavo.padovan@collabora.co.uk>:
>> > 2016-03-17 Joe Perches <joe@perches.com>:
>> > > 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

Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()

[Joe Perches]

On Thu, 2016-03-17 at 16:33 -0400, Rob Clark wrote:
> On Thu, Mar 17, 2016 at 4:22 PM, Joe Perches <joe@perches.com> wrote:
> > On Thu, 2016-03-17 at 15:43 -0300, Gustavo Padovan wrote:
> > > 2016-03-17 Gustavo Padovan <gustavo.padovan@collabora.co.uk>:
> > > > 2016-03-17 Joe Perches <joe@perches.com>:
> > > > > 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.

Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()

[Rob Clark]

On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches <joe@perches.com> wrote:
> On Thu, 2016-03-17 at 16:33 -0400, Rob Clark wrote:
>> On Thu, Mar 17, 2016 at 4:22 PM, Joe Perches <joe@perches.com> wrote:
>> > On Thu, 2016-03-17 at 15:43 -0300, Gustavo Padovan wrote:
>> > > 2016-03-17 Gustavo Padovan <gustavo.padovan@collabora.co.uk>:
>> > > > 2016-03-17 Joe Perches <joe@perches.com>:
>> > > > > 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.
>
>

Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()

[Joe Perches]

On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
> On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches <joe@perches.com> 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?

Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()

[Gustavo Padovan]

2016-03-17 Joe Perches <joe@perches.com>:

> On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
> > On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches <joe@perches.com> 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

Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()

[Rob Clark]

On Thu, Mar 17, 2016 at 5:19 PM, Gustavo Padovan <gustavo@padovan.org> wrote:
> 2016-03-17 Joe Perches <joe@perches.com>:
>
>> On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
>> > On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches <joe@perches.com> 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

Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()

[Joe Perches]

On Thu, 2016-03-17 at 18:19 -0300, Gustavo Padovan wrote:
> 2016-03-17 Joe Perches <joe@perches.com>:
> > On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
> > > On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches <joe@perches.com> 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.

Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()

[Gustavo Padovan]

2016-03-17 Joe Perches <joe@perches.com>:

> On Thu, 2016-03-17 at 18:19 -0300, Gustavo Padovan wrote:
> > 2016-03-17 Joe Perches <joe@perches.com>:
> > > On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
> > > > On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches <joe@perches.com> 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

Re: [PATCH v9 2/3] kernel.h: add to_user_ptr()

[Daniel Vetter]

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 <joe@perches.com>:
> > > On Thu, 2016-03-17 at 16:50 -0400, Rob Clark wrote:
> > > > On Thu, Mar 17, 2016 at 4:40 PM, Joe Perches <joe@perches.com> 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