From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755740AbcBDJ5e (ORCPT ); Thu, 4 Feb 2016 04:57:34 -0500 Received: from mga04.intel.com ([192.55.52.120]:14280 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754580AbcBDJ5T (ORCPT ); Thu, 4 Feb 2016 04:57:19 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,395,1449561600"; d="scan'208";a="896171952" Subject: Re: [PATCH v3 06/11] staging/android: turn fence_info into a __u64 pointer To: Gustavo Padovan , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org, dri-devel@lists.freedesktop.org, Daniel Stone , =?UTF-8?Q?Arve_Hj=c3=b8nnev=c3=a5g?= , Riley Andrews , Daniel Vetter , Rob Clark , Greg Hackmann , John Harrison , Gustavo Padovan References: <1454505940-18094-1-git-send-email-gustavo@padovan.org> <1454505940-18094-7-git-send-email-gustavo@padovan.org> <56B2111A.8080103@linux.intel.com> <20160203200957.GG2808@joana> From: Maarten Lankhorst Message-ID: <56B3207B.50100@linux.intel.com> Date: Thu, 4 Feb 2016 10:57:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20160203200957.GG2808@joana> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Op 03-02-16 om 21:09 schreef Gustavo Padovan: > Hi Maarten, > > 2016-02-03 Maarten Lankhorst : > >> Op 03-02-16 om 14:25 schreef Gustavo Padovan: >>> From: Gustavo Padovan >>> >>> 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 >>> --- >>> 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. But Daniel knows more about designing ioctl's than I do, so for exact behavior it's best to ask him. ~Maarten