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 16:48:05 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Christoph Hellwig <hch@....de>
Cc:     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 3:59 PM, Christoph Hellwig <hch@....de> wrote:
> 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.

Ok, fair enough. Given that the old version gets obsoleted by this
one, it shouldn't get much uglier than it already is here when you
start out with a regular timespec. We just need to be aware of possible
clashes when we get the patches merged at the same time.

      Arnd