From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Gustavo Padovan <gustavo@padovan.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
dri-devel@lists.freedesktop.org,
"Daniel Stone" <daniels@collabora.com>,
"Arve Hjønnevåg" <arve@android.com>,
"Riley Andrews" <riandrews@android.com>,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
"Rob Clark" <robdclark@gmail.com>,
"Greg Hackmann" <ghackmann@google.com>,
"John Harrison" <John.C.Harrison@Intel.com>,
"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>
Subject: Re: [PATCH v6 5/6] staging/android: refactor SYNC_IOC_FILE_INFO
Date: Thu, 3 Mar 2016 10:29:01 +0100 [thread overview]
Message-ID: <56D803DD.7050903@linux.intel.com> (raw)
In-Reply-To: <1456948331-7300-5-git-send-email-gustavo@padovan.org>
Op 02-03-16 om 20:52 schreef Gustavo Padovan:
> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> optimize buffer
>
> 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.
>
> Also, info->sync_fence_info was converted to __u64 pointer to prevent
> 32bit compatibility issues.
>
> 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);
> }
>
> 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
>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> ---
> drivers/staging/android/sync.c | 64 ++++++++++++++++++++-----------------
> drivers/staging/android/uapi/sync.h | 9 ++----
> 2 files changed, 38 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
> index dc5f382..3604e453 100644
> --- a/drivers/staging/android/sync.c
> +++ b/drivers/staging/android/sync.c
> @@ -479,13 +479,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,28 +491,20 @@ 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 in, *info;
Why put one copy on the stack, and allocate a second?
With sync_file_info now being a fixed size just put 1 copy on the stack from userspace,
run some sanity checks first, put in the new values and copy it back to userspace without additional memory allocation.
The rest looks good now. :)
~Maarten
next prev parent reply other threads:[~2016-03-03 9:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 19:52 [PATCH v6 1/6] staging/android: add num_fences field to struct sync_file_info Gustavo Padovan
2016-03-02 19:52 ` [PATCH v6 2/6] staging/android: rename SYNC_IOC_FENCE_INFO Gustavo Padovan
2016-03-02 19:52 ` [PATCH v6 3/6] staging/android: remove redundant comments on sync_merge_data Gustavo Padovan
2016-03-02 19:52 ` [PATCH v6 4/6] staging/android: align struct sync_merge_data to a multiple of 64-bits Gustavo Padovan
2016-03-02 21:40 ` Gustavo Padovan
2016-03-02 19:52 ` [PATCH v6 5/6] staging/android: refactor SYNC_IOC_FILE_INFO Gustavo Padovan
2016-03-03 9:29 ` Maarten Lankhorst [this message]
2016-03-03 14:34 ` [PATCH] " Gustavo Padovan
2016-03-03 14:59 ` Maarten Lankhorst
2016-03-02 19:52 ` [PATCH v6 6/6] staging/android: add flags member to sync ioctl structs Gustavo Padovan
2016-03-02 21:51 ` [PATCH] " Gustavo Padovan
2016-03-03 14:37 ` Gustavo Padovan
2016-03-03 16:17 ` Greg Kroah-Hartman
2016-03-03 19:14 ` Gustavo Padovan
2016-03-03 19:42 ` Gustavo Padovan
2016-03-03 20:01 ` Ville Syrjälä
2016-03-03 20:54 ` Rob Clark
2016-03-03 21:47 ` Rob Clark
2016-03-04 16:40 ` Daniel Vetter
2016-03-11 21:59 ` Greg Kroah-Hartman
2016-03-05 12:58 ` Emil Velikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56D803DD.7050903@linux.intel.com \
--to=maarten.lankhorst@linux.intel.com \
--cc=John.C.Harrison@Intel.com \
--cc=arve@android.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniels@collabora.com \
--cc=devel@driverdev.osuosl.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=ghackmann@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=gustavo.padovan@collabora.co.uk \
--cc=gustavo@padovan.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riandrews@android.com \
--cc=robdclark@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).