From: Martin Liu <liumartin@google.com>
To: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Todd Kjos <tkjos@android.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Chenbo Feng <fengc@google.com>,
Greg Hackmann <ghackmann@google.com>,
Linaro MM SIG <linaro-mm-sig@lists.linaro.org>,
minchan@kernel.org, Jenhao Chen <jenhaochen@google.com>,
DRI Development <dri-devel@lists.freedesktop.org>,
Daniel Vetter <daniel.vetter@intel.com>,
Suren Baghdasaryan <surenb@google.com>,
"open list:DMA BUFFER SHARING FRAMEWORK"
<linux-media@vger.kernel.org>
Subject: Re: [PATCH] dma-buf: Fix SET_NAME ioctl uapi
Date: Thu, 23 Apr 2020 22:51:22 +0800 [thread overview]
Message-ID: <20200423145122.GA17542@google.com> (raw)
In-Reply-To: <CAO_48GF5jM-L7bqnfvXSvbugAjYsYnE7rGokO7_LWQxHua0=wQ@mail.gmail.com>
On Thu, Apr 09, 2020 at 09:28:16AM +0530, Sumit Semwal wrote:
> Thanks for the patch, Daniel!
>
>
> On Tue, 7 Apr 2020 at 19:00, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > The uapi is the same on 32 and 64 bit, but the number isnt. Everyone
> > who botched this please re-read:
> >
> > https://www.kernel.org/doc/html/v5.4-preprc-cpu/ioctl/botching-up-ioctls.html
> >
> > Also, the type argument for the ioctl macros is for the type the void
> > __user *arg pointer points at, which in this case would be the
> > variable-sized char[] of a 0 terminated string. So this was botched in
> > more than just the usual ways.
>
> Yes, it shouldn't have passed through the cracks; my apologies!
>
> >
> > Cc: Sumit Semwal <sumit.semwal@linaro.org>
> > Cc: Chenbo Feng <fengc@google.com>
> > Cc: Greg Hackmann <ghackmann@google.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: linux-media@vger.kernel.org
> > Cc: linaro-mm-sig@lists.linaro.org
> > Cc: minchan@kernel.org
> > Cc: surenb@google.com
> > Cc: jenhaochen@google.com
> > Cc: Martin Liu <liumartin@google.com>
>
> Martin,
> Could I request you to test this one with the 4 combinations of 32-bit
> / 64-bit userspace and kernel, and let us know that all 4 are working
> alright? If yes, please consider giving your tested-by here.
>
Hi Sumit, Daniel,
Sorry for being late to the tests. I finished the tests on 32/64 apps
with 64 bit kernel and they were fine. Unfortunately, I couldn't have a 32
bit kernel to run the tests somehow. However, this should work from the
code logic. Hope this is okay to you and thanks for Todd's help.
Tested-by: Martin Liu <liumartin@google.com>
Reviewed-by: Martin Liu <liumartin@google.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> > drivers/dma-buf/dma-buf.c | 3 ++-
> > include/uapi/linux/dma-buf.h | 4 ++++
> > 2 files changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 570c923023e6..1d923b8e4c59 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -388,7 +388,8 @@ static long dma_buf_ioctl(struct file *file,
> >
> > return ret;
> >
> > - case DMA_BUF_SET_NAME:
> > + case DMA_BUF_SET_NAME_A:
> > + case DMA_BUF_SET_NAME_B:
> > return dma_buf_set_name(dmabuf, (const char __user *)arg);
> >
> > default:
> > diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
> > index dbc7092e04b5..21dfac815dc0 100644
> > --- a/include/uapi/linux/dma-buf.h
> > +++ b/include/uapi/linux/dma-buf.h
> > @@ -39,6 +39,10 @@ struct dma_buf_sync {
> >
> > #define DMA_BUF_BASE 'b'
> > #define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync)
> > +/* 32/64bitness of this uapi was botched in android, there's no difference
> > + * between them in actual uapi, they're just different numbers. */
> > #define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *)
> > +#define DMA_BUF_SET_NAME_A _IOW(DMA_BUF_BASE, 1, u32)
> > +#define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, u64)
> >
> > #endif
> > --
> > 2.25.1
> >
> Best,
> Sumit.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Martin Liu <liumartin@google.com>
To: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
DRI Development <dri-devel@lists.freedesktop.org>,
Chenbo Feng <fengc@google.com>,
Greg Hackmann <ghackmann@google.com>,
"open list:DMA BUFFER SHARING FRAMEWORK"
<linux-media@vger.kernel.org>,
Linaro MM SIG <linaro-mm-sig@lists.linaro.org>,
minchan@kernel.org, Suren Baghdasaryan <surenb@google.com>,
Jenhao Chen <jenhaochen@google.com>,
Daniel Vetter <daniel.vetter@intel.com>,
Todd Kjos <tkjos@android.com>
Subject: Re: [PATCH] dma-buf: Fix SET_NAME ioctl uapi
Date: Thu, 23 Apr 2020 22:51:22 +0800 [thread overview]
Message-ID: <20200423145122.GA17542@google.com> (raw)
In-Reply-To: <CAO_48GF5jM-L7bqnfvXSvbugAjYsYnE7rGokO7_LWQxHua0=wQ@mail.gmail.com>
On Thu, Apr 09, 2020 at 09:28:16AM +0530, Sumit Semwal wrote:
> Thanks for the patch, Daniel!
>
>
> On Tue, 7 Apr 2020 at 19:00, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > The uapi is the same on 32 and 64 bit, but the number isnt. Everyone
> > who botched this please re-read:
> >
> > https://www.kernel.org/doc/html/v5.4-preprc-cpu/ioctl/botching-up-ioctls.html
> >
> > Also, the type argument for the ioctl macros is for the type the void
> > __user *arg pointer points at, which in this case would be the
> > variable-sized char[] of a 0 terminated string. So this was botched in
> > more than just the usual ways.
>
> Yes, it shouldn't have passed through the cracks; my apologies!
>
> >
> > Cc: Sumit Semwal <sumit.semwal@linaro.org>
> > Cc: Chenbo Feng <fengc@google.com>
> > Cc: Greg Hackmann <ghackmann@google.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: linux-media@vger.kernel.org
> > Cc: linaro-mm-sig@lists.linaro.org
> > Cc: minchan@kernel.org
> > Cc: surenb@google.com
> > Cc: jenhaochen@google.com
> > Cc: Martin Liu <liumartin@google.com>
>
> Martin,
> Could I request you to test this one with the 4 combinations of 32-bit
> / 64-bit userspace and kernel, and let us know that all 4 are working
> alright? If yes, please consider giving your tested-by here.
>
Hi Sumit, Daniel,
Sorry for being late to the tests. I finished the tests on 32/64 apps
with 64 bit kernel and they were fine. Unfortunately, I couldn't have a 32
bit kernel to run the tests somehow. However, this should work from the
code logic. Hope this is okay to you and thanks for Todd's help.
Tested-by: Martin Liu <liumartin@google.com>
Reviewed-by: Martin Liu <liumartin@google.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> > drivers/dma-buf/dma-buf.c | 3 ++-
> > include/uapi/linux/dma-buf.h | 4 ++++
> > 2 files changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > index 570c923023e6..1d923b8e4c59 100644
> > --- a/drivers/dma-buf/dma-buf.c
> > +++ b/drivers/dma-buf/dma-buf.c
> > @@ -388,7 +388,8 @@ static long dma_buf_ioctl(struct file *file,
> >
> > return ret;
> >
> > - case DMA_BUF_SET_NAME:
> > + case DMA_BUF_SET_NAME_A:
> > + case DMA_BUF_SET_NAME_B:
> > return dma_buf_set_name(dmabuf, (const char __user *)arg);
> >
> > default:
> > diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
> > index dbc7092e04b5..21dfac815dc0 100644
> > --- a/include/uapi/linux/dma-buf.h
> > +++ b/include/uapi/linux/dma-buf.h
> > @@ -39,6 +39,10 @@ struct dma_buf_sync {
> >
> > #define DMA_BUF_BASE 'b'
> > #define DMA_BUF_IOCTL_SYNC _IOW(DMA_BUF_BASE, 0, struct dma_buf_sync)
> > +/* 32/64bitness of this uapi was botched in android, there's no difference
> > + * between them in actual uapi, they're just different numbers. */
> > #define DMA_BUF_SET_NAME _IOW(DMA_BUF_BASE, 1, const char *)
> > +#define DMA_BUF_SET_NAME_A _IOW(DMA_BUF_BASE, 1, u32)
> > +#define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, u64)
> >
> > #endif
> > --
> > 2.25.1
> >
> Best,
> Sumit.
next prev parent reply other threads:[~2020-04-23 22:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-07 13:30 [PATCH] dma-buf: Fix SET_NAME ioctl uapi Daniel Vetter
2020-04-07 13:30 ` Daniel Vetter
2020-04-09 3:58 ` Sumit Semwal
2020-04-09 3:58 ` Sumit Semwal
2020-04-23 14:51 ` Martin Liu [this message]
2020-04-23 14:51 ` Martin Liu
2020-04-28 10:37 ` Sumit Semwal
2020-04-28 10:37 ` Sumit Semwal
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=20200423145122.GA17542@google.com \
--to=liumartin@google.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=fengc@google.com \
--cc=ghackmann@google.com \
--cc=jenhaochen@google.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-media@vger.kernel.org \
--cc=minchan@kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=surenb@google.com \
--cc=tkjos@android.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 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.