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
next prev parent 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