linux-kernel - Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 17 Nov 2017 10:54:07 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Arnd Bergmann <arnd@...db.de>
cc:     Deepa Dinamani <deepa.kernel@...il.com>,
        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 Fri, 17 Nov 2017, Arnd Bergmann wrote:
> On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> > On Fri, 17 Nov 2017, Arnd Bergmann wrote:
> >> On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> >> > On Wed, 15 Nov 2017, Deepa Dinamani wrote:
> >> >> 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.
> >>
> >> The CONFIG_64BIT_TIME would do that nicely for the new stuff like
> >> the conditional definition of __kernel_timespec, this one would get
> >> removed after we convert all architectures.
> >>
> >> A second issue is how to control the compilation of the compat syscalls.
> >> CONFIG_COMPAT_32BIT_TIME handles that and could be defined
> >> in Kconfig as 'def_bool (!64BIT && CONFIG_64BIT_TIME) || COMPAT',
> >> this is then just a more readable way of expressing exactly when the
> >> functions should be built.
> >>
> >> For completeness, there may be a third category, depending on how
> >> we handle things like sys_nanosleep(): Here, we want the native
> >> sys_nanosleep on 64-bit architectures, and compat_sys_nanosleep()
> >> to handle the 32-bit time_t variant on both 32-bit and 64-bit targets,
> >> but our plan is to not have a native 32-bit sys_nanosleep on 32-bit
> >> architectures any more, as new glibc should call clock_nanosleep()
> >> with a new syscall number instead. Should we then enclose
> >
> > Isn't that going to break existing userspace?
> 
> No, syscall that existing 32-bit user space enters would be handled by
> compat_sys_nanosleep() on both 32-bit and 64-bit kernels at that
> point. The idea here is to make the code path more uniform between
> 32-bit and 64-bit kernels.

So on a 32bit system compat_sys_nanosleep() would be the legacy
sys_nanosleep() with the existing syscall number, but you don't want to
introduce a new sys_nanosleep64() for 32bit. That makes a lot of sense.

So back to your original question whether to use #if (MAGIC logic) or a
separate config symbol. Please use the latter, these magic logic constructs
are harder to read and prone to get wrong at some point. Having the
decision logic in one place is always the right thing to do.

Thanks,

	tglx