From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: dri-devel@lists.freedesktop.org
Cc: Chad Versace <chadversary@chromium.org>
Subject: Re: Why does OUT_FENCE_PTR point not to an fd (s32) but to an s64?
Date: Tue, 10 Jan 2017 22:58:28 +0200 [thread overview]
Message-ID: <3771380.gEfP3ddfRA@avalon> (raw)
In-Reply-To: <20170109102322.uuatwip5v6bjo6te@phenom.ffwll.local>
Hi Daniel,
On Monday 09 Jan 2017 11:23:23 Daniel Vetter wrote:
> On Fri, Jan 06, 2017 at 01:04:55PM -0800, Chad Versace wrote:
> > Was this a mistake in the API? If so, can we fix this ABI mistake before
> > kernel consumers rely on this?
> >
> > I naïvely expected that OUT_FENCE_PTR would be a pointer to, obviously, a
> > fence fd (s32 __user *). But it's not. It's s64 __user *. Due to that
> > surprise, I spent several hours chasing down weird corruption in Rob
> > Clark's kmscube. The kernel unexpectedly cleared the 32 bits *above* an
> > `int kms_fence_fd` in userspace.
>
> Never use unsized types for uabi. I guess we could have used s32, but then
> someone is going to store this in a long and it goes boom on 64 bit,
Why so ? And why do we care ? The commonly accepted practice is to store file
descriptors in int variables. s32 is an int on all platforms, so that's fine
too. If we use a s32 pointer here, and someone decides to store it in a long,
bool or cast it to a complex, that's their problem :-)
> while it works on 32 bit. "int" doesn't have that problem directly, but it's
> still a red flag imo.
>
> > For reference, here's the relevant DRM code.
> >
> > // file: drivers/gpu/drm/drm_atomic.c
> > struct drm_out_fence_state {
> > s64 __user *out_fence_ptr;
> > struct sync_file *sync_file;
> > int fd;
> > };
> >
> > static int setup_out_fence(struct drm_out_fence_state *fence_state,
> > struct dma_fence *fence)
> > {
> > fence_state->fd = get_unused_fd_flags(O_CLOEXEC);
> > if (fence_state->fd < 0)
> > return fence_state->fd;
> >
> > if (put_user(fence_state->fd, fence_state->out_fence_ptr))
> > return -EFAULT;
> >
> > fence_state->sync_file = sync_file_create(fence);
> > if (!fence_state->sync_file)
> > return -ENOMEM;
> >
> > return 0;
> > }
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-01-10 20:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-06 21:04 Why does OUT_FENCE_PTR point not to an fd (s32) but to an s64? Chad Versace
2017-01-06 21:13 ` Chad Versace
2017-01-09 10:23 ` Daniel Vetter
2017-01-10 20:58 ` Laurent Pinchart [this message]
2017-01-12 19:17 ` Gustavo Padovan
2017-01-12 19:26 ` Daniel Vetter
2017-01-12 19:29 ` Laurent Pinchart
2017-01-12 19:34 ` Gustavo Padovan
2017-01-13 21:31 ` Chad Versace
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=3771380.gEfP3ddfRA@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=chadversary@chromium.org \
--cc=dri-devel@lists.freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.