linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	me@zv.io
Subject: Re: [PATCH v5 6/8] media: v4l2-core: fix v4l2_buffer handling for time64 ABI
Date: Mon, 16 Dec 2019 10:29:26 +0100	[thread overview]
Message-ID: <CAK8P3a0ZwMgXqjAjh7P8B2BR4THd-rMZM0jt5KvxHtxNF_8Nqw@mail.gmail.com> (raw)
In-Reply-To: <bfc18778-0777-ad49-619b-39e1b9b536f3@xs4all.nl>

On Sun, Dec 15, 2019 at 6:26 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> Ah, great, that worked, after applying the patch below.
>
> Both struct v4l2_buffer32 and v4l2_event32 need to be packed, otherwise you would
> get an additional 4 bytes since the 64 bit compiler wants to align the 8 byte tv_secs
> to an 8 byte boundary. But that's not what the i686 compiler does.

Thanks so much for the testing and finding this issue. It would be much more
embarrassing to find it later, given that I explained how it's supposed to work
in the comment above v4l2_event32 and in the documentation I just submitted
but got it wrong anyway ;-)

> If I remember correctly, packed is only needed for CONFIG_X86_64.

Correct.

> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index 3bbf47d950e0..c01492cf6160 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> @@ -492,7 +492,11 @@ struct v4l2_buffer32 {
>         __u32                   length;
>         __u32                   reserved2;
>         __s32                   request_fd;
> +#ifdef CONFIG_X86_64
> +} __attribute__ ((packed));
> +#else
>  };
> +#endif

I would prefer to write it like this instead to avoid the #ifdef, the
effect should
be the same:

--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -475,8 +475,8 @@ struct v4l2_buffer32 {
        __u32                   flags;
        __u32                   field;  /* enum v4l2_field */
        struct {
-               long long       tv_sec;
-               long long       tv_usec;
+               compat_s64      tv_sec;
+               compat_s64      tv_usec;
        }                       timestamp;
        struct v4l2_timecode    timecode;
        __u32                   sequence;
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -1277,7 +1277,10 @@ struct v4l2_event32 {
        } u;
        __u32                           pending;
        __u32                           sequence;
-       struct __kernel_timespec        timestamp;
+       struct {
+               compat_s64              tv_sec;
+               compat_s64              tv_usec;
+       } timestamp;
        __u32                           id;
        __u32                           reserved[8];
 };

If you agree, I'll push out a modified branch with that version and send out
that series to the list again.

There is one more complication that I just noticed: The "struct v4l2_buffer32"
definition has always been defined in a way that works for i386 user space
but is broken for x32 user space. The version I used accidentally fixed x32
while breaking i386. With the change above, it's back to missing x32 support
(so nothing changed).

There is no way to fix the uapi definition of v4l2_buffer to have x32 and i386
use the same format, because applications may be using old headers, but
I suppose I could add yet another version of the struct to correctly deal with
x32, or just add a comment like

--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -468,6 +468,10 @@ struct v4l2_plane32 {
        __u32                   reserved[11];
 };

+/*
+ * This is correct for all architectures including i386, but not x32,
+ * which has different alignment requirements for timestamp
+ */
 struct v4l2_buffer32 {
        __u32                   index;
        __u32                   type;   /* enum v4l2_buf_type */


      Arnd

  reply	other threads:[~2019-12-16  9:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-26 16:18 [PATCH v5 0/8] y2038 safety in v4l2 Arnd Bergmann
2019-11-26 16:18 ` [PATCH v5 1/8] media: documentation: fix video_event description Arnd Bergmann
2019-11-26 16:18 ` [PATCH v5 2/8] media: v4l2: abstract timeval handling in v4l2_buffer Arnd Bergmann
2019-11-26 16:18 ` [PATCH v5 3/8] media: v4l2-core: compat: ignore native command codes Arnd Bergmann
2019-11-26 16:18 ` [PATCH v5 4/8] media: v4l2-core: split out data copy from video_usercopy Arnd Bergmann
2019-11-26 16:18 ` [PATCH v5 5/8] media: v4l2-core: fix VIDIOC_DQEVENT for time64 ABI Arnd Bergmann
2019-11-26 16:18 ` [PATCH v5 6/8] media: v4l2-core: fix v4l2_buffer handling " Arnd Bergmann
2019-12-12 15:43   ` Hans Verkuil
2019-12-13 15:08     ` Arnd Bergmann
2019-12-13 15:32       ` Hans Verkuil
2019-12-13 15:38         ` Arnd Bergmann
2019-12-14 11:27         ` Hans Verkuil
2019-12-14 21:44           ` Arnd Bergmann
2019-12-15 17:26             ` Hans Verkuil
2019-12-16  9:29               ` Arnd Bergmann [this message]
2019-12-16 10:28                 ` Hans Verkuil
2019-12-19 23:26             ` Zach van Rijn
2019-11-26 16:18 ` [PATCH v5 7/8] media: v4l2-core: fix compat VIDIOC_DQEVENT " Arnd Bergmann
2019-11-26 16:18 ` [PATCH v5 8/8] media: v4l2-core: fix compat v4l2_buffer handling " Arnd Bergmann
2019-11-26 19:55 ` [PATCH v5.1 4/8] media: v4l2-core: split out data copy from video_usercopy Arnd Bergmann

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=CAK8P3a0ZwMgXqjAjh7P8B2BR4THd-rMZM0jt5KvxHtxNF_8Nqw@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=me@zv.io \
    --cc=y2038@lists.linaro.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 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).