All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Deepa Dinamani <deepa.kernel@gmail.com>,
	"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	y2038 Mailman List <y2038@lists.linaro.org>
Subject: Re: [PATCH v2 3/4] input: Deprecate real timestamps beyond year 2106
Date: Fri, 28 Oct 2016 14:56:10 -0700	[thread overview]
Message-ID: <CAKdAkRRXyz=uao_XdDVpG=BDsy+GA=bzkEKJabbs3Cd7ZG1mZA@mail.gmail.com> (raw)
In-Reply-To: <3544660.FKrMrRAIUC@wuerfel>

On Fri, Oct 28, 2016 at 2:47 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday, October 28, 2016 2:39:35 PM CEST Deepa Dinamani wrote:
>> >> >> @@ -55,24 +60,24 @@ struct ff_effect_compat {
>> >> >>
>> >> >>  static inline size_t input_event_size(void)
>> >> >>  {
>> >> >> -       return (in_compat_syscall() && !COMPAT_USE_64BIT_TIME) ?
>> >> >> -               sizeof(struct input_event_compat) : sizeof(struct input_event);
>> >> >> +       return in_compat_syscall() ? sizeof(struct raw_input_event_compat) :
>> >> >> +                                    sizeof(struct raw_input_event);
>> >> >>  }
>> >> >
>> >> > I think the COMPAT_USE_64BIT_TIME check has to stay here,
>> >> > it's needed for x32 mode on x86-64.
>> >>
>> >> There is no time_t anymore in the raw_input_event structure.
>> >> The struct uses __kernel_ulong_t type.
>> >> This should take care of x32 support.
>> >
>> > I don't think it does.
>> >
>> >> From this cover letter:
>> >> https://www.spinics.net/lists/linux-arch/msg16356.html
>> >>
>> >> I see that that the __kernel types were introduced to address the ABI
>> >> issues for x32.
>> >
>> > This is a variation of the problem we are trying to solve for
>> > the other architectures in your patch set:
>> >
>> > On x32, the kernel uses produces a structure with the 64-bit
>> > layout, using __u64 tv_sec, to match the current user space
>> > that has 64-bit __kernel_ulong_t and 64-bit time_t, but
>> > in_compat_syscall() also returns 'true' here, as this is
>> > mostly a 32-bit ABI (time_t being one of the exceptions).
>>
>> Yes, I missed this.
>>
>> in_compat_syscall() is true for x32, this would mean we end up here
>> even if it is a x32 syscall.
>> But, wouldn't it be better to use in_x32_syscall() here since there is
>> no timeval any more?
>
> We have to distinguish four cases on x86:
>
> - native 32-bit, input_event with 32-bit time_t
> - compat 32-bit, input_event_compat with 32-bit time_t
> - native 64-bit, input_event with 64-bit time_t
> - compat x32, input_event with 64-bit time_t
>
> The first three can happen on other architectures too,
> the last one is x86 specific. There are probably other ways
> to express the condition above, but I can't think of one
> that is better than the one we have today.

Can we detect if given task is compat x32, like we do for compat
64/32? Or entire userspace has to be x32?

Thanks.

-- 
Dmitry

  reply	other threads:[~2016-10-28 21:56 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-18  3:27 [PATCH v2 0/4] Make input drivers y2038 safe Deepa Dinamani
2016-10-18  3:27 ` [PATCH v2 1/4] uinput: Add ioctl for using monotonic/ boot times Deepa Dinamani
2016-10-27  1:45   ` Peter Hutterer
2016-10-27 20:39     ` Deepa Dinamani
2016-10-27 20:39       ` Deepa Dinamani
2016-10-28  4:32       ` Peter Hutterer
2016-10-18  3:27 ` [PATCH v2 2/4] input: evdev: Replace timeval with timespec64 Deepa Dinamani
2016-10-27  1:34   ` Peter Hutterer
2016-10-27  1:34     ` Peter Hutterer
2016-10-27 11:14     ` [Y2038] " Arnd Bergmann
2016-10-27 11:14       ` Arnd Bergmann
2016-10-18  3:27 ` [PATCH v2 3/4] input: Deprecate real timestamps beyond year 2106 Deepa Dinamani
2016-10-27  2:24   ` Dmitry Torokhov
2016-10-27  2:24     ` Dmitry Torokhov
2016-10-27 22:25     ` Deepa Dinamani
2016-10-27 22:25       ` Deepa Dinamani
2016-10-27 23:12       ` Dmitry Torokhov
2016-10-27 23:12         ` Dmitry Torokhov
2016-10-28 12:19         ` Arnd Bergmann
2016-10-30  4:34           ` Deepa Dinamani
2016-10-27  2:56   ` Peter Hutterer
2016-10-27  2:56     ` Peter Hutterer
2016-10-27 22:24     ` Deepa Dinamani
2016-10-27 22:24       ` Deepa Dinamani
2016-10-28  4:46       ` Peter Hutterer
2016-10-28 12:44         ` Arnd Bergmann
2016-10-30  4:19         ` Deepa Dinamani
2016-10-30  4:19           ` Deepa Dinamani
2016-10-31 10:30           ` Peter Hutterer
2016-10-28 12:43   ` Arnd Bergmann
2016-10-28 15:19     ` Deepa Dinamani
2016-10-28 15:45       ` Arnd Bergmann
2016-10-28 21:39         ` Deepa Dinamani
2016-10-28 21:47           ` Arnd Bergmann
2016-10-28 21:56             ` Dmitry Torokhov [this message]
2016-10-28 22:01               ` Arnd Bergmann
2016-10-18  3:27 ` [PATCH v2 4/4] input: serio: Replace timeval by timespec64 Deepa Dinamani

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='CAKdAkRRXyz=uao_XdDVpG=BDsy+GA=bzkEKJabbs3Cd7ZG1mZA@mail.gmail.com' \
    --to=dmitry.torokhov@gmail.com \
    --cc=arnd@arndb.de \
    --cc=deepa.kernel@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 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.