[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191016233342.GA3075@gmail.com>
Date: Wed, 16 Oct 2019 16:33:42 -0700
From: Andrei Vagin <avagin@...il.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Vincenzo Frascino <vincenzo.frascino@....com>,
Dmitry Safonov <dima@...sta.com>, linux-kernel@...r.kernel.org,
Dmitry Safonov <0x7f454c46@...il.com>,
Andrei Vagin <avagin@...nvz.org>,
Adrian Reber <adrian@...as.de>,
Andy Lutomirski <luto@...nel.org>,
Arnd Bergmann <arnd@...db.de>,
Christian Brauner <christian.brauner@...ntu.com>,
Cyrill Gorcunov <gorcunov@...nvz.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
Jann Horn <jannh@...gle.com>, Jeff Dike <jdike@...toit.com>,
Oleg Nesterov <oleg@...hat.com>,
Pavel Emelyanov <xemul@...tuozzo.com>,
Shuah Khan <shuah@...nel.org>,
containers@...ts.linux-foundation.org, criu@...nvz.org,
linux-api@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCHv7 01/33] ns: Introduce Time Namespace
On Wed, Oct 16, 2019 at 12:39:11PM +0200, Thomas Gleixner wrote:
> On Wed, 16 Oct 2019, Vincenzo Frascino wrote:
>
> < Trim 250+ lines ( 3+ pages) of pointlessly wasted electrons >
>
> > > --- a/init/Kconfig
> > > +++ b/init/Kconfig
> > > @@ -1096,6 +1096,13 @@ config UTS_NS
> > > In this namespace tasks see different info provided with the
> > > uname() system call
> > >
> > > +config TIME_NS
> > > + bool "TIME namespace"
> > > + default y
> >
> > Having CONFIG_TIME_NS "default y" makes so that the option is selected even on
> > the architectures that have no support for time namespaces.
> > The direct consequence is that the fallbacks defined in this patch are never
> > selected and this ends up in kernel compilation errors due to missing symbols.
> >
> > The error below shows what happens on arm64 (similar behavior on other
> > architectures):
> >
> > aarch64-linux-gnu-ld: kernel/time/namespace.o: in function `timens_on_fork':
> > kernel/time/namespace.c:321: undefined reference to `vdso_join_timens'
> >
> > My proposal is to keep TIME_NS "default n" (just remove "default y"), let the
> > architectures that enable time namespaces select it and make CONFIG_TIME_NS
> > select GENERIC_VDSO_TIME_NS if arch has HAVE_GENERIC_VDSO.
>
> Nah.
>
> config TIME_NS
> bool "TIME namespace"
> depends on GENERIC_VDSO_TIME_NS
I was thinking to fix this by the same way with a small difference.
If GENERIC_GETTIMEOFDAY isn't set, it should be safe to allow enabling
TIME_NS. In this case, clock_gettime works via system call and we don't
have arch-specific code in this case. Does this sound reasonable?
depends on (!GENERIC_GETTIMEOFDAY || GENERIC_VDSO_TIME_NS)
Thanks,
Andrei
Powered by blists - more mailing lists