linux-kernel - Re: [PATCH v3 06/11] staging/android: turn fence_info into a _

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56B350D4.9060504@linux.intel.com>
Date:	Thu, 4 Feb 2016 14:23:32 +0100
From:	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
To:	Gustavo Padovan <gustavo.padovan@...labora.co.uk>
Cc:	Gustavo Padovan <gustavo@...ovan.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org,
	dri-devel@...ts.freedesktop.org,
	Daniel Stone <daniels@...labora.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Riley Andrews <riandrews@...roid.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Rob Clark <robdclark@...il.com>,
	Greg Hackmann <ghackmann@...gle.com>,
	John Harrison <John.C.Harrison@...el.com>
Subject: Re: [PATCH v3 06/11] staging/android: turn fence_info into a __u64
 pointer

Op 04-02-16 om 14:05 schreef Gustavo Padovan:
> 2016-02-04 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>:
>
>> Op 03-02-16 om 21:09 schreef Gustavo Padovan:
>>> Hi Maarten,
>>>
>>> 2016-02-03 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>:
>>>
>>>> Op 03-02-16 om 14:25 schreef Gustavo Padovan:
>>>>> From: Gustavo Padovan <gustavo.padovan@...labora.co.uk>
>>>>>
>>>>> Turn sync_fence_info into __u64 type enable us to extend the struct in the
>>>>> future without breaking the ABI.
>>>>>
>>>>> v2: use type __u64 for fence_info
>>>>>
>>>>> v3: fix commit message to reflect the v2 change
>>>>>
>>>>> Signed-off-by: Gustavo Padovan <gustavo.padovan@...labora.co.uk>
>>>>> ---
>>>>>  drivers/staging/android/sync.c      | 2 +-
>>>>>  drivers/staging/android/uapi/sync.h | 2 +-
>>>>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
>>>>> index 2ab0c20..8425457 100644
>>>>> --- a/drivers/staging/android/sync.c
>>>>> +++ b/drivers/staging/android/sync.c
>>>>> @@ -525,7 +525,7 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
>>>>>  	if (info->status >= 0)
>>>>>  		info->status = !info->status;
>>>>>  
>>>>> -	len = sizeof(struct sync_file_info);
>>>>> +	len = sizeof(struct sync_file_info) - sizeof(__u64);
>>>>>  
>>>>>  	for (i = 0; i < sync_file->num_fences; ++i) {
>>>>>  		struct fence *fence = sync_file->cbs[i].fence;
>>>>> diff --git a/drivers/staging/android/uapi/sync.h b/drivers/staging/android/uapi/sync.h
>>>>> index a0cf357..e649953 100644
>>>>> --- a/drivers/staging/android/uapi/sync.h
>>>>> +++ b/drivers/staging/android/uapi/sync.h
>>>>> @@ -54,7 +54,7 @@ struct sync_file_info {
>>>>>  	char	name[32];
>>>>>  	__s32	status;
>>>>>  
>>>>> -	__u8	sync_fence_info[0];
>>>>> +	__u64	sync_fence_info;
>>>>>  };
>>>>>  
>>>>>  #define SYNC_IOC_MAGIC		'>'
>>>> This still doesn't do what you expect it to.
>>>>
>>>> I think this is what you want is for userspace to do:
>>>>
>>>> struct sync_file_info info;
>>>>
>>>> info.flags = info.num_fences = 0;
>>>> ioctl(fd, SYNC_IOC_FENCE_INFO, &info);
>>>> if (info.num_fences) {
>>>> info.sync_fence_info = (uintptr)kcalloc(info.num_fences, sizeof(struct sync_fence_info));
>>>> ioctl(fd, SYNC_IOC_FENCE_INFO, &info);
>>>> }
>>>>
>>>> Maybe userspace could preallocate the max in advance and set num_fences higher,
>>>>
>>>> kernel would do something like:
>>>>
>>>> num_fences = min(info.num_fences, sync->num_fences);
>>>> struct sync_fence_info array[num_fences];
>>>>
>>>> info.num_fences = sync->num_fences;
>>>> if (num_fences &&
>>>>     copy_to_user((void * __user)(unsigned long)info.sync_fence_info, array, num_fences  * sizeof(array)))
>>>>  return -EFAULT;
>>> If we are going to call IOCTL twice I would actually have a new IOCTL only
>>> to fetch sync_fence_info.
>>>
>>> First we would call
>>>
>>> ioctl(fd, SYNC_IOC_FILE_INFO, &info);
>>>
>>> where info is:
>>>
>>> struct sync_file_info {    
>>>         char    name[32];  
>>>         __s32   status;    
>>>         __u32   flags;     
>>>         __u32   num_fences;
>>> };
>>>
>>> then we would allocate a buffer with
>>>
>>> size = info.num_fences * sizeof(struct sync_fence_info)
>>>
>>> and call the new ioctl
>>>
>>> ioctl(fd, SYNC_IOC_SYNC_FENCE_INFO, sync_fence_info);
>>>
>>> This looks like a cleaner solution and doesn't break ABI. What do you
>>> think?
>> I think it's good taste that userspace specifies the size of the buffer it passes, so former feels more clean to me,
>> since you need to pass num_fences anyway.
> Just to clarify, userspace specifies the size of the buffer in the
> solution I proposed. It would be
>
> 	size = info.num_fences * sizeof(struct sync_fence_info)
>
> 	sync_fence_info = malloc(size);
>
> 	ioctl(fd, SYNC_IOC_SYNC_FENCE_INFO, sync_fence_info);
>
For someone writing a wrapper like valgrind would mean having prior knowledge of previous ioctl results too.
Hence you would need something like

struct fence_collection {
u32 num_fences;
u32 pad;
struct sync_fence_info fences[0];
}

in which case you might as well return it optionally as a pointer in sync_file_info.

~Maarten