arch/x86/entry/vdso/common/vclock_gettime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
To get from arch/x86/entry/vdso/common/vclock_gettime.c to
lib/vdso/gettimeofday.c, you need 5 "..", not 4.
Proof:
$ (cd "$(dirname arch/x86/entry/vdso/common/vclock_gettime.c)" && ls ../../../../lib/vdso/gettimeofday.c)
ls: cannot access '../../../../lib/vdso/gettimeofday.c': No such file or directory
$ (cd "$(dirname arch/x86/entry/vdso/common/vclock_gettime.c)" && ls ../../../../../lib/vdso/gettimeofday.c)
../../../../../lib/vdso/gettimeofday.c
I'm blaming the commit below because it moved vclock_gettime.c from
arch/x86/entry/vdso/vclock_gettime.c to
arch/x86/entry/vdso/common/vclock_gettime.c
without updating the relative include path.
This shows up on an x86 allmodconfig build, I don't really know why it
hasn't been reported so far.
The fix, though, is to make the include path a bit more robust. Benefit
from the fact that arch/x86/entry/vdso/common/Makefile.include sets up
"flags-y += -I$(srctree)", and just specify the include path relative to
the kernel root directory. This was done in a few places in the blamed
commit, but here it was missed.
Fixes: 693c819fedcd ("x86/entry/vdso: Refactor the vdso build")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
arch/x86/entry/vdso/common/vclock_gettime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/entry/vdso/common/vclock_gettime.c b/arch/x86/entry/vdso/common/vclock_gettime.c
index 027b7e88d753..57066f346b3f 100644
--- a/arch/x86/entry/vdso/common/vclock_gettime.c
+++ b/arch/x86/entry/vdso/common/vclock_gettime.c
@@ -13,7 +13,7 @@
#include <linux/types.h>
#include <vdso/gettime.h>
-#include "../../../../lib/vdso/gettimeofday.c"
+#include "lib/vdso/gettimeofday.c"
int __vdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz)
{
--
2.43.0
On Sat, Mar 07, 2026 at 07:44:06PM +0200, vladimir.oltean@nxp.com wrote:
> To get from arch/x86/entry/vdso/common/vclock_gettime.c to
> lib/vdso/gettimeofday.c, you need 5 "..", not 4.
>
> Proof:
> $ (cd "$(dirname arch/x86/entry/vdso/common/vclock_gettime.c)" && ls ../../../../lib/vdso/gettimeofday.c)
> ls: cannot access '../../../../lib/vdso/gettimeofday.c': No such file or directory
> $ (cd "$(dirname arch/x86/entry/vdso/common/vclock_gettime.c)" && ls ../../../../../lib/vdso/gettimeofday.c)
> ../../../../../lib/vdso/gettimeofday.c
>
> I'm blaming the commit below because it moved vclock_gettime.c from
> arch/x86/entry/vdso/vclock_gettime.c to
> arch/x86/entry/vdso/common/vclock_gettime.c
> without updating the relative include path.
>
> This shows up on an x86 allmodconfig build, I don't really know why it
> hasn't been reported so far.
I see what you mean and it does sound plausible but allmodconfig builds fine
here. Perhaps you're doing it differently from how I'm doing it ...
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Sat, Mar 07, 2026 at 08:09:44PM +0100, Borislav Petkov wrote: > On Sat, Mar 07, 2026 at 07:44:06PM +0200, vladimir.oltean@nxp.com wrote: > > To get from arch/x86/entry/vdso/common/vclock_gettime.c to > > lib/vdso/gettimeofday.c, you need 5 "..", not 4. > > > > Proof: > > $ (cd "$(dirname arch/x86/entry/vdso/common/vclock_gettime.c)" && ls ../../../../lib/vdso/gettimeofday.c) > > ls: cannot access '../../../../lib/vdso/gettimeofday.c': No such file or directory > > $ (cd "$(dirname arch/x86/entry/vdso/common/vclock_gettime.c)" && ls ../../../../../lib/vdso/gettimeofday.c) > > ../../../../../lib/vdso/gettimeofday.c > > > > I'm blaming the commit below because it moved vclock_gettime.c from > > arch/x86/entry/vdso/vclock_gettime.c to > > arch/x86/entry/vdso/common/vclock_gettime.c > > without updating the relative include path. > > > > This shows up on an x86 allmodconfig build, I don't really know why it > > hasn't been reported so far. > > I see what you mean and it does sound plausible but allmodconfig builds fine > here. Perhaps you're doing it differently from how I'm doing it ... > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette cc="ccache gcc" output_dir=build_allmodconfig_warn/ ncpu=$(grep -c processor /proc/cpuinfo) build_flags="-Oline -j $ncpu W=1 C=1" tmpfile_o=$(mktemp) tmpfile_n=$(mktemp) make CC="$cc" O=$output_dir allmodconfig ./scripts/config --file $output_dir/.config -d werror ./scripts/config --file $output_dir/.config -d drm_werror ./scripts/config --file $output_dir/.config -d kvm_werror ./scripts/config --file $output_dir/.config -d rust ./scripts/config --file $output_dir/.config -d security_apparmor make CC="$cc" O=$output_dir $build_flags
On 2026-03-07 16:21, Vladimir Oltean wrote: > > cc="ccache gcc" > output_dir=build_allmodconfig_warn/ > ncpu=$(grep -c processor /proc/cpuinfo) > build_flags="-Oline -j $ncpu W=1 C=1" > tmpfile_o=$(mktemp) > tmpfile_n=$(mktemp) > > make CC="$cc" O=$output_dir allmodconfig > ./scripts/config --file $output_dir/.config -d werror > ./scripts/config --file $output_dir/.config -d drm_werror > ./scripts/config --file $output_dir/.config -d kvm_werror > ./scripts/config --file $output_dir/.config -d rust > ./scripts/config --file $output_dir/.config -d security_apparmor > > make CC="$cc" O=$output_dir $build_flags Any chance you have a stale ccache? -hpa
On Sat, Mar 07, 2026 at 04:29:47PM -0800, H. Peter Anvin wrote: > On 2026-03-07 16:21, Vladimir Oltean wrote: > > > > cc="ccache gcc" > > output_dir=build_allmodconfig_warn/ > > ncpu=$(grep -c processor /proc/cpuinfo) > > build_flags="-Oline -j $ncpu W=1 C=1" > > tmpfile_o=$(mktemp) > > tmpfile_n=$(mktemp) > > > > make CC="$cc" O=$output_dir allmodconfig > > ./scripts/config --file $output_dir/.config -d werror > > ./scripts/config --file $output_dir/.config -d drm_werror > > ./scripts/config --file $output_dir/.config -d kvm_werror > > ./scripts/config --file $output_dir/.config -d rust > > ./scripts/config --file $output_dir/.config -d security_apparmor > > > > make CC="$cc" O=$output_dir $build_flags > > Any chance you have a stale ccache? > > -hpa I'm not sure stale in which sense (I don't seem to have problems otherwise), but I don't really have time to split hairs on such an insignificant topic, sorry. The include path is wrong.
On Mon, Mar 09, 2026 at 08:38:03PM +0200, Vladimir Oltean wrote:
> I'm not sure stale in which sense (I don't seem to have problems
> otherwise), but I don't really have time to split hairs on such an
> insignificant topic, sorry. The include path is wrong.
This is not splitting hairs - we're trying to figure out how *you* have seen
it and we haven't so that we can make sure we're not missing an angle while
testing.
I'll fix up your commit message to match what's happening.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On March 9, 2026 11:46:15 AM PDT, Borislav Petkov <bp@alien8.de> wrote: >On Mon, Mar 09, 2026 at 08:38:03PM +0200, Vladimir Oltean wrote: >> I'm not sure stale in which sense (I don't seem to have problems >> otherwise), but I don't really have time to split hairs on such an >> insignificant topic, sorry. The include path is wrong. > >This is not splitting hairs - we're trying to figure out how *you* have seen >it and we haven't so that we can make sure we're not missing an angle while >testing. > >I'll fix up your commit message to match what's happening. > One of the reasons I'm asking is because ccache staleness has been a real issue in my experience. I gave up on ccache for that reason a long time ago – between the extra overhead, relatively low cache hit rate, and inability to help with link overhead, the win is relatively small on modern machines. That doesn't mean we shouldn't fix things that are obviously wrong, but it is odd that something like this wouldn't show up in direct builds — my numerous people and robots.
On Mon, Mar 09, 2026 at 07:46:15PM +0100, Borislav Petkov wrote: > On Mon, Mar 09, 2026 at 08:38:03PM +0200, Vladimir Oltean wrote: > > I'm not sure stale in which sense (I don't seem to have problems > > otherwise), but I don't really have time to split hairs on such an > > insignificant topic, sorry. The include path is wrong. > > This is not splitting hairs - we're trying to figure out how *you* have seen > it and we haven't so that we can make sure we're not missing an angle while > testing. > > I'll fix up your commit message to match what's happening. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette My best guess is that I'm building in a git worktree and you aren't. [/opt/linux/linux-phy] $ git worktree list /opt/linux caf08514bbee [test-vdso] <- doesn't fail /opt/linux/linux-phy 4e7a72a8696d [...] <- fails But don't ask me why it doesn't fail on the test-vdso branch in the main git tree with the exact same steps. I don't usually build-test x86, so I haven't been tracking the history and my experience is limited.
© 2016 - 2026 Red Hat, Inc.