| Message ID | 20171110224259.15930-1-deepa.kernel@gmail.com |
|---|---|
| Headers | show |
| Series | posix_clocks: Prepare syscalls for 64 bit time_t conversion | expand |
On Fri, Nov 10, 2017 at 11:42 PM, Deepa Dinamani <deepa.kernel@gmail.com> wrote: > The series is a preparation series for individual architectures > to use 64 bit time_t syscalls in compat and 32 bit emulation modes. > > This is a follow up to the series Arnd Bergmann posted: > https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html > > Big picture is as per the lwn article: > https://lwn.net/Articles/643234/ > > The series is directed at converting posix clock syscalls: > clock_gettime, clock_settime, clock_getres and clock_nanosleep > to use a new data structure __kernel_timespec at syscall boundaries. > __kernel_timespec maintains 64 bit time_t across all execution modes. > > vdso will be handled as part of each architecture when they enable > support for 64 bit time_t. > > The compat syscalls are repurposed to provide backward compatibility > by using them as native syscalls as well for 32 bit architectures. > They will continue to use timespec at syscall boundaries. > > CONFIG_64_BIT_TIME controls whether the syscalls use __kernel_timespec > or timespec at syscall boundaries. > > The series does the following: > 1. Enable compat syscalls unconditionally. > 2. Add a new __kernel_timespec type to be used as the data structure > for all the new syscalls. > 3. Add new config CONFIG_64BIT_TIME(intead of the CONFIG_COMPAT_TIME in > [1] and [2] to switch to new definition of __kernel_timespec. It is > the same as struct timespec otherwise. > > Arnd Bergmann (1): > y2038: introduce CONFIG_64BIT_TIME The series looks good to me overall, and I've added it to my build-testing tree to see if it shows any regressions in random configurations. I had on concern about x32, maybe we should check for "COMPAT_USE_64BIT_TIME" before zeroing out the tv_nsec bits. 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? Arnd -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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? -Deepa -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > 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. 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 sys_nanosleep in "#if !defined(CONFIG_64BIT_TIME) || defined(CONFIG_64BIT)", or should we try to come up with another Kconfig symbol name that expresses this better? Arnd -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 17 Nov 2017, Arnd Bergmann wrote: > On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner <tglx@linutronix.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? Thanks tglx -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > On Fri, 17 Nov 2017, Arnd Bergmann wrote: >> On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner <tglx@linutronix.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. Arnd -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 17 Nov 2017, Arnd Bergmann wrote: > On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > > On Fri, 17 Nov 2017, Arnd Bergmann wrote: > >> On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner <tglx@linutronix.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 -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 17, 2017 at 10:54 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > On Fri, 17 Nov 2017, Arnd Bergmann wrote: >> On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <tglx@linutronix.de> wrote: >> >> 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. How about this: config LEGACY_TIME_SYSCALLS def_bool 64BIT || !64BIT_TIME help This controls the compilation of the following system calls: time, stime, gettimeofday, settimeofday, adjtimex, nanosleep, alarm, getitimer, setitimer, select, utime, utimes, futimesat, and {old,new}{l,f,}stat{,64}. These all pass 32-bit time_t arguments on 32-bit architectures and are replaced by other interfaces (e.g. posix timers and clocks, statx). C libraries implementing 64-bit time_t in 32-bit architectures have to implement the handles by wrapping around the newer interfaces. New architectures should not explicitly disable this. Arnd -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 17 Nov 2017, Arnd Bergmann wrote: > On Fri, Nov 17, 2017 at 10:54 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > > On Fri, 17 Nov 2017, Arnd Bergmann wrote: > >> On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > >> > >> 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. > > How about this: > > config LEGACY_TIME_SYSCALLS > def_bool 64BIT || !64BIT_TIME > help > This controls the compilation of the following system calls: > time, stime, > gettimeofday, settimeofday, adjtimex, nanosleep, alarm, getitimer, > setitimer, select, utime, utimes, futimesat, and > {old,new}{l,f,}stat{,64}. > These all pass 32-bit time_t arguments on 32-bit architectures and > are replaced by other interfaces (e.g. posix timers and clocks, statx). > C libraries implementing 64-bit time_t in 32-bit architectures have to > implement the handles by wrapping around the newer interfaces. s/handles/handling/ ???? > New architectures should not explicitly disable this. New architectures should never enable this, right? Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Nov 17, 2017 at 11:40 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > On Fri, 17 Nov 2017, Arnd Bergmann wrote: >> On Fri, Nov 17, 2017 at 10:54 AM, Thomas Gleixner <tglx@linutronix.de> wrote: >> > On Fri, 17 Nov 2017, Arnd Bergmann wrote: >> >> On Fri, Nov 17, 2017 at 9:58 AM, Thomas Gleixner <tglx@linutronix.de> wrote: >> >> >> >> 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. >> >> How about this: >> >> config LEGACY_TIME_SYSCALLS >> def_bool 64BIT || !64BIT_TIME >> help >> This controls the compilation of the following system calls: >> time, stime, >> gettimeofday, settimeofday, adjtimex, nanosleep, alarm, getitimer, >> setitimer, select, utime, utimes, futimesat, and >> {old,new}{l,f,}stat{,64}. >> These all pass 32-bit time_t arguments on 32-bit architectures and >> are replaced by other interfaces (e.g. posix timers and clocks, statx). >> C libraries implementing 64-bit time_t in 32-bit architectures have to >> implement the handles by wrapping around the newer interfaces. > > s/handles/handling/ ???? I meant "handlers". >> New architectures should not explicitly disable this. > > New architectures should never enable this, right? Right, I got an extra "not". I guess if Deepa incorporates the new option, she can also improve my English ;-) Arnd -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html