From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [klibc] kernel/libc uapi changes for y2038 Date: Mon, 18 May 2015 22:35:40 +0200 Message-ID: <3622889.d8DplXjbu8@wuerfel> References: <2664016.bYZKg6FQqR@wuerfel> <10173485.f8yUt0lQ60@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: y2038-bounces@lists.linaro.org Sender: "Y2038" To: y2038@lists.linaro.org Cc: klibc@zytor.com, libc-alpha@sourceware.org, linux-api@vger.kernel.org, musl@lists.openwall.com, linux-kernel@vger.kernel.org, Rich Felker , Thorsten Glaser , cferris@google.com, enh@google.com, "Joseph S. Myers" List-Id: linux-api@vger.kernel.org T24gTW9uZGF5IDE4IE1heSAyMDE1IDE3OjAzOjA4IFRob3JzdGVuIEdsYXNlciB3cm90ZToKCj4g Pk1JUFMgb24gdGhlIG90aGVyIGhhbmQgaXMgbm8gbW9yZSBicm9rZW4gdGhhbiBhbnkgb2YgdGhl IG90aGVyIDMyLWJpdAo+ID5BQklzLCBiZWNhdXNlIGl0IGRvZXMgbm90IHVzZSA2NC1iaXQgX19r ZXJuZWxfbG9uZ190IGluIGl0cyBuMzIgQUJJLgo+IAo+IEkgaGF2ZSBoZWFyZCBmcm9tIGEgTUlQ UyBwb3J0ZXIgdGhhdCBvbmUgb2YgdGhlIGZsYXZvdXJzIHN1ZmZlcnMKPiBmcm9tIHNpbWlsYXIg cHJvYmxlbXMgYXMgeDMyLCBqdXN0IG5vdCB0byB0aGF0IGV4dGVudC4gQnV0IEkKPiBkb27igJl0 IHJlY2FsbCBteSBzb3VyY2XigKYKCk1JUFMgbjMyIGhhcyBhIGxvdCBvZiB0aGUgc2FtZSBpc3N1 ZXMgYXMgeDg2IHgzMiwgYnV0IEknbSBwcmV0dHkKc3VyZSB0aGF0IHRoZSB0aW1lX3Qgb25lIGlz IG5vdCBhbW9uZyB0aGVtLgoKPiA+aW9jdGxzLiBNeSBwbGFuIGF0IHRoaXMgcG9pbnQgaXMgdG8g ZWxpbWluYXRlIGFsbCB1c2VzIG9mIHRpbWVfdCBpbgo+ID50aGUga2VybmVsIGFuZCByZXBsYWNl IHRoZW0gd2l0aCB0aW1lNjRfdCBvciBvdGhlciBzYWZlIHR5cGVzLgo+ID5UaGlzIHdheSwgd2Ug d2lsbCBldmVudHVhbGx5IGZpbmQgYWxsIGNvZGUgdGhhdCBwYXNzZXMgMzItYml0IHRpbWUgdHlw ZXMKPiA+dG8gdXNlciBzcGFjZSBhbmQgY2FuIGZpeCBpdC4gVGhpcyB3aWxsIHRha2UgY2FyZSBv ZiB0aGUgdGltZV90Cj4gPnJlbGF0ZWQgcHJvYmxlbXMgb24geDMyIGFzIHdlbGwuCj4gCj4gQWgs IGludGVyZXN0aW5nIGFwcHJvYWNoLiBBbmQgZXhpc3RpbmcgdXNlcnNwYWNlLCBhcyB3ZWxsIGFz IG5ldwo+IHVzZXJzcGFjZSB0aGF0IGRvZXMgbm90IGRlY2xhcmUgNjQtYml0IHRpbWVfdCByZWFk aW5lc3MsIGlzIHN0aWxsCj4gc2FmZSBvbiBjdXJyZW50bHktbm90LWJyb2tlbiBhcmNoaXRlY3R1 cmVzPyBTbywgdGhlcmXigJlzIGVub3VnaCB0aW1lCj4gdG8gZml4IHRoaXMgYmVmb3JlIHRoZSB2 YXJpb3VzIGxpYmNzIHR1cm4gdGhhdCBvbiAoYW5kIGl0IGhhZCBiZXR0ZXIKPiBiZSBmaXhlZCBi eSB0aGVuLCBiZWNhdXNlIGl0IGJlY29tZXMgQUJJIGJ5IHRoZW4pLiBOaWNlIGlkZWEuCgpDb3Jy ZWN0LiBBbm90aGVyIGFzcGVjdCBvZiB0aGUgYXBwcm9hY2ggSSdtIHRha2luZyBpcyB0aGF0IHRo ZQpzeXN0ZW0tY2FsbCBpbXBsZW1lbnRhdGlvbiBpcyBzaGFyZWQgYmV0d2VlbiB0aGUgbmF0aXZl IDY0LWJpdApjYXNlIGFuZCB0aGUgbmV3IDMyLWJpdCBjYXNlLCB3aGlsZSB0aGUgaGFuZGxpbmcg Zm9yIHRoZSBleGlzdGluZwpzeXNjYWxscyBvbiAzMi1iaXQgYXJjaGl0ZWN0dXJlcyBpcyBzaGFy ZWQgd2l0aCB0aGUgMzItYml0IGNvbXBhdApjb2RlIG9uIDY0LWJpdCBhcmNoaXRlY3R1cmVzLiBU aGlzIG1lYW5zIGlmIHdlIGludHJvZHVjZSBhIGJ1ZwppbiBlaXRoZXIgb2YgdGhlbSwgd2Ugd2ls bCBmaW5kIG91dCB2ZXJ5IHF1aWNrbHkgYW5kIGRvbid0IGhhdmUKdG8gd2FpdCB1bnRpbCBwZW9w bGUgc3RhcnQgdXNpbmcgNjQtYml0IHRpbWVfdCBvbiAzMi1iaXQgdXNlciBsYW5kLgoKPiBJIGFt IHdvbmRlcmluZyBhIGJpdCBhYm91dCB0aGUgaW9jdGxzIGJlaW5nIGhhcmQgdG8gZmluZC4gSSBo YXZlCj4gbm90IG11Y2ggZXhwZXJpZW5jZSB3aXRoIGtlcm5lbCBwcm9ncmFtbWluZywgYW5kIGV2 ZW4gbGVzcyB3aXRoCj4gTGludXggdGhhbiB3aXRoIE1TLURPUyBhbmQgQlNELCBidXQgc2hvdWxk IG5vdCBlYWNoIGRyaXZlciBoYXZlCj4gYSBjZW50cmFsIGlvY3RsIGVudHJ5IHBvaW50LCBmcm9t IHdoaWNoIGl0IHNob3VsZCBjYXN0IHRoZSB1c2VyCj4gc3BhY2UgZGF0YSBpbnRvIGEgKHBvc3Np Ymx5IGxvY2FsbHkgZGVjbGFyZWQpIHN0cnVjdHVyZT8KClllcywgdGhhdCdzIGhvdyBpdCB3b3Jr cywgYnV0IHVuZm9ydHVuYXRlbHkgd2UgaGF2ZSBhIGZldyB0aG91c2FuZApkcml2ZXJzIHRoYXQg ZGVjbGFyZSBhbiBpb2N0bCBmdW5jdGlvbiwgYW5kIEkgaG9wZSB0byBkbyBzb21ldGhpbmcKYmV0 dGVyIHRoYW4gYnJ1dGUtZm9yY2Ugc2VhcmNoIGFsbCBvZiB0aGVtLiBUaGUgb3RoZXIgcG9pbnQg aXMgdGhhdAp3ZSByZWFsbHkgbmVlZCB0byBmaXggYWxsIHkyMDM4LXJlbGF0ZWQgYnVnIGluIGRy aXZlcnMsIG5vdCBqdXN0CnRoZSBvbmVzIGluIGlvY3RsLiBUaGlzIGluY2x1ZGVzIHRoaW5ncyBs aWtlIGZpbGUgc3lzdGVtcyBzdG9yaW5nCnRpbWUgaW4gMzItYml0IHVuaXRzIG9uIGRpc2ssIG9y IGRyaXZlcnMgdHJ5aW5nIHRvIG1lYXN1cmUgaG93IG11Y2gKdGltZSBoYXMgZWxhcHNlZCB3aXRo b3V0IGNvbW11bmljYXRpbmcgdGhhdCB2YWx1ZSBlbHNld2hlcmUsIGJ1dApmYWlsaW5nIHdoZW4g dGhlIHRpbWVfdCBudW1iZXIgZ29lcyBuZWdhdGl2ZS4KCglBcm5kCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClkyMDM4IG1haWxpbmcgbGlzdApZMjAzOEBs aXN0cy5saW5hcm8ub3JnCmh0dHBzOi8vbGlzdHMubGluYXJvLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3kyMDM4Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932867AbbERUhU (ORCPT ); Mon, 18 May 2015 16:37:20 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:52848 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932359AbbERUhP convert rfc822-to-8bit (ORCPT ); Mon, 18 May 2015 16:37:15 -0400 From: Arnd Bergmann To: y2038@lists.linaro.org Cc: Thorsten Glaser , klibc@zytor.com, libc-alpha@sourceware.org, linux-api@vger.kernel.org, musl@lists.openwall.com, linux-kernel@vger.kernel.org, Rich Felker , cferris@google.com, enh@google.com, "Joseph S. Myers" Subject: Re: [Y2038] [klibc] kernel/libc uapi changes for y2038 Date: Mon, 18 May 2015 22:35:40 +0200 Message-ID: <3622889.d8DplXjbu8@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <2664016.bYZKg6FQqR@wuerfel> <10173485.f8yUt0lQ60@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="utf-8" X-Provags-ID: V03:K0:NvlzkWTsyqPO2TbN1iwfNJy5oxlM5eU+vwPCk7NxxbhA0coXUIX fX7xQI/NudxbMR8579p0+Qd9lYzkvOMIghbT7x67v+Ldqp7RZCBtnjy8gPWvcCUCQkNxQla pebKV8Ph5GY19whhz8wA857WYTImhLxw3y7oE2UM4+7kAN1wA17YkLmvvsppDdmnbqrPGY4 6hQPspgndz5CGm8k8sxlQ== X-UI-Out-Filterresults: notjunk:1; Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 18 May 2015 17:03:08 Thorsten Glaser wrote: > >MIPS on the other hand is no more broken than any of the other 32-bit > >ABIs, because it does not use 64-bit __kernel_long_t in its n32 ABI. > > I have heard from a MIPS porter that one of the flavours suffers > from similar problems as x32, just not to that extent. But I > don’t recall my source… MIPS n32 has a lot of the same issues as x86 x32, but I'm pretty sure that the time_t one is not among them. > >ioctls. My plan at this point is to eliminate all uses of time_t in > >the kernel and replace them with time64_t or other safe types. > >This way, we will eventually find all code that passes 32-bit time types > >to user space and can fix it. This will take care of the time_t > >related problems on x32 as well. > > Ah, interesting approach. And existing userspace, as well as new > userspace that does not declare 64-bit time_t readiness, is still > safe on currently-not-broken architectures? So, there’s enough time > to fix this before the various libcs turn that on (and it had better > be fixed by then, because it becomes ABI by then). Nice idea. Correct. Another aspect of the approach I'm taking is that the system-call implementation is shared between the native 64-bit case and the new 32-bit case, while the handling for the existing syscalls on 32-bit architectures is shared with the 32-bit compat code on 64-bit architectures. This means if we introduce a bug in either of them, we will find out very quickly and don't have to wait until people start using 64-bit time_t on 32-bit user land. > I am wondering a bit about the ioctls being hard to find. I have > not much experience with kernel programming, and even less with > Linux than with MS-DOS and BSD, but should not each driver have > a central ioctl entry point, from which it should cast the user > space data into a (possibly locally declared) structure? Yes, that's how it works, but unfortunately we have a few thousand drivers that declare an ioctl function, and I hope to do something better than brute-force search all of them. The other point is that we really need to fix all y2038-related bug in drivers, not just the ones in ioctl. This includes things like file systems storing time in 32-bit units on disk, or drivers trying to measure how much time has elapsed without communicating that value elsewhere, but failing when the time_t number goes negative. Arnd