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 >

quoted

quoted

--- 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