* Re: [PATCH v2 1/9] time: Respect COMPAT_32BIT_TIME for old time type functions
From: Arnd Bergmann @ 2026-06-30 13:00 UTC (permalink / raw)
To: Thomas Weißschuh, Andy Lutomirski, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Russell King, Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Thomas Bogendoerfer, Vincenzo Frascino, John Stultz, Stephen Boyd,
David S . Miller, Andreas Larsson
Cc: linux-kernel, linux-arm-kernel, linuxppc-dev, linux-mips,
linux-api, sparclinux
In-Reply-To: <20260630-vdso-compat_32bit_time-v2-1-520d194640dd@linutronix.de>
On Tue, Jun 30, 2026, at 09:38, Thomas Weißschuh wrote:
> The "old" time types use 32-bit seconds which are not y2038-safe.
> Respect COMPAT_32BIT_TIME for functions using those types.
> time(), stime() and gettimeofday() are disabled completely.
Looks good, yes
> settimeofday() is kept as it is required to do the initial timewarping
> after boot. However the 'tv' argument will be rejected.
Not sure about this part, did we already discuss this last time?
I can see how keeping the timewarping functionality is the easy way
out, but completely disabling the settimeofday syscall the same
way we do on new architectures seems so much more consistent.
Note how scripts/syscall.tbl blocks sys_settimeofday on
architectures that don't set the time32 flag, which ideally
should match the COMPAT_32BIT_TIME option here.
Arnd
^ permalink raw reply
* Re: [PATCH v2 0/9] vDSO: Respect COMPAT_32BIT_TIME
From: Arnd Bergmann @ 2026-06-30 13:16 UTC (permalink / raw)
To: Thomas Weißschuh, Andy Lutomirski, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Russell King, Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy,
Thomas Bogendoerfer, Vincenzo Frascino, John Stultz, Stephen Boyd,
David S . Miller, Andreas Larsson
Cc: linux-kernel, linux-arm-kernel, linuxppc-dev, linux-mips,
linux-api, sparclinux
In-Reply-To: <20260630-vdso-compat_32bit_time-v2-0-520d194640dd@linutronix.de>
On Tue, Jun 30, 2026, at 09:38, Thomas Weißschuh wrote:
> If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
> provide any 32-bit time related functionality. This is the intended
> effect of the kconfig option and also the fallback system calls would
> also not be implemented.
>
> Currently the kconfig option does not affect the gettimeofday() syscall,
> so also keep that in the vDSO.
>
> I also tried to introduce some helpers to avoid much of the ifdeffery,
> but due to the high variance in the architecture-specific glue code
> these would need to handle they ended up being worse than the current
> proposal.
>
> As a side-effect this will make the self-tests more reliable,
> as there is now always a matching syscall available for each vDSO function.
>
> clock_gettime_time64() was only introduced in v6.19, so libc implementations
^ clock_getres_time64()
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
once we have consensus on my patch 1/9 comment. Thanks for
continuing this work!
Arnd
^ permalink raw reply
* Re: [RFC] Null Namespaces
From: John Ericson @ 2026-06-30 17:20 UTC (permalink / raw)
To: Christian Brauner
Cc: Li Chen, Cong Wang, linux-arch, LKML, linux-fsdevel, linux-api,
Arnd Bergmann, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Jan Kara,
Jonathan Corbet, Shuah Khan, Al Viro, Kees Cook, Sergei Zimmerman,
Farid Zakaria
In-Reply-To: <20260630-kippen-jobaussicht-restriktionen-2149cc663b22@brauner>
I'll throw in the towel after this email, I promise :)
On Tue, Jun 30, 2026, at 3:14 AM, Christian Brauner wrote:
> I think Al is about to have a stroke reading this... and I might too.
Hahaha. Alas, C does have a longstanding beef with discriminated unions
--- I can't do anything about that! (Well, other than wait 15 years for
this stuff to eventually be rewritten in Rust, that is ;).)
> I agree with the sentiment
Thanks, I appreciate it :).
> You know what the easy solution is: don't allow a struct path to be
> empty...
Just so we're clear, my quibble here is purely behavioral: the nullfs
directory can be opened, right? And that open directory can also be
getdents64ed (yielding no entries, since it is empty), right? If I am
wrong about these things then sure, no objections from me --- let's ship
nullfs FDs right away!
My reasoning for being a bit of a weenie on that behavior is just that I
think "fail fast" is good. A lot of userspace programs crawl the file
space pretty willy-nilly (e.g. they are doing some caching thing, or
they are looking for something, etc.). I suspect the nullfs approach is
going to result in more "red herring" error messages and google searches
about "why can't I write to the working directory, not even as root"
etc. I just think "no directory" vs "immutable empty directory" sends a
clearer message to userspace, and will align mental models more rapidly.
Put another way, if there were no implementation downsides to either
approach, I assume everyone else would also slightly prefer "no
directory" over "immutable empty directory".
From that premise, I am further presuming that any non-empty `struct
path` to a directory that doesn't exist would be a real VFS crime, and
so making `optional_path` one way or another is the proper way to
implement this behavior.
If I am wrong about either step of my reasoning --- that nullfs like
every sort of FS ought to be openable/readdirable with sufficient perms
at the root, that a valid `struct path` to a "non-object" is bad design
--- do say so, and I'll drop the `optional_path` stuff completely.
> I disagree with the details of this
You mean the unergonomics of making a valid `optional_path`, right?
> and touching the whole kernel for this.
I want to make sure this is a difference in opinion and not a difference
in the view of the facts.
The linchpin of my prior email was that very little of the kernel cares
about these fields in `struct fs_struct`, or even cares about `struct
fs_struct` at all, so this is *not* a "whole kernel" change. Yes, thanks
to `current`, a bunch of code *could* look at this stuff if it wants to.
But it should *not* want to, regardless of what we do.
If there were a way to make parts of `struct task_struct` opaque
(without including another header) to enforce this design principle, I
would definitely go contribute that. (I remember the desire for
something like this coming up with the "fast headers" patches, but there
wasn't a good implementation strategy in C, alas.)
Likewise, for the tiny few usages outside of `fs/namei.c` that I found,
I would be happy to more creatively look at that code to see if I can
indeed avoid `struct fs_struct` altogether.
Cheers,
John
P.S. The "regardless of what we do" part was key to my earlier code
review argument that gave you "mixture of amusement and slight anger":
of course I don't expect other maintainers to keep abreast of subtle
null pointer invariants, but the simple rule that nothing but
`fs/namei.c` really ought to be consuming these `struct fs_struct`
fields is, I believe, all three of: good, already true, and intuitive.
^ permalink raw reply
* Re: [RFC] Null Namespaces
From: Andy Lutomirski @ 2026-06-30 17:41 UTC (permalink / raw)
To: John Ericson
Cc: Christian Brauner, Li Chen, Cong Wang, linux-arch, LKML,
linux-fsdevel, linux-api, Arnd Bergmann, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Jan Kara, Jonathan Corbet, Shuah Khan, Al Viro,
Kees Cook, Sergei Zimmerman, Farid Zakaria
In-Reply-To: <372c1f13-e6eb-46e6-8685-3c39da4e9f72@app.fastmail.com>
On Tue, Jun 30, 2026 at 10:20 AM John Ericson <mail@johnericson.me> wrote:
>
> I'll throw in the towel after this email, I promise :)
>
> On Tue, Jun 30, 2026, at 3:14 AM, Christian Brauner wrote:
> > I think Al is about to have a stroke reading this... and I might too.
>
> Hahaha. Alas, C does have a longstanding beef with discriminated unions
> --- I can't do anything about that! (Well, other than wait 15 years for
> this stuff to eventually be rewritten in Rust, that is ;).)
>
> > I agree with the sentiment
>
> Thanks, I appreciate it :).
>
> > You know what the easy solution is: don't allow a struct path to be
> > empty...
>
> Just so we're clear, my quibble here is purely behavioral: the nullfs
> directory can be opened, right? And that open directory can also be
> getdents64ed (yielding no entries, since it is empty), right? If I am
> wrong about these things then sure, no objections from me --- let's ship
> nullfs FDs right away!
>
Christian, how would you feel about a variant of nullfs that fails all
operations instead of acting as if it were empty? (I'm far from
convinced that this would actually be better, but it at least seems
pretty straightforwardly possible. And obviously the
nullfs-at-the-root-of-everything would not want this variant.)
> My reasoning for being a bit of a weenie on that behavior is just that I
> think "fail fast" is good. A lot of userspace programs crawl the file
> space pretty willy-nilly (e.g. they are doing some caching thing, or
> they are looking for something, etc.). I suspect the nullfs approach is
> going to result in more "red herring" error messages and google searches
> about "why can't I write to the working directory, not even as root"
> etc. I just think "no directory" vs "immutable empty directory" sends a
> clearer message to userspace, and will align mental models more rapidly.
This is the difference between a greenfield project and working with
existing designs.
If I were designing an OS and its entire API from scratch, then, sure,
the cwd and the root directory would just be well-known items in a
capability table, and they could be absent.
Linux's implementation and its API are not greenfield projects,
though, and it seems pretty silly to try to make this change.
--Andy
^ permalink raw reply
* Re: [RFC] Null Namespaces
From: H. Peter Anvin @ 2026-06-30 18:05 UTC (permalink / raw)
To: John Ericson, Christian Brauner
Cc: Li Chen, Cong Wang, linux-arch, LKML, linux-fsdevel, linux-api,
Arnd Bergmann, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, Jan Kara, Jonathan Corbet,
Shuah Khan, Al Viro, Kees Cook, Sergei Zimmerman, Farid Zakaria
In-Reply-To: <372c1f13-e6eb-46e6-8685-3c39da4e9f72@app.fastmail.com>
On June 30, 2026 10:20:05 AM PDT, John Ericson <mail@johnericson.me> wrote:
>I'll throw in the towel after this email, I promise :)
>
>On Tue, Jun 30, 2026, at 3:14 AM, Christian Brauner wrote:
>> I think Al is about to have a stroke reading this... and I might too.
>
>Hahaha. Alas, C does have a longstanding beef with discriminated unions
>--- I can't do anything about that! (Well, other than wait 15 years for
>this stuff to eventually be rewritten in Rust, that is ;).)
>
>> I agree with the sentiment
>
>Thanks, I appreciate it :).
>
>> You know what the easy solution is: don't allow a struct path to be
>> empty...
>
>Just so we're clear, my quibble here is purely behavioral: the nullfs
>directory can be opened, right? And that open directory can also be
>getdents64ed (yielding no entries, since it is empty), right? If I am
>wrong about these things then sure, no objections from me --- let's ship
>nullfs FDs right away!
>
>My reasoning for being a bit of a weenie on that behavior is just that I
>think "fail fast" is good. A lot of userspace programs crawl the file
>space pretty willy-nilly (e.g. they are doing some caching thing, or
>they are looking for something, etc.). I suspect the nullfs approach is
>going to result in more "red herring" error messages and google searches
>about "why can't I write to the working directory, not even as root"
>etc. I just think "no directory" vs "immutable empty directory" sends a
>clearer message to userspace, and will align mental models more rapidly.
>
>Put another way, if there were no implementation downsides to either
>approach, I assume everyone else would also slightly prefer "no
>directory" over "immutable empty directory".
>
>From that premise, I am further presuming that any non-empty `struct
>path` to a directory that doesn't exist would be a real VFS crime, and
>so making `optional_path` one way or another is the proper way to
>implement this behavior.
>
>If I am wrong about either step of my reasoning --- that nullfs like
>every sort of FS ought to be openable/readdirable with sufficient perms
>at the root, that a valid `struct path` to a "non-object" is bad design
>--- do say so, and I'll drop the `optional_path` stuff completely.
>
>> I disagree with the details of this
>
>You mean the unergonomics of making a valid `optional_path`, right?
>
>> and touching the whole kernel for this.
>
>I want to make sure this is a difference in opinion and not a difference
>in the view of the facts.
>
>The linchpin of my prior email was that very little of the kernel cares
>about these fields in `struct fs_struct`, or even cares about `struct
>fs_struct` at all, so this is *not* a "whole kernel" change. Yes, thanks
>to `current`, a bunch of code *could* look at this stuff if it wants to.
>But it should *not* want to, regardless of what we do.
>
>If there were a way to make parts of `struct task_struct` opaque
>(without including another header) to enforce this design principle, I
>would definitely go contribute that. (I remember the desire for
>something like this coming up with the "fast headers" patches, but there
>wasn't a good implementation strategy in C, alas.)
>
>Likewise, for the tiny few usages outside of `fs/namei.c` that I found,
>I would be happy to more creatively look at that code to see if I can
>indeed avoid `struct fs_struct` altogether.
>
>Cheers,
>
>John
>
>P.S. The "regardless of what we do" part was key to my earlier code
>review argument that gave you "mixture of amusement and slight anger":
>of course I don't expect other maintainers to keep abreast of subtle
>null pointer invariants, but the simple rule that nothing but
>`fs/namei.c` really ought to be consuming these `struct fs_struct`
>fields is, I believe, all three of: good, already true, and intuitive.
15 years?
Don't make me laugh...
^ permalink raw reply
* Re: [PATCH v2 0/7] vmsplice: fix some problems in my previous vmsplice patchset
From: Askar Safin @ 2026-07-01 4:00 UTC (permalink / raw)
To: Christian Brauner
Cc: David Hildenbrand (Arm), akpm, avagin, axboe, collin.funk1,
david.laight.linux, dhowells, fuse-devel, hch, jack, joannelkoong,
kernel, linux-api, linux-fsdevel, linux-kernel, linux-mm, luto,
metze, miklos, netdev, patches, pfalcato, torvalds, val, viro, w,
willy
In-Reply-To: <20260629-bauland-knabbern-abgeladen-c0acbfa62cc2@brauner>
On Mon, Jun 29, 2026 at 11:56 AM Christian Brauner <brauner@kernel.org> wrote:
> The amount of regression reports that we got in short succession doesn't
> make it likely that we can merge a plain degradation.
Let me repeat: this v2 patchset fixes all regressions found so far,
except for major CRIU performance regression
--
Askar Safin
^ permalink raw reply
* Re: [PATCH v2 2/9] vdso/gettimeofday: Validate system call existence for time() and gettimeofday()
From: Philippe Mathieu-Daudé @ 2026-07-01 7:47 UTC (permalink / raw)
To: Thomas Weißschuh, Andy Lutomirski, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Russell King, Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Thomas Bogendoerfer, Vincenzo Frascino, John Stultz, Stephen Boyd,
David S. Miller, Andreas Larsson
Cc: linux-kernel, linux-arm-kernel, linuxppc-dev, linux-mips,
Arnd Bergmann, linux-api, sparclinux
In-Reply-To: <20260630-vdso-compat_32bit_time-v2-2-520d194640dd@linutronix.de>
On 30/6/26 09:38, Thomas WeiÃschuh wrote:
> Not all architectures have the system calls for time() and
> gettimeofday(). When the system call is missing, the vDSO function
> should also not be present.
>
> Validate that.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> lib/vdso/gettimeofday.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 4/9] arm64: vdso32: Respect COMPAT_32BIT_TIME
From: Philippe Mathieu-Daudé @ 2026-07-01 7:49 UTC (permalink / raw)
To: Thomas Weißschuh, Andy Lutomirski, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Russell King, Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Thomas Bogendoerfer, Vincenzo Frascino, John Stultz, Stephen Boyd,
David S. Miller, Andreas Larsson
Cc: linux-kernel, linux-arm-kernel, linuxppc-dev, linux-mips,
Arnd Bergmann, linux-api, sparclinux
In-Reply-To: <20260630-vdso-compat_32bit_time-v2-4-520d194640dd@linutronix.de>
On 30/6/26 09:38, Thomas WeiÃschuh wrote:
> If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
> provide any 32-bit time related functionality. This is the intended
> effect of the kconfig option and also the fallback system calls would
> also not be implemented.
>
> Currently the kconfig option does not affect the gettimeofday() syscall,
> so also keep that in the vDSO.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> arch/arm64/kernel/vdso32/vdso.lds.S | 2 ++
> arch/arm64/kernel/vdso32/vgettimeofday.c | 14 ++++++++------
> 2 files changed, 10 insertions(+), 6 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 5/9] ARM: VDSO: Respect COMPAT_32BIT_TIME
From: Philippe Mathieu-Daudé @ 2026-07-01 7:49 UTC (permalink / raw)
To: Thomas Weißschuh, Andy Lutomirski, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Russell King, Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Thomas Bogendoerfer, Vincenzo Frascino, John Stultz, Stephen Boyd,
David S. Miller, Andreas Larsson
Cc: linux-kernel, linux-arm-kernel, linuxppc-dev, linux-mips,
Arnd Bergmann, linux-api, sparclinux
In-Reply-To: <20260630-vdso-compat_32bit_time-v2-5-520d194640dd@linutronix.de>
On 30/6/26 09:38, Thomas WeiÃschuh wrote:
> If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
> provide any 32-bit time related functionality. This is the intended
> effect of the kconfig option and also the fallback system calls would
> also not be implemented.
>
> Currently the kconfig option does not affect the gettimeofday() syscall,
> so also keep that in the vDSO.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> arch/arm/vdso/vdso.lds.S | 2 ++
> arch/arm/vdso/vgettimeofday.c | 14 ++++++++------
> 2 files changed, 10 insertions(+), 6 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 8/9] sparc: vdso: Respect COMPAT_32BIT_TIME
From: Philippe Mathieu-Daudé @ 2026-07-01 7:50 UTC (permalink / raw)
To: Thomas Weißschuh, Andy Lutomirski, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Russell King, Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Thomas Bogendoerfer, Vincenzo Frascino, John Stultz, Stephen Boyd,
David S. Miller, Andreas Larsson
Cc: linux-kernel, linux-arm-kernel, linuxppc-dev, linux-mips,
Arnd Bergmann, linux-api, sparclinux
In-Reply-To: <20260630-vdso-compat_32bit_time-v2-8-520d194640dd@linutronix.de>
On 30/6/26 09:38, Thomas WeiÃschuh wrote:
> If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
> provide any 32-bit time related functionality. This is the intended
> effect of the kconfig option and also the fallback system calls would
> also not be implemented.
>
> Currently the kconfig option does not affect the gettimeofday() syscall,
> so also keep that in the vDSO.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> arch/sparc/vdso/vclock_gettime.c | 4 ++++
> arch/sparc/vdso/vdso32/vdso32.lds.S | 6 ++++--
> 2 files changed, 8 insertions(+), 2 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 9/9] vdso/gettimeofday: Verify COMPAT_32BIT_TIME interactions
From: Philippe Mathieu-Daudé @ 2026-07-01 7:51 UTC (permalink / raw)
To: Thomas Weißschuh, Andy Lutomirski, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Russell King, Catalin Marinas, Will Deacon, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Thomas Bogendoerfer, Vincenzo Frascino, John Stultz, Stephen Boyd,
David S. Miller, Andreas Larsson
Cc: linux-kernel, linux-arm-kernel, linuxppc-dev, linux-mips,
Arnd Bergmann, linux-api, sparclinux
In-Reply-To: <20260630-vdso-compat_32bit_time-v2-9-520d194640dd@linutronix.de>
On 30/6/26 09:38, Thomas WeiÃschuh wrote:
> If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
> provide any 32-bit time related functionality.
>
> Add some build-time validations to make sure the architecture-specific
> glue satisfies this requirement.
>
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> lib/vdso/gettimeofday.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 1/9] time: Respect COMPAT_32BIT_TIME for old time type functions
From: Thomas Weißschuh @ 2026-07-01 8:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Russell King, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Thomas Bogendoerfer,
Vincenzo Frascino, John Stultz, Stephen Boyd, David S . Miller,
Andreas Larsson, linux-kernel, linux-arm-kernel, linuxppc-dev,
linux-mips, linux-api, sparclinux
In-Reply-To: <0cda7366-2eb9-4ecb-b76a-b3b68ee10043@app.fastmail.com>
On Tue, Jun 30, 2026 at 03:00:37PM +0200, Arnd Bergmann wrote:
> On Tue, Jun 30, 2026, at 09:38, Thomas Weißschuh wrote:
> > The "old" time types use 32-bit seconds which are not y2038-safe.
> > Respect COMPAT_32BIT_TIME for functions using those types.
> > time(), stime() and gettimeofday() are disabled completely.
>
> Looks good, yes
Sashiko found an issue [0], which I think is valid. I'll change that for v3.
> > settimeofday() is kept as it is required to do the initial timewarping
> > after boot. However the 'tv' argument will be rejected.
>
> Not sure about this part, did we already discuss this last time?
This is my interpretation of [1].
> I can see how keeping the timewarping functionality is the easy way
> out, but completely disabling the settimeofday syscall the same
> way we do on new architectures seems so much more consistent.
Shouldn't we then do this completely? Irrespective of COMPAT_32BIT_TIME?
And then remove all of the timewarping and kernel timezone bits.
It would be nice however if this series, and my other ones blocked behind it,
are not blocked on that larger rework.
(...)
[0] https://sashiko.dev/#/patchset/20260630-vdso-compat_32bit_time-v2-0-520d194640dd%40linutronix.de?part=1
[1] https://lore.kernel.org/all/e9487ebe-3730-438a-9c23-e45f75986ecc@app.fastmail.com/
Thomas
^ permalink raw reply
* Re: [RFC] Null Namespaces
From: Jori Koolstra @ 2026-07-01 9:49 UTC (permalink / raw)
To: Christian Brauner
Cc: John Ericson, H. Peter Anvin, Al Viro, Li Chen, Cong Wang,
linux-arch, LKML, linux-fsdevel, linux-api, Arnd Bergmann,
Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, Jan Kara, Jonathan Corbet, Shuah Khan, Kees Cook,
Sergei Zimmerman, Farid Zakaria
In-Reply-To: <20260629-zoomen-tragweite-redakteur-dc6c41c9c151@brauner>
On Mon, Jun 29, 2026 at 12:39:56PM +0200, Christian Brauner wrote:
> > The kernel rightfully has consolidated path resolution in a few key
> > places as much as possible -- the internal `struct path` does not suffer
> > from these issues. I barely modify those places to support null root and
> > CWD, and because of that consolidation, we shouldn't expect new places
> > to crop up in the future. (Duplicative path resolution logic is a bad
> > idea whether or not we have a nascent, little-used NULL-cwd/root code
> > path.) Therefore, I think existing code review, even among people
> > totally ignorant of this feature, will protect us --- the vast majority
> > of code will just be working with `struct path`, and be totally
> > unaffected by this change.
>
> I actually did laugh out loud reading this. I'm sorry, I can't really
> take this argument seriously. May I introduce you to drivers/ for a
> start and the history of path lookup exploits of the last - say 10
> years.
>
> You have to excuse me but it's a mixture of amusement and slight anger.
> Amusement because this is really naive and thus also a bit endearing.
> Anger because it single-handedly dismisses how big of an attack surface
> and problem space path lookup is. The equivalent of every math
> professor's "trivial. excercise left to the reader".
I could easily show you why path lookup is trivial, but I have no space
left in the margins of this email.
^ permalink raw reply
* Re: [PATCH v2 1/9] time: Respect COMPAT_32BIT_TIME for old time type functions
From: Arnd Bergmann @ 2026-07-01 13:11 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Russell King, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Thomas Bogendoerfer,
Vincenzo Frascino, John Stultz, Stephen Boyd, David S . Miller,
Andreas Larsson, linux-kernel, linux-arm-kernel, linuxppc-dev,
linux-mips, linux-api, sparclinux
In-Reply-To: <20260701102912-ea8f3291-7bba-407b-9a7d-7c367a4c9398@linutronix.de>
On Wed, Jul 1, 2026, at 10:40, Thomas Weißschuh wrote:
> On Tue, Jun 30, 2026 at 03:00:37PM +0200, Arnd Bergmann wrote:
>> On Tue, Jun 30, 2026, at 09:38, Thomas Weißschuh wrote:
>> > The "old" time types use 32-bit seconds which are not y2038-safe.
>> > Respect COMPAT_32BIT_TIME for functions using those types.
>> > time(), stime() and gettimeofday() are disabled completely.
>>
>> Looks good, yes
>
> Sashiko found an issue [0], which I think is valid. I'll change that for v3.
Ok
>> > settimeofday() is kept as it is required to do the initial timewarping
>> > after boot. However the 'tv' argument will be rejected.
>>
>> Not sure about this part, did we already discuss this last time?
>
> This is my interpretation of [1].
Indeed, we did.
>> I can see how keeping the timewarping functionality is the easy way
>> out, but completely disabling the settimeofday syscall the same
>> way we do on new architectures seems so much more consistent.
>
> Shouldn't we then do this completely? Irrespective of COMPAT_32BIT_TIME?
> And then remove all of the timewarping and kernel timezone bits.
I don't think we can simply kill the timewarping code since that
likely has users on architectures including on x86-64.
COMPAT_32BIT_TIME=n is somewhat special because this is an
intentional (and optional) ABI break already and requires
updated userspace that avoids the time32 syscalls. Having the
timewarp still in settimeofday() or dropping it entirely is not
that different for userspace.
I was slightly worried about whether returning -EINVAL or -ENOSYS
is the better option here, but I think your choice is the correct
one after seeing that this is what glibc does other invalid
cases, and that in all of codesearch.debian.net, I could not
find a single caller that would care about the difference.
> It would be nice however if this series, and my other ones blocked behind it,
> are not blocked on that larger rework.
Sure.
I think you can go ahead with this version. I would prefer
to not have any settimeofday() for the COMPAT_32BIT_TIME=n
case, but if nobody else has a strong opinion on the matter,
let's do it your way.
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH v2 0/7] vmsplice: fix some problems in my previous vmsplice patchset
From: Andrei Vagin @ 2026-07-01 19:16 UTC (permalink / raw)
To: Askar Safin
Cc: Christian Brauner, David Hildenbrand (Arm), akpm, axboe,
collin.funk1, david.laight.linux, dhowells, fuse-devel, hch, jack,
joannelkoong, kernel, linux-api, linux-fsdevel, linux-kernel,
linux-mm, luto, metze, miklos, netdev, patches, pfalcato,
torvalds, val, viro, w, willy
In-Reply-To: <CAPnZJGAJROqfCWSeeBu31HsE6nmgxVqHTNeC554S5y1Y-VN19w@mail.gmail.com>
On Tue, Jun 30, 2026 at 9:01 PM Askar Safin <safinaskar@gmail.com> wrote:
>
> On Mon, Jun 29, 2026 at 11:56 AM Christian Brauner <brauner@kernel.org> wrote:
> > The amount of regression reports that we got in short succession doesn't
> > make it likely that we can merge a plain degradation.
>
> Let me repeat: this v2 patchset fixes all regressions found so far,
> except for major CRIU performance regression
Askar,
As previously mentioned, this isn't just a major performance issue for
CRIU; it completely breaks the current pre-dump implementation.
The other proposed fixes look like workarounds that target specific
projects. Since few projects run tests on linux-next kernels, we should
expect more projects to be affected by these changes.
Thanks,
Andrei
^ permalink raw reply
* [PATCH v3 0/9] vDSO: Respect COMPAT_32BIT_TIME
From: Thomas Weißschuh @ 2026-07-02 8:21 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Russell King, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Thomas Bogendoerfer,
Vincenzo Frascino, John Stultz, Stephen Boyd, David S. Miller,
Andreas Larsson
Cc: Thomas Weißschuh, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-mips, Arnd Bergmann, linux-api, sparclinux,
Philippe Mathieu-Daudé
If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
provide any 32-bit time related functionality. This is the intended
effect of the kconfig option and also the fallback system calls would
also not be implemented.
I also tried to introduce some helpers to avoid much of the ifdeffery,
but due to the high variance in the architecture-specific glue code
these would need to handle, they ended up being worse than the current
proposal.
As a side-effect this will make the self-tests more reliable,
as there is now always a matching syscall available for each vDSO function.
clock_getres_time64() was only introduced in v6.19, so libc implementations
are likely not using it yet.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
Changes in v3:
- Pick up tags.
- Fix incorrect references gettimeofday() in per-arch commit messages.
- Test for CONFIG_COMPAT_32BIT_TIME over __WANT_OLD_TIME_TYPE_SYSCALL in compat_settimeofday()
- Link to v2: https://patch.msgid.link/20260630-vdso-compat_32bit_time-v2-0-520d194640dd@linutronix.de
Changes in v2:
- Also handle SPARC.
- Drop MIPS cleanup patches.
- Also handle gettimeofday().
- Add more static validations.
- Rebase on v7.2-rc1.
- Link to v1: https://lore.kernel.org/r/20260227-vdso-compat_32bit_time-v1-0-3f0286a7bac3@linutronix.de
To: Andy Lutomirski <luto@kernel.org>
To: Thomas Gleixner <tglx@kernel.org>
To: Ingo Molnar <mingo@redhat.com>
To: Borislav Petkov <bp@alien8.de>
To: Dave Hansen <dave.hansen@linux.intel.com>
To: x86@kernel.org
To: H. Peter Anvin <hpa@zytor.com>
To: Russell King <linux@armlinux.org.uk>
To: Catalin Marinas <catalin.marinas@arm.com>
To: Will Deacon <will@kernel.org>
To: Madhavan Srinivasan <maddy@linux.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>
To: Nicholas Piggin <npiggin@gmail.com>
To: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Vincenzo Frascino <vincenzo.frascino@arm.com>
To: John Stultz <jstultz@google.com>
To: Stephen Boyd <sboyd@kernel.org>
To: "David S. Miller" <davem@davemloft.net>
To: Andreas Larsson <andreas@gaisler.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-mips@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-api@vger.kernel.org
Cc: sparclinux@vger.kernel.org
Cc: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
---
Thomas Weißschuh (9):
time: Respect COMPAT_32BIT_TIME for old time type functions
vdso/gettimeofday: Validate system call existence for time() and gettimeofday()
x86/vdso: Respect COMPAT_32BIT_TIME
arm64: vdso32: Respect COMPAT_32BIT_TIME
ARM: VDSO: Respect COMPAT_32BIT_TIME
powerpc/vdso: Respect COMPAT_32BIT_TIME
MIPS: VDSO: Respect COMPAT_32BIT_TIME
sparc: vdso: Respect COMPAT_32BIT_TIME
vdso/gettimeofday: Verify COMPAT_32BIT_TIME interactions
arch/arm/vdso/vdso.lds.S | 2 ++
arch/arm/vdso/vgettimeofday.c | 14 ++++++++------
arch/arm64/kernel/vdso32/vdso.lds.S | 2 ++
arch/arm64/kernel/vdso32/vgettimeofday.c | 14 ++++++++------
arch/mips/vdso/vdso.lds.S | 2 ++
arch/mips/vdso/vgettimeofday.c | 3 +++
arch/powerpc/kernel/vdso/gettimeofday.S | 8 ++++++++
arch/powerpc/kernel/vdso/vdso32.lds.S | 8 +++++---
arch/powerpc/kernel/vdso/vgettimeofday.c | 16 ++++++++++------
arch/sparc/vdso/vclock_gettime.c | 4 ++++
arch/sparc/vdso/vdso32/vdso32.lds.S | 6 ++++--
arch/x86/entry/vdso/common/vclock_gettime.c | 20 ++++++++++++--------
arch/x86/entry/vdso/vdso32/vdso32.lds.S | 2 ++
kernel/sys_ni.c | 4 ++++
kernel/time/time.c | 24 ++++++++++++++++++++----
lib/vdso/gettimeofday.c | 20 ++++++++++++++++++++
16 files changed, 114 insertions(+), 35 deletions(-)
---
base-commit: e6da2429169af9b33f3629b69905d89bb5ee9e64
change-id: 20260113-vdso-compat_32bit_time-e808763e976a
Best regards,
--
Thomas Weißschuh (Schneider Electric) <thomas.weissschuh@linutronix.de>
^ permalink raw reply
* [PATCH v3 1/9] time: Respect COMPAT_32BIT_TIME for old time type functions
From: Thomas Weißschuh @ 2026-07-02 8:21 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Russell King, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Thomas Bogendoerfer,
Vincenzo Frascino, John Stultz, Stephen Boyd, David S. Miller,
Andreas Larsson
Cc: Thomas Weißschuh, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-mips, Arnd Bergmann, linux-api, sparclinux,
Philippe Mathieu-Daudé
In-Reply-To: <20260702-vdso-compat_32bit_time-v3-0-db9f36d8d432@linutronix.de>
The "old" time types use 32-bit seconds which are not y2038-safe.
Respect COMPAT_32BIT_TIME for functions using those types.
time(), stime() and gettimeofday() are disabled completely.
settimeofday() is kept as it is required to do the initial timewarping
after boot. However the 'tv' argument will be rejected.
Link: https://lore.kernel.org/lkml/e9487ebe-3730-438a-9c23-e45f75986ecc@app.fastmail.com/
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
kernel/sys_ni.c | 4 ++++
kernel/time/time.c | 24 ++++++++++++++++++++----
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index add3032da16f..c8be0abaa407 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -351,6 +351,10 @@ COND_SYSCALL(ppoll_time32);
COND_SYSCALL_COMPAT(ppoll_time32);
COND_SYSCALL(utimensat_time32);
COND_SYSCALL(clock_adjtime32);
+COND_SYSCALL(gettimeofday);
+COND_SYSCALL_COMPAT(gettimeofday);
+COND_SYSCALL(time);
+COND_SYSCALL(stime);
/*
* The syscalls below are not found in include/uapi/asm-generic/unistd.h
diff --git a/kernel/time/time.c b/kernel/time/time.c
index 0dd63a91e7c5..f836a31751f4 100644
--- a/kernel/time/time.c
+++ b/kernel/time/time.c
@@ -43,6 +43,12 @@
#include <generated/timeconst.h>
#include "timekeeping.h"
+#if defined(CONFIG_64BIT) || defined(CONFIG_COMPAT_32BIT_TIME)
+#define __WANT_OLD_TIME_TYPE_SYSCALL 1
+#endif
+
+static_assert(sizeof(__kernel_old_time_t) == 8 ? IS_ENABLED(__WANT_OLD_TIME_TYPE_SYSCALL) : true);
+
/*
* The timezone where the local system is located. Used as a default by some
* programs who obtain this value by using gettimeofday.
@@ -51,7 +57,7 @@ struct timezone sys_tz;
EXPORT_SYMBOL(sys_tz);
-#ifdef __ARCH_WANT_SYS_TIME
+#if defined(__ARCH_WANT_SYS_TIME) && defined(__WANT_OLD_TIME_TYPE_SYSCALL)
/*
* sys_time() can be implemented in user-level using
@@ -96,7 +102,7 @@ SYSCALL_DEFINE1(stime, __kernel_old_time_t __user *, tptr)
return 0;
}
-#endif /* __ARCH_WANT_SYS_TIME */
+#endif /* __ARCH_WANT_SYS_TIME && __WANT_OLD_TIME_TYPE_SYSCALL */
#ifdef CONFIG_COMPAT_32BIT_TIME
#ifdef __ARCH_WANT_SYS_TIME32
@@ -137,6 +143,7 @@ SYSCALL_DEFINE1(stime32, old_time32_t __user *, tptr)
#endif /* __ARCH_WANT_SYS_TIME32 */
#endif
+#ifdef __WANT_OLD_TIME_TYPE_SYSCALL
SYSCALL_DEFINE2(gettimeofday, struct __kernel_old_timeval __user *, tv,
struct timezone __user *, tz)
{
@@ -154,6 +161,7 @@ SYSCALL_DEFINE2(gettimeofday, struct __kernel_old_timeval __user *, tv,
}
return 0;
}
+#endif /* __WANT_OLD_TIME_TYPE_SYSCALL */
/*
* In case for some reason the CMOS clock has not already been running
@@ -203,6 +211,9 @@ SYSCALL_DEFINE2(settimeofday, struct __kernel_old_timeval __user *, tv,
struct timezone new_tz;
if (tv) {
+ if (!IS_ENABLED(__WANT_OLD_TIME_TYPE_SYSCALL))
+ return -EINVAL;
+
if (get_user(new_ts.tv_sec, &tv->tv_sec) ||
get_user(new_ts.tv_nsec, &tv->tv_usec))
return -EFAULT;
@@ -220,7 +231,7 @@ SYSCALL_DEFINE2(settimeofday, struct __kernel_old_timeval __user *, tv,
return do_sys_settimeofday64(tv ? &new_ts : NULL, tz ? &new_tz : NULL);
}
-#ifdef CONFIG_COMPAT
+#ifdef CONFIG_COMPAT_32BIT_TIME
COMPAT_SYSCALL_DEFINE2(gettimeofday, struct old_timeval32 __user *, tv,
struct timezone __user *, tz)
{
@@ -239,7 +250,9 @@ COMPAT_SYSCALL_DEFINE2(gettimeofday, struct old_timeval32 __user *, tv,
return 0;
}
+#endif /* CONFIG_COMPAT_32BIT_TIME */
+#ifdef CONFIG_COMPAT
COMPAT_SYSCALL_DEFINE2(settimeofday, struct old_timeval32 __user *, tv,
struct timezone __user *, tz)
{
@@ -247,6 +260,9 @@ COMPAT_SYSCALL_DEFINE2(settimeofday, struct old_timeval32 __user *, tv,
struct timezone new_tz;
if (tv) {
+ if (!IS_ENABLED(CONFIG_COMPAT_32BIT_TIME))
+ return -EINVAL;
+
if (get_user(new_ts.tv_sec, &tv->tv_sec) ||
get_user(new_ts.tv_nsec, &tv->tv_usec))
return -EFAULT;
@@ -263,7 +279,7 @@ COMPAT_SYSCALL_DEFINE2(settimeofday, struct old_timeval32 __user *, tv,
return do_sys_settimeofday64(tv ? &new_ts : NULL, tz ? &new_tz : NULL);
}
-#endif
+#endif /* CONFIG_COMPAT */
#ifdef CONFIG_64BIT
SYSCALL_DEFINE1(adjtimex, struct __kernel_timex __user *, txc_p)
--
2.55.0
^ permalink raw reply related
* [PATCH v3 2/9] vdso/gettimeofday: Validate system call existence for time() and gettimeofday()
From: Thomas Weißschuh @ 2026-07-02 8:21 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Russell King, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Thomas Bogendoerfer,
Vincenzo Frascino, John Stultz, Stephen Boyd, David S. Miller,
Andreas Larsson
Cc: Thomas Weißschuh, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-mips, Arnd Bergmann, linux-api, sparclinux,
Philippe Mathieu-Daudé
In-Reply-To: <20260702-vdso-compat_32bit_time-v3-0-db9f36d8d432@linutronix.de>
Not all architectures have the system calls for time() and
gettimeofday(). When the system call is missing, the vDSO function
should also not be present.
Validate that.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
lib/vdso/gettimeofday.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c
index e0f289d3d110..b8c1fc85eb74 100644
--- a/lib/vdso/gettimeofday.c
+++ b/lib/vdso/gettimeofday.c
@@ -12,6 +12,8 @@
#include <vdso/time32.h>
#include <vdso/time64.h>
+#include <uapi/linux/unistd.h>
+
/*
* The generic vDSO implementation requires that gettimeofday.h
* provides:
@@ -348,6 +350,10 @@ __cvdso_gettimeofday_data(const struct vdso_time_data *vd,
{
const struct vdso_clock *vc = vd->clock_data;
+#ifndef __NR_gettimeofday
+ BUILD_BUG();
+#endif
+
if (likely(tv != NULL)) {
struct __kernel_timespec ts;
@@ -382,6 +388,10 @@ __cvdso_time_data(const struct vdso_time_data *vd, __kernel_old_time_t *time)
const struct vdso_clock *vc = vd->clock_data;
__kernel_old_time_t t;
+#ifndef __NR_time
+ BUILD_BUG();
+#endif
+
if (vdso_is_timens_clock(vc)) {
vd = vdso_timens_data(vd);
vc = vd->clock_data;
--
2.55.0
^ permalink raw reply related
* [PATCH v3 3/9] x86/vdso: Respect COMPAT_32BIT_TIME
From: Thomas Weißschuh @ 2026-07-02 8:21 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Russell King, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Thomas Bogendoerfer,
Vincenzo Frascino, John Stultz, Stephen Boyd, David S. Miller,
Andreas Larsson
Cc: Thomas Weißschuh, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-mips, Arnd Bergmann, linux-api, sparclinux,
Philippe Mathieu-Daudé
In-Reply-To: <20260702-vdso-compat_32bit_time-v3-0-db9f36d8d432@linutronix.de>
If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
provide any 32-bit time related functionality. This is the intended
effect of the kconfig option and also the fallback system calls would
also not be implemented.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
arch/x86/entry/vdso/common/vclock_gettime.c | 20 ++++++++++++--------
arch/x86/entry/vdso/vdso32/vdso32.lds.S | 2 ++
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/x86/entry/vdso/common/vclock_gettime.c b/arch/x86/entry/vdso/common/vclock_gettime.c
index 57066f346b3f..304dbd1f9db4 100644
--- a/arch/x86/entry/vdso/common/vclock_gettime.c
+++ b/arch/x86/entry/vdso/common/vclock_gettime.c
@@ -15,6 +15,7 @@
#include "lib/vdso/gettimeofday.c"
+#if defined(__x86_64__) || defined(CONFIG_COMPAT_32BIT_TIME)
int __vdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz)
{
return __cvdso_gettimeofday(tv, tz);
@@ -29,6 +30,7 @@ __kernel_old_time_t __vdso_time(__kernel_old_time_t *t)
}
__kernel_old_time_t time(__kernel_old_time_t *t) __attribute__((weak, alias("__vdso_time")));
+#endif /* CONFIG_COMPAT_32BIT_TIME */
#if defined(CONFIG_X86_64) && !defined(BUILD_VDSO32_64)
@@ -51,6 +53,7 @@ int clock_getres(clockid_t, struct __kernel_timespec *)
#else
/* i386 only */
+#ifdef CONFIG_COMPAT_32BIT_TIME
int __vdso_clock_gettime(clockid_t clock, struct old_timespec32 *ts)
{
return __cvdso_clock_gettime32(clock, ts);
@@ -59,14 +62,6 @@ int __vdso_clock_gettime(clockid_t clock, struct old_timespec32 *ts)
int clock_gettime(clockid_t, struct old_timespec32 *)
__attribute__((weak, alias("__vdso_clock_gettime")));
-int __vdso_clock_gettime64(clockid_t clock, struct __kernel_timespec *ts)
-{
- return __cvdso_clock_gettime(clock, ts);
-}
-
-int clock_gettime64(clockid_t, struct __kernel_timespec *)
- __attribute__((weak, alias("__vdso_clock_gettime64")));
-
int __vdso_clock_getres(clockid_t clock, struct old_timespec32 *res)
{
return __cvdso_clock_getres_time32(clock, res);
@@ -74,6 +69,15 @@ int __vdso_clock_getres(clockid_t clock, struct old_timespec32 *res)
int clock_getres(clockid_t, struct old_timespec32 *)
__attribute__((weak, alias("__vdso_clock_getres")));
+#endif /* CONFIG_COMPAT_32BIT_TIME */
+
+int __vdso_clock_gettime64(clockid_t clock, struct __kernel_timespec *ts)
+{
+ return __cvdso_clock_gettime(clock, ts);
+}
+
+int clock_gettime64(clockid_t, struct __kernel_timespec *)
+ __attribute__((weak, alias("__vdso_clock_gettime64")));
int __vdso_clock_getres_time64(clockid_t clock, struct __kernel_timespec *ts)
{
diff --git a/arch/x86/entry/vdso/vdso32/vdso32.lds.S b/arch/x86/entry/vdso/vdso32/vdso32.lds.S
index cee8f7f9fe80..00629192db56 100644
--- a/arch/x86/entry/vdso/vdso32/vdso32.lds.S
+++ b/arch/x86/entry/vdso/vdso32/vdso32.lds.S
@@ -23,10 +23,12 @@ VERSION
{
LINUX_2.6 {
global:
+#ifdef CONFIG_COMPAT_32BIT_TIME
__vdso_clock_gettime;
__vdso_gettimeofday;
__vdso_time;
__vdso_clock_getres;
+#endif /* CONFIG_COMPAT_32BIT_TIME */
__vdso_clock_gettime64;
__vdso_clock_getres_time64;
__vdso_getcpu;
--
2.55.0
^ permalink raw reply related
* [PATCH v3 4/9] arm64: vdso32: Respect COMPAT_32BIT_TIME
From: Thomas Weißschuh @ 2026-07-02 8:21 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Russell King, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Thomas Bogendoerfer,
Vincenzo Frascino, John Stultz, Stephen Boyd, David S. Miller,
Andreas Larsson
Cc: Thomas Weißschuh, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-mips, Arnd Bergmann, linux-api, sparclinux,
Philippe Mathieu-Daudé
In-Reply-To: <20260702-vdso-compat_32bit_time-v3-0-db9f36d8d432@linutronix.de>
If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
provide any 32-bit time related functionality. This is the intended
effect of the kconfig option and also the fallback system calls would
also not be implemented.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm64/kernel/vdso32/vdso.lds.S | 2 ++
arch/arm64/kernel/vdso32/vgettimeofday.c | 14 ++++++++------
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/vdso32/vdso.lds.S b/arch/arm64/kernel/vdso32/vdso.lds.S
index c374fb0146f3..12bfc39e8aab 100644
--- a/arch/arm64/kernel/vdso32/vdso.lds.S
+++ b/arch/arm64/kernel/vdso32/vdso.lds.S
@@ -82,9 +82,11 @@ VERSION
{
LINUX_2.6 {
global:
+#ifdef CONFIG_COMPAT_32BIT_TIME
__vdso_clock_gettime;
__vdso_gettimeofday;
__vdso_clock_getres;
+#endif /* CONFIG_COMPAT_32BIT_TIME */
__vdso_clock_gettime64;
__vdso_clock_getres_time64;
local: *;
diff --git a/arch/arm64/kernel/vdso32/vgettimeofday.c b/arch/arm64/kernel/vdso32/vgettimeofday.c
index 0c6998ebe491..12d0255cc2cf 100644
--- a/arch/arm64/kernel/vdso32/vgettimeofday.c
+++ b/arch/arm64/kernel/vdso32/vgettimeofday.c
@@ -8,16 +8,17 @@
#define BUILD_VDSO32_64
#include <vdso/gettime.h>
+#ifdef CONFIG_COMPAT_32BIT_TIME
int __vdso_clock_gettime(clockid_t clock,
struct old_timespec32 *ts)
{
return __cvdso_clock_gettime32(clock, ts);
}
-int __vdso_clock_gettime64(clockid_t clock,
- struct __kernel_timespec *ts)
+int __vdso_clock_getres(clockid_t clock_id,
+ struct old_timespec32 *res)
{
- return __cvdso_clock_gettime(clock, ts);
+ return __cvdso_clock_getres_time32(clock_id, res);
}
int __vdso_gettimeofday(struct __kernel_old_timeval *tv,
@@ -25,11 +26,12 @@ int __vdso_gettimeofday(struct __kernel_old_timeval *tv,
{
return __cvdso_gettimeofday(tv, tz);
}
+#endif /* CONFIG_COMPAT_32BIT_TIME */
-int __vdso_clock_getres(clockid_t clock_id,
- struct old_timespec32 *res)
+int __vdso_clock_gettime64(clockid_t clock,
+ struct __kernel_timespec *ts)
{
- return __cvdso_clock_getres_time32(clock_id, res);
+ return __cvdso_clock_gettime(clock, ts);
}
int __vdso_clock_getres_time64(clockid_t clock_id, struct __kernel_timespec *res)
--
2.55.0
^ permalink raw reply related
* [PATCH v3 5/9] ARM: VDSO: Respect COMPAT_32BIT_TIME
From: Thomas Weißschuh @ 2026-07-02 8:21 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Russell King, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Thomas Bogendoerfer,
Vincenzo Frascino, John Stultz, Stephen Boyd, David S. Miller,
Andreas Larsson
Cc: Thomas Weißschuh, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-mips, Arnd Bergmann, linux-api, sparclinux,
Philippe Mathieu-Daudé
In-Reply-To: <20260702-vdso-compat_32bit_time-v3-0-db9f36d8d432@linutronix.de>
If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
provide any 32-bit time related functionality. This is the intended
effect of the kconfig option and also the fallback system calls would
also not be implemented.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/vdso/vdso.lds.S | 2 ++
arch/arm/vdso/vgettimeofday.c | 14 ++++++++------
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/vdso/vdso.lds.S b/arch/arm/vdso/vdso.lds.S
index 74d8d8bc8a40..e61038c0195a 100644
--- a/arch/arm/vdso/vdso.lds.S
+++ b/arch/arm/vdso/vdso.lds.S
@@ -70,9 +70,11 @@ VERSION
{
LINUX_2.6 {
global:
+#ifdef CONFIG_COMPAT_32BIT_TIME
__vdso_clock_gettime;
__vdso_gettimeofday;
__vdso_clock_getres;
+#endif /* CONFIG_COMPAT_32BIT_TIME */
__vdso_clock_gettime64;
__vdso_clock_getres_time64;
local: *;
diff --git a/arch/arm/vdso/vgettimeofday.c b/arch/arm/vdso/vgettimeofday.c
index f7a2f5dc2fdc..3eebeddbfd18 100644
--- a/arch/arm/vdso/vgettimeofday.c
+++ b/arch/arm/vdso/vgettimeofday.c
@@ -10,16 +10,17 @@
#include <asm/unwind.h>
#include <vdso/gettime.h>
+#ifdef CONFIG_COMPAT_32BIT_TIME
int __vdso_clock_gettime(clockid_t clock,
struct old_timespec32 *ts)
{
return __cvdso_clock_gettime32(clock, ts);
}
-int __vdso_clock_gettime64(clockid_t clock,
- struct __kernel_timespec *ts)
+int __vdso_clock_getres(clockid_t clock_id,
+ struct old_timespec32 *res)
{
- return __cvdso_clock_gettime(clock, ts);
+ return __cvdso_clock_getres_time32(clock_id, res);
}
int __vdso_gettimeofday(struct __kernel_old_timeval *tv,
@@ -27,11 +28,12 @@ int __vdso_gettimeofday(struct __kernel_old_timeval *tv,
{
return __cvdso_gettimeofday(tv, tz);
}
+#endif /* CONFIG_COMPAT_32BIT_TIME */
-int __vdso_clock_getres(clockid_t clock_id,
- struct old_timespec32 *res)
+int __vdso_clock_gettime64(clockid_t clock,
+ struct __kernel_timespec *ts)
{
- return __cvdso_clock_getres_time32(clock_id, res);
+ return __cvdso_clock_gettime(clock, ts);
}
int __vdso_clock_getres_time64(clockid_t clock_id, struct __kernel_timespec *res)
--
2.55.0
^ permalink raw reply related
* [PATCH v3 6/9] powerpc/vdso: Respect COMPAT_32BIT_TIME
From: Thomas Weißschuh @ 2026-07-02 8:21 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Russell King, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Thomas Bogendoerfer,
Vincenzo Frascino, John Stultz, Stephen Boyd, David S. Miller,
Andreas Larsson
Cc: Thomas Weißschuh, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-mips, Arnd Bergmann, linux-api, sparclinux,
Philippe Mathieu-Daudé
In-Reply-To: <20260702-vdso-compat_32bit_time-v3-0-db9f36d8d432@linutronix.de>
If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
provide any 32-bit time related functionality. This is the intended
effect of the kconfig option and also the fallback system calls would
also not be implemented.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/kernel/vdso/gettimeofday.S | 8 ++++++++
arch/powerpc/kernel/vdso/vdso32.lds.S | 8 +++++---
arch/powerpc/kernel/vdso/vgettimeofday.c | 16 ++++++++++------
3 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/vdso/gettimeofday.S b/arch/powerpc/kernel/vdso/gettimeofday.S
index 1c8e51691bf8..c635cd1e77be 100644
--- a/arch/powerpc/kernel/vdso/gettimeofday.S
+++ b/arch/powerpc/kernel/vdso/gettimeofday.S
@@ -67,9 +67,11 @@
* int __kernel_gettimeofday(struct timeval *tv, struct timezone *tz);
*
*/
+#if defined(__powerpc64__) || defined(CONFIG_COMPAT_32BIT_TIME)
V_FUNCTION_BEGIN(__kernel_gettimeofday)
cvdso_call __c_kernel_gettimeofday
V_FUNCTION_END(__kernel_gettimeofday)
+#endif
/*
* Exact prototype of clock_gettime()
@@ -77,9 +79,11 @@ V_FUNCTION_END(__kernel_gettimeofday)
* int __kernel_clock_gettime(clockid_t clock_id, struct timespec *tp);
*
*/
+#if defined(__powerpc64__) || defined(CONFIG_COMPAT_32BIT_TIME)
V_FUNCTION_BEGIN(__kernel_clock_gettime)
cvdso_call __c_kernel_clock_gettime
V_FUNCTION_END(__kernel_clock_gettime)
+#endif
/*
* Exact prototype of clock_gettime64()
@@ -99,9 +103,11 @@ V_FUNCTION_END(__kernel_clock_gettime64)
* int __kernel_clock_getres(clockid_t clock_id, struct timespec *res);
*
*/
+#if defined(__powerpc64__) || defined(CONFIG_COMPAT_32BIT_TIME)
V_FUNCTION_BEGIN(__kernel_clock_getres)
cvdso_call __c_kernel_clock_getres
V_FUNCTION_END(__kernel_clock_getres)
+#endif
/*
* Exact prototype of clock_getres_time64()
@@ -122,6 +128,8 @@ V_FUNCTION_END(__kernel_clock_getres_time64)
* time_t time(time *t);
*
*/
+#if defined(__powerpc64__) || defined(CONFIG_COMPAT_32BIT_TIME)
V_FUNCTION_BEGIN(__kernel_time)
cvdso_call __c_kernel_time call_time=1
V_FUNCTION_END(__kernel_time)
+#endif
diff --git a/arch/powerpc/kernel/vdso/vdso32.lds.S b/arch/powerpc/kernel/vdso/vdso32.lds.S
index 3f384a2526ae..5e87c18fd282 100644
--- a/arch/powerpc/kernel/vdso/vdso32.lds.S
+++ b/arch/powerpc/kernel/vdso/vdso32.lds.S
@@ -119,13 +119,15 @@ VERSION
{
VDSO_VERSION_STRING {
global:
- __kernel_get_syscall_map;
+#ifdef CONFIG_COMPAT_32BIT_TIME
__kernel_gettimeofday;
__kernel_clock_gettime;
- __kernel_clock_gettime64;
__kernel_clock_getres;
- __kernel_clock_getres_time64;
__kernel_time;
+#endif /* CONFIG_COMPAT_32BIT_TIME */
+ __kernel_get_syscall_map;
+ __kernel_clock_gettime64;
+ __kernel_clock_getres_time64;
__kernel_get_tbfreq;
__kernel_sync_dicache;
__kernel_sigtramp32;
diff --git a/arch/powerpc/kernel/vdso/vgettimeofday.c b/arch/powerpc/kernel/vdso/vgettimeofday.c
index 3c194e1ab562..4b712fb01a3f 100644
--- a/arch/powerpc/kernel/vdso/vgettimeofday.c
+++ b/arch/powerpc/kernel/vdso/vgettimeofday.c
@@ -18,23 +18,25 @@ int __c_kernel_clock_getres(clockid_t clock_id, struct __kernel_timespec *res,
return __cvdso_clock_getres_data(vd, clock_id, res);
}
#else
+#ifdef CONFIG_COMPAT_32BIT_TIME
int __c_kernel_clock_gettime(clockid_t clock, struct old_timespec32 *ts,
const struct vdso_time_data *vd)
{
return __cvdso_clock_gettime32_data(vd, clock, ts);
}
-int __c_kernel_clock_gettime64(clockid_t clock, struct __kernel_timespec *ts,
- const struct vdso_time_data *vd)
-{
- return __cvdso_clock_gettime_data(vd, clock, ts);
-}
-
int __c_kernel_clock_getres(clockid_t clock_id, struct old_timespec32 *res,
const struct vdso_time_data *vd)
{
return __cvdso_clock_getres_time32_data(vd, clock_id, res);
}
+#endif /* CONFIG_COMPAT_32BIT_TIME */
+
+int __c_kernel_clock_gettime64(clockid_t clock, struct __kernel_timespec *ts,
+ const struct vdso_time_data *vd)
+{
+ return __cvdso_clock_gettime_data(vd, clock, ts);
+}
int __c_kernel_clock_getres_time64(clockid_t clock_id, struct __kernel_timespec *res,
const struct vdso_time_data *vd)
@@ -43,6 +45,7 @@ int __c_kernel_clock_getres_time64(clockid_t clock_id, struct __kernel_timespec
}
#endif
+#if defined(__powerpc64__) || defined(CONFIG_COMPAT_32BIT_TIME)
int __c_kernel_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz,
const struct vdso_time_data *vd)
{
@@ -53,3 +56,4 @@ __kernel_old_time_t __c_kernel_time(__kernel_old_time_t *time, const struct vdso
{
return __cvdso_time_data(vd, time);
}
+#endif
--
2.55.0
^ permalink raw reply related
* [PATCH v3 7/9] MIPS: VDSO: Respect COMPAT_32BIT_TIME
From: Thomas Weißschuh @ 2026-07-02 8:21 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Russell King, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Thomas Bogendoerfer,
Vincenzo Frascino, John Stultz, Stephen Boyd, David S. Miller,
Andreas Larsson
Cc: Thomas Weißschuh, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-mips, Arnd Bergmann, linux-api, sparclinux,
Philippe Mathieu-Daudé
In-Reply-To: <20260702-vdso-compat_32bit_time-v3-0-db9f36d8d432@linutronix.de>
If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
provide any 32-bit time related functionality. This is the intended
effect of the kconfig option and also the fallback system calls would
also not be implemented.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
arch/mips/vdso/vdso.lds.S | 2 ++
arch/mips/vdso/vgettimeofday.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/arch/mips/vdso/vdso.lds.S b/arch/mips/vdso/vdso.lds.S
index 278ab6444e98..b11ee493c67f 100644
--- a/arch/mips/vdso/vdso.lds.S
+++ b/arch/mips/vdso/vdso.lds.S
@@ -97,9 +97,11 @@ VERSION
LINUX_2.6 {
#ifdef CONFIG_GENERIC_GETTIMEOFDAY
global:
+#if _MIPS_SIM == _MIPS_SIM_ABI64 || defined(CONFIG_COMPAT_32BIT_TIME)
__vdso_clock_gettime;
__vdso_gettimeofday;
__vdso_clock_getres;
+#endif
#if _MIPS_SIM != _MIPS_SIM_ABI64
__vdso_clock_gettime64;
__vdso_clock_getres_time64;
diff --git a/arch/mips/vdso/vgettimeofday.c b/arch/mips/vdso/vgettimeofday.c
index 00f9fcfc327e..a1fb06b8973e 100644
--- a/arch/mips/vdso/vgettimeofday.c
+++ b/arch/mips/vdso/vgettimeofday.c
@@ -12,6 +12,8 @@
#include <vdso/gettime.h>
#if _MIPS_SIM != _MIPS_SIM_ABI64
+
+#ifdef CONFIG_COMPAT_32BIT_TIME
int __vdso_clock_gettime(clockid_t clock,
struct old_timespec32 *ts)
{
@@ -29,6 +31,7 @@ int __vdso_clock_getres(clockid_t clock_id,
{
return __cvdso_clock_getres_time32(clock_id, res);
}
+#endif /* CONFIG_COMPAT_32BIT_TIME */
int __vdso_clock_gettime64(clockid_t clock,
struct __kernel_timespec *ts)
--
2.55.0
^ permalink raw reply related
* [PATCH v3 8/9] sparc: vdso: Respect COMPAT_32BIT_TIME
From: Thomas Weißschuh @ 2026-07-02 8:21 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Russell King, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Thomas Bogendoerfer,
Vincenzo Frascino, John Stultz, Stephen Boyd, David S. Miller,
Andreas Larsson
Cc: Thomas Weißschuh, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-mips, Arnd Bergmann, linux-api, sparclinux,
Philippe Mathieu-Daudé
In-Reply-To: <20260702-vdso-compat_32bit_time-v3-0-db9f36d8d432@linutronix.de>
If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
provide any 32-bit time related functionality. This is the intended
effect of the kconfig option and also the fallback system calls would
also not be implemented.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
arch/sparc/vdso/vclock_gettime.c | 4 ++++
arch/sparc/vdso/vdso32/vdso32.lds.S | 6 ++++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/sparc/vdso/vclock_gettime.c b/arch/sparc/vdso/vclock_gettime.c
index 1d9859392e4c..221bd4ed19f5 100644
--- a/arch/sparc/vdso/vclock_gettime.c
+++ b/arch/sparc/vdso/vclock_gettime.c
@@ -21,6 +21,7 @@
#include "../../../../lib/vdso/gettimeofday.c"
+#if defined(CONFIG_SPARC64) || defined(CONFIG_COMPAT_32BIT_TIME)
int __vdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz)
{
return __cvdso_gettimeofday(tv, tz);
@@ -28,6 +29,7 @@ int __vdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz)
int gettimeofday(struct __kernel_old_timeval *, struct timezone *)
__weak __alias(__vdso_gettimeofday);
+#endif
#if defined(CONFIG_SPARC64)
int __vdso_clock_gettime(clockid_t clock, struct __kernel_timespec *ts)
@@ -40,6 +42,7 @@ int clock_gettime(clockid_t, struct __kernel_timespec *)
#else
+#if defined(CONFIG_COMPAT_32BIT_TIME)
int __vdso_clock_gettime(clockid_t clock, struct old_timespec32 *ts)
{
return __cvdso_clock_gettime32(clock, ts);
@@ -47,6 +50,7 @@ int __vdso_clock_gettime(clockid_t clock, struct old_timespec32 *ts)
int clock_gettime(clockid_t, struct old_timespec32 *)
__weak __alias(__vdso_clock_gettime);
+#endif
int __vdso_clock_gettime64(clockid_t clock, struct __kernel_timespec *ts)
{
diff --git a/arch/sparc/vdso/vdso32/vdso32.lds.S b/arch/sparc/vdso/vdso32/vdso32.lds.S
index a14e4f77e6f2..28052168b875 100644
--- a/arch/sparc/vdso/vdso32/vdso32.lds.S
+++ b/arch/sparc/vdso/vdso32/vdso32.lds.S
@@ -15,12 +15,14 @@
VERSION {
LINUX_2.6 {
global:
+#ifdef CONFIG_COMPAT_32BIT_TIME
clock_gettime;
__vdso_clock_gettime;
- clock_gettime64;
- __vdso_clock_gettime64;
gettimeofday;
__vdso_gettimeofday;
+#endif
+ clock_gettime64;
+ __vdso_clock_gettime64;
local: *;
};
}
--
2.55.0
^ permalink raw reply related
* [PATCH v3 9/9] vdso/gettimeofday: Verify COMPAT_32BIT_TIME interactions
From: Thomas Weißschuh @ 2026-07-02 8:21 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Russell King, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Thomas Bogendoerfer,
Vincenzo Frascino, John Stultz, Stephen Boyd, David S. Miller,
Andreas Larsson
Cc: Thomas Weißschuh, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-mips, Arnd Bergmann, linux-api, sparclinux,
Philippe Mathieu-Daudé
In-Reply-To: <20260702-vdso-compat_32bit_time-v3-0-db9f36d8d432@linutronix.de>
If CONFIG_COMPAT_32BIT_TIME is disabled then the vDSO should not
provide any 32-bit time related functionality.
Add some build-time validations to make sure the architecture-specific
glue satisfies this requirement.
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Philippe Mathieu-Daudé <philmd@oss.qualcomm.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
lib/vdso/gettimeofday.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c
index b8c1fc85eb74..f7a591aba59f 100644
--- a/lib/vdso/gettimeofday.c
+++ b/lib/vdso/gettimeofday.c
@@ -25,6 +25,8 @@
*/
#include <asm/vdso/gettimeofday.h>
+#include <linux/build_bug.h>
+
/* Bring in default accessors */
#include <vdso/vsyscall.h>
@@ -325,6 +327,8 @@ __cvdso_clock_gettime32_data(const struct vdso_time_data *vd, clockid_t clock,
struct __kernel_timespec ts;
bool ok;
+ BUILD_BUG_ON(!IS_ENABLED(CONFIG_COMPAT_32BIT_TIME));
+
ok = __cvdso_clock_gettime_common(vd, clock, &ts);
if (unlikely(!ok))
@@ -354,6 +358,8 @@ __cvdso_gettimeofday_data(const struct vdso_time_data *vd,
BUILD_BUG();
#endif
+ BUILD_BUG_ON(sizeof(tv->tv_sec) != 8 && !IS_ENABLED(CONFIG_COMPAT_32BIT_TIME));
+
if (likely(tv != NULL)) {
struct __kernel_timespec ts;
@@ -392,6 +398,8 @@ __cvdso_time_data(const struct vdso_time_data *vd, __kernel_old_time_t *time)
BUILD_BUG();
#endif
+ BUILD_BUG_ON(sizeof(*time) != 8 && !IS_ENABLED(CONFIG_COMPAT_32BIT_TIME));
+
if (vdso_is_timens_clock(vc)) {
vd = vdso_timens_data(vd);
vc = vd->clock_data;
@@ -481,6 +489,8 @@ __cvdso_clock_getres_time32_data(const struct vdso_time_data *vd, clockid_t cloc
struct __kernel_timespec ts;
bool ok;
+ BUILD_BUG_ON(!IS_ENABLED(CONFIG_COMPAT_32BIT_TIME));
+
ok = __cvdso_clock_getres_common(vd, clock, &ts);
if (unlikely(!ok))
--
2.55.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).