From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: [PATCH] io_uring: use __kernel_timespec in timeout ABI Date: Tue, 1 Oct 2019 09:52:27 -0600 Message-ID: References: <20190930202055.1748710-1-arnd@arndb.de> <8d5d34da-e1f0-1ab5-461e-f3145e52c48a@kernel.dk> <623e1d27-d3b1-3241-bfd4-eb94ce70da14@kernel.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Arnd Bergmann Cc: y2038 Mailman List , Linux API , Alexander Viro , =?UTF-8?Q?Stefan_B=c3=bchler?= , Hannes Reinecke , Jackie Liu , Andrew Morton , Hristo Venev , linux-block , Linux FS-devel Mailing List , "linux-kernel@vger.kernel.org" List-Id: linux-api@vger.kernel.org On 10/1/19 9:49 AM, Arnd Bergmann wrote: > On Tue, Oct 1, 2019 at 5:38 PM Jens Axboe wrote: >> >> On 10/1/19 8:09 AM, Jens Axboe wrote: >>> On 9/30/19 2:20 PM, Arnd Bergmann wrote: >>>> All system calls use struct __kernel_timespec instead of the old struct >>>> timespec, but this one was just added with the old-style ABI. Change it >>>> now to enforce the use of __kernel_timespec, avoiding ABI confusion and >>>> the need for compat handlers on 32-bit architectures. >>>> >>>> Any user space caller will have to use __kernel_timespec now, but this >>>> is unambiguous and works for any C library regardless of the time_t >>>> definition. A nicer way to specify the timeout would have been a less >>>> ambiguous 64-bit nanosecond value, but I suppose it's too late now to >>>> change that as this would impact both 32-bit and 64-bit users. >>> >>> Thanks for catching that, Arnd. Applied. >> >> On second thought - since there appears to be no good 64-bit timespec >> available to userspace, the alternative here is including on in liburing. > > What's wrong with using __kernel_timespec? Just the name? > I suppose liburing could add a macro to give it a different name > for its users. Just that it seems I need to make it available through liburing on systems that don't have it yet. Not a big deal, though. >> That seems kinda crappy in terms of API, so why not just use a 64-bit nsec >> value as you suggest? There's on released kernel with this feature yet, so >> there's nothing stopping us from just changing the API to be based on >> a single 64-bit nanosecond timeout. > > Certainly fine with me. > >> + timeout = READ_ONCE(sqe->addr); >> hrtimer_init(&req->timeout.timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); >> req->timeout.timer.function = io_timeout_fn; >> - hrtimer_start(&req->timeout.timer, timespec_to_ktime(ts), >> + hrtimer_start(&req->timeout.timer, ns_to_ktime(timeout), > > It seems a little odd to use the 'addr' field as something that's not > an address, > and I'm not sure I understand the logic behind when you use a READ_ONCE() > as opposed to simply accessing the sqe the way it is done a few lines > earlier. > > The time handling definitely looks good to me. One thing that struck me about this approach - we then lose the ability to differentiate between "don't want a timed timeout" with ts == NULL, vs tv_sec and tv_nsec both being 0. I think I'll stuck with that you had and just use __kernel_timespec in liburing. -- Jens Axboe