[PATCH 1/2] dma-buf: Add an API for exporting sync files (v13)
Christian König
christian.koenig at amd.com
Thu May 5 08:27:39 UTC 2022
Am 05.05.22 um 10:10 schrieb Jason Ekstrand:
> On Thu, May 5, 2022 at 1:25 AM Christian König
> <christian.koenig at amd.com> wrote:
>
> [SNIP]
> > + fd_install(fd, sync_file->file);
> > +
> > + arg.fd = fd;
> > + if (copy_to_user(user_data, &arg, sizeof(arg)))
> > + return -EFAULT;
>
> I know we had that discussion before, but I'm not 100% any more
> what the
> outcome was.
>
> The problem here is that when the copy_to_user fails we have a file
> descriptor which is valid, but userspace doesn't know anything
> about it.
>
> I only see a few possibilities here:
> 1. Keep it like this and just assume that a process which you
> can't copy
> the fd to is also dying (a bit to much assumption for my taste).
>
> 2. Close the file descriptor when this happens (not ideal either).
>
> 3. Instead of returning the fd in the parameter structure return
> it as
> IOCTL result.
>
> Number 3 is what drm_prime_handle_to_fd_ioctl() is doing as well and
> IIRC we said that this is probably the best option.
>
>
> I don't have a strong preference here, so I'll go with whatever in the
> end but let me at least explain my reasoning. First, this was based
> on the FD import/export in syncobj which stuffs the FD in the args
> struct. If `copy_to_user` is a problem here, it's a problem there as
> well. Second, the only way `copy_to_user` can fail is if the client
> gives us a read-only page or somehow manages to race removing the page
> from their address space (via unmap(), for instance) with this ioctl.
> Both of those seem like pretty serious client errors to me. That, or
> the client is in the process of dying, in which case we really don't care.
Yeah, I know about that copy_to_user() issue in the syncobj and also
some driver specific handling.
That's why we discussed this before and IIRC somebody indeed ran into an
issue with -EFAULT and that was the reason all this bubbled up.
I don't have a strong preference either, but I think we should try to
learn from previous mistakes and design new interfaces based on such
experience.
Christian.
>
> --Jason
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20220505/d7cdf42a/attachment.htm>
More information about the dri-devel
mailing list