On 15.1.20. 17:37, Arnd Bergmann wrote:
On Wed, Jan 15, 2020 at 5:32 PM Laurent Vivier <laur...@vivier.eu> wrote:
Le 15/01/2020 à 17:18, Arnd Bergmann a écrit :
On Wed, Jan 15, 2020 at 4:53 PM Filip Bozuta <filip.boz...@rt-rk.com> wrote:
This patch implements functionality of following ioctl:

SNDRV_TIMER_IOCTL_TREAD - Setting enhanced time read

     Sets enhanced time read which is used for reading time with timestamps
     and events. The third ioctl's argument is a pointer to an 'int'. Enhanced
     reading is set if the third argument is different than 0, otherwise normal
     time reading is set.

Implementation notes:

     Because the implemented ioctl has 'int' as its third argument, the
     implementation was straightforward.

Signed-off-by: Filip Bozuta <filip.boz...@rt-rk.com>
I think this one is wrong when you go between 32-bit and 64-bit
kernel uses an "int" and "int" is always 32bit.
The problem is most likely with timespec I think.

targets, and it gets worse with the kernel patches that just got
merged for linux-5.5, which extends the behavior to deal with
64-bit time_t on 32-bit architectures.

Please have a look at
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=80fe7430c70859
Yes, we already had the same kind of problem with SIOCGSTAMP and
SIOCGSTAMPNS.

Do the kernel patches add new ioctl numbers to differentiate 32bit and
64bit time_t?
Yes, though SNDRV_TIMER_IOCTL_TREAD is worse: the ioctl argument
is a pure 'int' that decides what format you get when you 'read' from the
same file descriptor.

For emulating 64-bit on 32-bit kernels, you have to use the new
SNDRV_TIMER_IOCTL_TREAD64, and for emulating 32-bit on
64-bit kernels, you probably have to return -ENOTTY to
SNDRV_TIMER_IOCTL_TREAD_OLD unless you also want to
emulate the read() behavior.
When a 32-bit process calls SNDRV_TIMER_IOCTL_TREAD64,
you can translate that into the 64-bit
SNDRV_TIMER_IOCTL_TREAD_OLD.

      Arnd


Thank you for bringing this up to my attention. Unfortunately i have some duties of academic nature in next month so i won't have much time fix this bug. I will try to fix this as soon as possible.

Best regards,

Filip Bozuta


Reply via email to