OpenVZ / Virtuozzo kernel development (devel@openvz.org)
 help / color / mirror / Atom feed
From: no-reply@sashiko.virtuozzo.com
To: khorenko@virtuozzo.com, Eva Kurchatova <eva.kurchatova@virtuozzo.com>
Cc: devel@openvz.org
Subject: Re: [Devel] [PATCH hci-8.1 3/4] ms/timens: Remove dependency on the vDSO
Date: Fri, 9 Oct 2026 14:06:53 +0000	[thread overview]
Message-ID: <010701a120fcfe42-80a270f4-284b-4c9e-aea4-1b373baf4a15-000000@eu-central-1.amazonses.com> (raw)
In-Reply-To: <20261009135929.3274885-4-eva.kurchatova@virtuozzo.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] timens: TIME_NS now selectable on SPARC, whose private vDSO ignores offsets
--

commit 07e6081c6b5ec1169db1364534dcb49acce62383
Author: Eva Kurchatova <eva.kurchatova@virtuozzo.com>

ms/timens: Remove dependency on the vDSO

This backport drops "depends on GENERIC_GETTIMEOFDAY" from TIME_NS. It adds
a TIME_NS_VDSO symbol that gates the vDSO-specific code, and it stubs out
timens_commit() and find_timens_vvar_page() when TIME_NS_VDSO is not set.

Link: https://patch.msgid.link/20260326-vdso-timens-decoupling-v2-2-c82693a7775f@linutronix.de

> diff --git a/init/Kconfig b/init/Kconfig
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1306,12 +1306,14 @@ config UTS_NS
>  
>  config TIME_NS
>  	bool "TIME namespace"
> -	depends on GENERIC_GETTIMEOFDAY
>  	default y
>  	help
>  	  In this namespace boottime and monotonic clocks can be set.
>  	  The time will keep going with the same pace.
>  
> +config TIME_NS_VDSO
> +	def_bool TIME_NS && GENERIC_GETTIMEOFDAY
> +

[Severity: Medium]
Can TIME_NS now be enabled on SPARC with a vDSO that ignores the offsets?

The commit message says "Now that all architectures using a real vDSO are
using the generic library, that dependency is not necessary anymore."
That does not appear to hold for SPARC in this tree. arch/sparc/Kconfig
selects only GENERIC_TIME_VSYSCALL. It does not select
GENERIC_GETTIMEOFDAY or HAVE_GENERIC_VDSO. The tree still contains
arch/sparc/vdso/vclock_gettime.c and
arch/sparc/vdso/vdso32/vclock_gettime.c.

Those files read the host vvar page directly:

arch/sparc/vdso/vclock_gettime.c:__vdso_clock_gettime() {
    ...
    case CLOCK_MONOTONIC:
        if (unlikely(vvd->vclock_mode == VCLOCK_NONE))
            break;
        return do_monotonic(vvd, ts);
    ...
}

They have no time namespace offset handling. Before this patch, the
GENERIC_GETTIMEOFDAY dependency kept TIME_NS (default y) off on SPARC.
With the dependency gone, TIME_NS is on by default there.
TIME_NS_VDSO is then n, so these two stubs do nothing:

include/linux/time_namespace.h:
#else /* !CONFIG_TIME_NS_VDSO */
static inline void timens_commit(struct task_struct *tsk, struct time_namespace *ns)
{
}

static inline struct page *find_timens_vvar_page(struct vm_area_struct *vma)
{
	return NULL;
}

On SPARC, unshare(CLONE_NEWTIME), setns() and writes to
/proc/<pid>/timens_offsets would all succeed. A task in a non-init time
namespace would still get host CLOCK_MONOTONIC and CLOCK_MONOTONIC_COARSE
from the vDSO, with no offset applied. The syscall path, /proc/uptime and
timerfd do apply the offset, so the two paths would disagree, and nothing
reports an error.

Should TIME_NS keep a dependency that excludes architectures whose vDSO is
not the generic one, such as SPARC? Alternatively, should the commit
message be corrected?

> diff --git a/include/linux/time_namespace.h b/include/linux/time_namespace.h
> --- a/include/linux/time_namespace.h
> +++ b/include/linux/time_namespace.h

[ ... ]

> +#ifdef CONFIG_TIME_NS_VDSO
> +extern void timens_commit(struct task_struct *tsk, struct time_namespace *ns);
> +struct page *find_timens_vvar_page(struct vm_area_struct *vma);
> +#else /* !CONFIG_TIME_NS_VDSO */
> +static inline void timens_commit(struct task_struct *tsk, struct time_namespace *ns)
> +{
> +}
> +
> +static inline struct page *find_timens_vvar_page(struct vm_area_struct *vma)
> +{
> +	return NULL;
> +}
> +#endif /* CONFIG_TIME_NS_VDSO */
> +
>  #endif /* _LINUX_TIMENS_H */

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261009135929.3274885-1-eva.kurchatova@virtuozzo.com?part=3

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

  reply	other threads:[~2026-10-09 14:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09 13:58 [Devel] [PATCH hci-8.1 0/4] timens: " Eva Kurchatova
2026-10-09 13:58 ` [Devel] [PATCH hci-8.1 1/4] ms/vdso: Drop Kconfig GENERIC_VDSO_TIME_NS Eva Kurchatova
2026-10-09 14:04   ` no-reply
2026-10-09 13:58 ` [Devel] [PATCH hci-8.1 2/4] ms/vdso/timens: Move functions to new file Eva Kurchatova
2026-10-09 14:03   ` no-reply
2026-10-09 13:58 ` [Devel] [PATCH hci-8.1 3/4] ms/timens: Remove dependency on the vDSO Eva Kurchatova
2026-10-09 14:06   ` no-reply [this message]
2026-10-09 13:58 ` [Devel] [PATCH hci-8.1 4/4] timens: freeze the offsets on the first join without the vDSO too Eva Kurchatova
2026-10-09 14:06   ` no-reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=010701a120fcfe42-80a270f4-284b-4c9e-aea4-1b373baf4a15-000000@eu-central-1.amazonses.com \
    --to=no-reply@sashiko.virtuozzo.com \
    --cc=devel@openvz.org \
    --cc=eva.kurchatova@virtuozzo.com \
    --cc=khorenko@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox