On Friday, October 28, 2016 2:56:10 PM CEST Dmitry Torokhov wrote:

On Fri, Oct 28, 2016 at 2:47 PM, Arnd Bergmann [off-list ref] wrote:

quoted

On Friday, October 28, 2016 2:39:35 PM CEST Deepa Dinamani wrote:

quoted

quoted

quoted

quoted

quoted

@@ -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.

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?

Yes, this works fine per task, with the definition of COMPAT_USE_64BIT_TIME
that is hardcoded to zero everywhere except on x86 where it is

#define COMPAT_USE_64BIT_TIME \
        (!!(task_pt_regs(current)->orig_ax & __X32_SYSCALL_BIT))

This is unrelated to the patch in question, the existing code
is correct as long as we don't change the logic and just
replace input_event with raw_input_event (or __kernel_input_event
or whichever you prefer).

	Arnd