[GIT PULL] x86/entry for 7.0-rc1

[GIT PULL] x86/entry for 7.0-rc1

[Dave Hansen]

Hi Linus,

Please pull some x86/entry changes for 7.0-rc1. This is entirely
composed of a set of long overdue VDSO cleanups. They makes the VDSO
build much more logical and zap quite a bit of old cruft. It also
results in a coveted net-code-removal diffstat.

There have been a few bumps along the way with this series, thus the
bug fixes on top. But nothing too scary.

--

The following changes since commit 0f61b1860cc3f52aef9036d7235ed1f017632193:

  Linux 6.19-rc5 (2026-01-11 17:03:14 -1000)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/x86_entry_for_7.0-rc1

for you to fetch changes up to ce9b1c10c3f1c723c3cc7b63aa8331fdb6c57a04:

  x86/entry/vdso: Add vdso2c to .gitignore (2026-01-27 23:27:51 +0100)

----------------------------------------------------------------
 * VDSO rework and cleanups

----------------------------------------------------------------
Borislav Petkov (AMD) (1):
      x86/entry/vdso: Add vdso2c to .gitignore

H. Peter Anvin (13):
      x86/entry/vdso: Rename vdso_image_* to vdso*_image
      x86/entry/vdso: Move vdso2c to arch/x86/tools
      x86/entry/vdso: Refactor the vdso build
      x86/entry/vdso32: Don't rely on int80_landing_pad for adjusting ip
      x86/entry/vdso32: Remove SYSCALL_ENTER_KERNEL macro in sigreturn.S
      x86/entry/vdso32: Remove open-coded DWARF in sigreturn.S
      x86/entry/vdso: Include GNU_PROPERTY and GNU_STACK PHDRs
      x86/vdso: Abstract out vdso system call internals
      x86/cpufeature: Replace X86_FEATURE_SYSENTER32 with X86_FEATURE_SYSFAST32
      x86/entry/vdso32: When using int $0x80, use it directly
      x86/entry/vdso: Update the object paths for "make vdso_install"
      x86/entry/vdso: Fix filtering of vdso compiler flags
      x86/entry/vdso/selftest: Update location of vgetrandom-chacha.S

Lukas Bulwahn (1):
      MAINTAINERS: Adjust vdso file entry in INTEL SGX

Nathan Chancellor (1):
      x86/entry/vdso32: Omit '.cfi_offset eflags' for LLVM < 16

 MAINTAINERS                                        |   2 +-
 arch/x86/Kconfig.cpufeatures                       |   8 +
 arch/x86/Makefile                                  |   8 +-
 arch/x86/entry/syscall_32.c                        |   2 +-
 arch/x86/entry/vdso/.gitignore                     |  11 +-
 arch/x86/entry/vdso/Makefile                       | 162 +--------------------
 arch/x86/entry/vdso/common/Makefile.include        |  89 +++++++++++
 arch/x86/entry/vdso/{vdso-note.S => common/note.S} |   5 +-
 arch/x86/entry/vdso/{ => common}/vclock_gettime.c  |   0
 arch/x86/entry/vdso/{ => common}/vdso-layout.lds.S |  38 +++--
 arch/x86/entry/vdso/{ => common}/vgetcpu.c         |   0
 arch/x86/entry/vdso/vdso32/Makefile                |  24 +++
 arch/x86/entry/vdso/vdso32/note.S                  |  19 +--
 arch/x86/entry/vdso/vdso32/sigreturn.S             | 160 ++++++--------------
 arch/x86/entry/vdso/vdso32/system_call.S           |  22 ++-
 arch/x86/entry/vdso/vdso32/vclock_gettime.c        |   5 +-
 arch/x86/entry/vdso/vdso32/vdso32.lds.S            |   2 +-
 arch/x86/entry/vdso/vdso32/vgetcpu.c               |   4 +-
 arch/x86/entry/vdso/vdso64/Makefile                |  46 ++++++
 arch/x86/entry/vdso/vdso64/note.S                  |   1 +
 arch/x86/entry/vdso/vdso64/vclock_gettime.c        |   1 +
 .../entry/vdso/{vdso.lds.S => vdso64/vdso64.lds.S} |   2 +-
 arch/x86/entry/vdso/{ => vdso64}/vdsox32.lds.S     |   2 +-
 arch/x86/entry/vdso/vdso64/vgetcpu.c               |   1 +
 .../entry/vdso/{ => vdso64}/vgetrandom-chacha.S    |   0
 arch/x86/entry/vdso/{ => vdso64}/vgetrandom.c      |   2 +-
 arch/x86/entry/vdso/{ => vdso64}/vsgx.S            |   0
 arch/x86/entry/vdso/vma.c                          |  24 ++-
 arch/x86/include/asm/cpufeatures.h                 |   2 +-
 arch/x86/include/asm/dwarf2.h                      |   1 +
 arch/x86/include/asm/elf.h                         |   2 +-
 arch/x86/include/asm/vdso.h                        |   6 +-
 arch/x86/include/asm/vdso/gettimeofday.h           | 108 +-------------
 arch/x86/include/asm/vdso/sys_call.h               | 105 +++++++++++++
 arch/x86/kernel/asm-offsets.c                      |   6 +
 arch/x86/kernel/cpu/centaur.c                      |   3 -
 arch/x86/kernel/cpu/common.c                       |   8 +
 arch/x86/kernel/cpu/intel.c                        |   4 +-
 arch/x86/kernel/cpu/zhaoxin.c                      |   4 +-
 arch/x86/kernel/fred.c                             |   2 +-
 arch/x86/kernel/process_64.c                       |   6 +-
 arch/x86/kernel/signal_32.c                        |   4 +-
 arch/x86/tools/.gitignore                          |   1 +
 arch/x86/tools/Makefile                            |  15 +-
 arch/x86/{entry/vdso => tools}/vdso2c.c            |   0
 arch/x86/{entry/vdso => tools}/vdso2c.h            |   0
 arch/x86/xen/setup.c                               |  28 ++--
 arch/x86/xen/smp_pv.c                              |   5 +-
 arch/x86/xen/xen-ops.h                             |   1 -
 tools/testing/selftests/vDSO/vgetrandom-chacha.S   |   2 +-
 50 files changed, 459 insertions(+), 494 deletions(-)
 create mode 100644 arch/x86/entry/vdso/common/Makefile.include
 rename arch/x86/entry/vdso/{vdso-note.S => common/note.S} (62%)
 rename arch/x86/entry/vdso/{ => common}/vclock_gettime.c (100%)
 rename arch/x86/entry/vdso/{ => common}/vdso-layout.lds.S (77%)
 rename arch/x86/entry/vdso/{ => common}/vgetcpu.c (100%)
 create mode 100644 arch/x86/entry/vdso/vdso32/Makefile
 create mode 100644 arch/x86/entry/vdso/vdso64/Makefile
 create mode 100644 arch/x86/entry/vdso/vdso64/note.S
 create mode 100644 arch/x86/entry/vdso/vdso64/vclock_gettime.c
 rename arch/x86/entry/vdso/{vdso.lds.S => vdso64/vdso64.lds.S} (94%)
 rename arch/x86/entry/vdso/{ => vdso64}/vdsox32.lds.S (92%)
 create mode 100644 arch/x86/entry/vdso/vdso64/vgetcpu.c
 rename arch/x86/entry/vdso/{ => vdso64}/vgetrandom-chacha.S (100%)
 rename arch/x86/entry/vdso/{ => vdso64}/vgetrandom.c (91%)
 rename arch/x86/entry/vdso/{ => vdso64}/vsgx.S (100%)
 create mode 100644 arch/x86/include/asm/vdso/sys_call.h
 rename arch/x86/{entry/vdso => tools}/vdso2c.c (100%)
 rename arch/x86/{entry/vdso => tools}/vdso2c.h (100%)

Re: [GIT PULL] x86/entry for 7.0-rc1

[pr-tracker-bot]

The pull request you sent on Mon,  9 Feb 2026 13:09:24 -0800:

> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/x86_entry_for_7.0-rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6f7e6393d1ce636bb7ec77a7fe7b77458fddf701

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] x86/entry for 7.0-rc1

[Linus Torvalds]

On Mon, 9 Feb 2026 at 13:09, Dave Hansen <dave.hansen@linux.intel.com> wrote:
>
> Please pull some x86/entry changes for 7.0-rc1. This is entirely
> composed of a set of long overdue VDSO cleanups.

Argh, I didn't notice this problem until after pushing things out, but
that pull also removes the old filenames from the .gitignore file.

That may feel like the right thing to do, but it's not. It means that
anybody with a build tree that was active before they updated will
suddenly now see those old stale generated filenames in 'git status'
output etc.

Most of the time that's only a visual oddity that may confuse people.

But it can cause - and has caused - actual real problems when people
then do exactly the wrong thing as a result (ie they mindlessly commit
the files because they didn't look very closely at what they did and
they had other work of their own that they *did* mean to commit).

So .gitignore files should only add new names, not remove old names.

Sure, _eventually_ the stale entries can be removed, but not in some
kind of immediate short timeframe.

The old stale files don't go away until you do an explicit "git clean"
(I don't think even a "make clean" will remove those, I didn't check).

I added the files back to the .gitignore file. I'm sure I have missed
similar things in the past just because they happen to only be
generated in configurations that I happen to test, but I thought I'd
point this out so that people are more aware of this whole issue.

Maybe some people keep their build trees religiously clean or entirely
separate from their source trees. But I certainly don't, and I know
many other developers don't.

            Linus

Re: [GIT PULL] x86/entry for 7.0-rc1

[Linus Torvalds]

On Tue, 10 Feb 2026 at 20:24, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So .gitignore files should only add new names, not remove old names.
>
> Sure, _eventually_ the stale entries can be removed, but not in some
> kind of immediate short timeframe.

Side note: it might be worth thinking about naming generated files
very explicitly.

Out generated headers go into a subdirectory of their own, which
solves the problem for them. But that's inconvenient when you want to
have just a random one-off thing.

Maybe it would be good to just make those files *very* explicit, and
name them something very clearly different. Like always using the
filename pattern 'xyz.generated.[ch]' or something like that.

Then we could just add the '*.generated.[ch]' pattern to the top-level
.gitignore and not have to worry about at least those files.

This is not a huge issue, and most releases don't have this at all.

But it just so happens that not having seen this for a good long
while, the current merge window has now had two very different "people
don't ignore generated files properly".

Don't people use 'git status' (or look at the status that gets printed
out by a number of other git commands)?

I suspect one issue is that people who *know* they moved the file may
think "oh, I moved that file, I'll just remove that left-over turd
too". So the people who move files aren't confused and don't think
it's a big deal.

But they don't realize that for other people - the people who *didn't*
move the file and have no idea what that file is - are much more
likely to be confused and go "Why did that file suddenly show up".

Because those other people may not even realize that it's a generated
file because they were never really aware of it before.

              Linus

Re: [GIT PULL] x86/entry for 7.0-rc1

[H. Peter Anvin]

On February 10, 2026 8:39:52 PM PST, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Tue, 10 Feb 2026 at 20:24, Linus Torvalds
><torvalds@linux-foundation.org> wrote:
>>
>> So .gitignore files should only add new names, not remove old names.
>>
>> Sure, _eventually_ the stale entries can be removed, but not in some
>> kind of immediate short timeframe.
>
>Side note: it might be worth thinking about naming generated files
>very explicitly.
>
>Out generated headers go into a subdirectory of their own, which
>solves the problem for them. But that's inconvenient when you want to
>have just a random one-off thing.
>
>Maybe it would be good to just make those files *very* explicit, and
>name them something very clearly different. Like always using the
>filename pattern 'xyz.generated.[ch]' or something like that.
>
>Then we could just add the '*.generated.[ch]' pattern to the top-level
>.gitignore and not have to worry about at least those files.
>
>This is not a huge issue, and most releases don't have this at all.
>
>But it just so happens that not having seen this for a good long
>while, the current merge window has now had two very different "people
>don't ignore generated files properly".
>
>Don't people use 'git status' (or look at the status that gets printed
>out by a number of other git commands)?
>
>I suspect one issue is that people who *know* they moved the file may
>think "oh, I moved that file, I'll just remove that left-over turd
>too". So the people who move files aren't confused and don't think
>it's a big deal.
>
>But they don't realize that for other people - the people who *didn't*
>move the file and have no idea what that file is - are much more
>likely to be confused and go "Why did that file suddenly show up".
>
>Because those other people may not even realize that it's a generated
>file because they were never really aware of it before.
>
>              Linus

Arguably the best thing would be to stop building in the source directory at all...

Re: [GIT PULL] x86/entry for 7.0-rc1

[Linus Torvalds]

On Tue, 10 Feb 2026 at 22:15, H. Peter Anvin <hpa@zytor.com> wrote:
>
> Arguably the best thing would be to stop building in the source directory at all...

I feel like every time people make that argument, it's because they do
something seriously wrong to begin with.

For example, back in the CVS days, that was common as a way to build
multiple different configurations from the same source tree. So
keeping a separate build directory was the answer.

No. The real answer was that CVS was crap, and made it hard to just
have multiple trees. And you do want multiple source trees, because
you may want to then edit the sources when one of those configurations
breaks or might show interesting issues that only show up in one
configuration.

And I think that's still true for generated files etc.

There are zero real advantages to separate build trees - they are only
used to hide problems that should be fixed elsewhere.

I don't want to go look elsewhere and have some separate directory
structure just because it's a build file.

             Linus

Re: [GIT PULL] x86/entry for 7.0-rc1

[H. Peter Anvin]

On February 10, 2026 10:34:54 PM PST, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Tue, 10 Feb 2026 at 22:15, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> Arguably the best thing would be to stop building in the source directory at all...
>
>I feel like every time people make that argument, it's because they do
>something seriously wrong to begin with.
>
>For example, back in the CVS days, that was common as a way to build
>multiple different configurations from the same source tree. So
>keeping a separate build directory was the answer.
>
>No. The real answer was that CVS was crap, and made it hard to just
>have multiple trees. And you do want multiple source trees, because
>you may want to then edit the sources when one of those configurations
>breaks or might show interesting issues that only show up in one
>configuration.
>
>And I think that's still true for generated files etc.
>
>There are zero real advantages to separate build trees - they are only
>used to hide problems that should be fixed elsewhere.
>
>I don't want to go look elsewhere and have some separate directory
>structure just because it's a build file.
>
>             Linus

I don't know if it is "wrong", but I have a build setup with canned configurations that build into separate directories, while keeping the sources the same so I can try to see if one tweak changes anything in any of those configurations.

The second thing is that it makes it *very* easy to separate source from generated...

Re: [GIT PULL] x86/entry for 7.0-rc1

[Linus Torvalds]

On Wed, 11 Feb 2026 at 08:30, H. Peter Anvin <hpa@zytor.com> wrote:
>
> I don't know if it is "wrong", but I have a build setup with canned
> configurations that build into separate directories, while keeping the
> sources the same so I can try to see if one tweak changes anything in
> any of those configurations.
>
> The second thing is that it makes it *very* easy to separate source
> from generated...

So I personally find the build trees convenient for automation or for
just building other peoples projects, but annoying for when I do
actual development.

It's easy for automation because there you care more about the build
tree than the source tree, and the build has an unambiguous "this is
where the sources are", and it's all scripted anyway.

So if you do automation - like building N different targets for
various different configurations - you love build trees, because it's
very natural, and it makes what you care about - the build - the
central part.

Same goes for "I build somebody else's project" where there may not be
different configurations, but the thing you care about is the end
result, not the source tree.

So then doing the standard (for cmake) dance of

   mkdir build && cd build && cmake ..

is pretty simple. It's just a special case of the "automation" case
where having just one special build location avoids the "where to put
the build" question.

But as a developer, I used to just detest them.

Going somewhere else to test-build something is just a supremely
annoying extra step to me. Yes, you can use multiple terminals, or an
IDE - or aliases or other abstractions - that deals with the whole
"build here, work there" thing.

But I have always felt that if I care primarily about a source tree,
I'd much rather just have the build right there, and not have to care
about the distinction.

I often actually look at the build results. Not the object files, no.
But I do things like

   make xyz/file.s

*ALL* the time when developing, and I just don't want to have to treat
the "this was what I just generated" and "this was what I generated it
from" as something very different.

Admittedly, these days I don't do much actual development, so I guess
I wouldn't care.

Which reminds me that I need to go back to merging...

              Linus

Re: [GIT PULL] x86/entry for 7.0-rc1

[H. Peter Anvin]

On 2026-02-11 09:05, Linus Torvalds wrote:
> 
> I often actually look at the build results. Not the object files, no.
> But I do things like
> 
>    make xyz/file.s
> 
> *ALL* the time when developing, and I just don't want to have to treat
> the "this was what I just generated" and "this was what I generated it
> from" as something very different.
> 
> Admittedly, these days I don't do much actual development, so I guess
> I wouldn't care.
> 
> Which reminds me that I need to go back to merging...
> 

Oh, I do too. And so I do make in the build directory, or tack on the O=
option. FAR more annoying to me is that kbuild requires you to do the make
command in the root directory of the tree.

"make -C ../../../../.. arch/x86/entry/vdso/vdso32/sigreturn.o" is not really
much better than

"make -C ../../../../.. O=o/x86_64.cf arch/x86/entry/vdso/vdso32/sigreturn.o"

Come to think of it, I really should just wrap that up in a script...

If anyone is interested, my scripts are sitting at:

	git://git.zytor.com/linux/ktest.git

	-hpa

Re: [GIT PULL] x86/entry for 7.0-rc1

[Linus Torvalds]

On Wed, 11 Feb 2026 at 09:40, H. Peter Anvin <hpa@zytor.com> wrote:
>
> Oh, I do too. And so I do make in the build directory, or tack on the O=
> option. FAR more annoying to me is that kbuild requires you to do the make
> command in the root directory of the tree.

It would indeed be lovely if "make" in subdirectories would find their
way back home.

> "make -C ../../../../.. arch/x86/entry/vdso/vdso32/sigreturn.o" is not really
> much better than

Yeah, I live in the top directory most of the time, so I go the other
way and just do

   make arch/x86/entry/vdso/vdso32/sigreturn.o

or whatever path I'm interested in (sometimes just a whole subdirectory).

And then I depend on good autocomplete of filenames, so I never
actually type out that full path.

              Linus

Re: [GIT PULL] x86/entry for 7.0-rc1

[H. Peter Anvin]

On 2026-02-11 09:52, Linus Torvalds wrote:
> On Wed, 11 Feb 2026 at 09:40, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> Oh, I do too. And so I do make in the build directory, or tack on the O=
>> option. FAR more annoying to me is that kbuild requires you to do the make
>> command in the root directory of the tree.
> 
> It would indeed be lovely if "make" in subdirectories would find their
> way back home.
> 
>> "make -C ../../../../.. arch/x86/entry/vdso/vdso32/sigreturn.o" is not really
>> much better than
> 
> Yeah, I live in the top directory most of the time, so I go the other
> way and just do
> 
>    make arch/x86/entry/vdso/vdso32/sigreturn.o
> 
> or whatever path I'm interested in (sometimes just a whole subdirectory).
> 
> And then I depend on good autocomplete of filenames, so I never
> actually type out that full path.
> 
I just wrote up a script called kmake and added it to my scripts repository:

	https://git.zytor.com/linux/ktest/tree/bin/kmake

	-hpa

Re: [GIT PULL] x86/entry for 7.0-rc1

[Andy Shevchenko]

On Tue, Feb 10, 2026 at 08:24:49PM -0800, Linus Torvalds wrote:
> On Mon, 9 Feb 2026 at 13:09, Dave Hansen <dave.hansen@linux.intel.com> wrote:

...

> Maybe some people keep their build trees religiously clean or entirely
> separate from their source trees. But I certainly don't, and I know
> many other developers don't.

There may be actual benefits of having source and output not to be mixed.
For example, it can be that one has a source on an read-only volume or
by a network filesystem. It's possible to say that cloning a Git repository
locally is the solution, but for some cases it might be too much.

And yes, I happily use `git worktree`. The difference with worktree and
output folder, that the output may be located on tmpfs or be removed w/o
much thinking of unfinished jobs or so.

-- 
With Best Regards,
Andy Shevchenko

Re: [GIT PULL] x86/entry for 7.0-rc1

[Linus Torvalds]

On Wed, 11 Feb 2026 at 10:16, Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> There may be actual benefits of having source and output not to be mixed.

I'm perfectly happy for you to do that, and I agree that it has advantages.

But I'm *not* willing to have your say that everybody else has to do
that, and you forcing me to work in those ways.

So the "mixed source and build tree" had better work and not cause problems.

                Linus