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]
Message-ID: <alpine.DEB.2.20.1711160958430.2191@nanos>
Date:   Thu, 16 Nov 2017 10:04:00 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Deepa Dinamani <deepa.kernel@...il.com>
cc:     Arnd Bergmann <arnd@...db.de>,
        John Stultz <john.stultz@...aro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Chris Metcalf <cmetcalf@...lanox.com>, cohuck@...hat.com,
        David Miller <davem@...emloft.net>,
        Helge Deller <deller@....de>, devel@...verdev.osuosl.org,
        gerald.schaefer@...ibm.com, gregkh <gregkh@...uxfoundation.org>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Jan Hoeppner <hoeppner@...ux.vnet.ibm.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "James E.J. Bottomley" <jejb@...isc-linux.org>,
        Julian Wiedmann <jwi@...ux.vnet.ibm.com>,
        Linux API <linux-api@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        "open list:RALINK MIPS ARCHITECTURE" <linux-mips@...ux-mips.org>,
        Parisc List <linux-parisc@...r.kernel.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        linux-s390 <linux-s390@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        oberpar@...ux.vnet.ibm.com, oprofile-list@...ts.sf.net,
        Paul Mackerras <paulus@...ba.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ralf Baechle <ralf@...ux-mips.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Robert Richter <rric@...nel.org>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        sebott@...ux.vnet.ibm.com, sparclinux <sparclinux@...r.kernel.org>,
        Stefan Haberland <sth@...ux.vnet.ibm.com>,
        Ursula Braun <ubraun@...ux.vnet.ibm.com>,
        Will Deacon <will.deacon@....com>,
        the arch/x86 maintainers <x86@...nel.org>
Subject: Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t
 conversion

On Wed, 15 Nov 2017, Deepa Dinamani wrote:
> > I had on concern about x32, maybe we should check
> > for "COMPAT_USE_64BIT_TIME" before zeroing out the tv_nsec
> > bits.
> 
> Thanks, I think you are right. I had the check conditional on
> CONFIG_64BIT_TIME and then removed as I forgot why I added it. :)
> 
> > Regarding CONFIG_COMPAT_TIME/CONFIG_64BIT_TIME, would
> > it help to just leave out that part for now and unconditionally
> > define '__kernel_timespec' as 'timespec' until we are ready to
> > convert the architectures?
> 
> Another approach would be to use separate configs:
> 
> 1. To indicate 64 bit time_t syscall support. This will be dependent
> on architectures as CONFIG_64BIT_TIME.
> We can delete this once all architectures have provided support for this.
> 
> 2. Another config (maybe COMPAT_32BIT_TIME?) to be introduced later,
> which will compile out all syscalls/ features that use 32 bit time_t.
> This can help build a y2038 safe kernel later.
> 
> Would this work for everyone?

Having extra config switches which are selectable by architectures and
removed when everything is converted is definitely the right way to go.

That allows you to gradually convert stuff w/o inflicting wreckage all over
the place.

Thanks,

	tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ