linux-kernel - Re: [PATCH 31/31] aio: implement io

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 10 Jan 2018 15:59:48 +0100
From:   Christoph Hellwig <hch@....de>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Christoph Hellwig <hch@....de>, Al Viro <viro@...iv.linux.org.uk>,
        Avi Kivity <avi@...lladb.com>, linux-aio@...ck.org,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        y2038 Mailman List <y2038@...ts.linaro.org>
Subject: Re: [PATCH 31/31] aio: implement io_pgetevents

On Wed, Jan 10, 2018 at 12:03:24PM +0100, Arnd Bergmann wrote:
> I'd suggest passing a variant of timespec with two 64-bit members.
> Deepa has posted patches for this structure in the past and was planning
> to do a new version (with minor changes from review) soon, but we
> can just well use it in your patch if that gets merged first.
> 
> If we merge io_pgetevents quickly (before the bulk of the y2038 syscall
> conversion), I'd say we should use
> 
> struct __kernel_timespec64 {
>          __s64 tv_sec;
>          __s64 tv_nsec;
> };
> 
> The tv_nsec type is unfortunately much trickier than it should be:
> C99 requires it to be 'long', so user space needs to define the 64-bit
> 'struct timespec' with internal padding in the right places depending
> on endianess, and the kernel has to be careful about either zeroing
> the upper half or checking it for being zeroed by user space depending
> on whether we come from a 32-bit or 64-bit task, but I'm fairly sure
> we have that part worked out by now.

Eww.  Being the ginea pig is never good, and in this the fact that
the aio syscalls aren't in glibc is just going to make things worse
in chances of diverging from the future 'standard'.

I'm tempted to say I'd rather deal with the new 64-bit time_t version
later, especially as that should only affect 32-bit ports.