Linus,
Please pull the latest x86/mm git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-mm-2024-01-08
# HEAD: 91c17d7b04498ffb52939a18eb7e28fd23c9b654 x86/percpu: Use %RIP-relative address in untagged_addr()
x86/mm changes for v6.8:
- Robustify pfn_to_kaddr()
- Improve the __untagged_addr() code: RIP-relative addresses are fine these days
and generate better code, and update misleading/outdated comments as well.
Thanks,
Ingo
------------------>
Michael Roth (1):
x86/mm: Ensure input to pfn_to_kaddr() is treated as a 64-bit type
Uros Bizjak (1):
x86/percpu: Use %RIP-relative address in untagged_addr()
arch/x86/include/asm/page.h | 6 +++++-
arch/x86/include/asm/uaccess_64.h | 11 ++++-------
2 files changed, 9 insertions(+), 8 deletions(-)
On Mon, 8 Jan 2024 at 03:35, Ingo Molnar <[email protected]> wrote:
>
> - Robustify pfn_to_kaddr()
>
> - Improve the __untagged_addr() code: RIP-relative addresses are fine these days
> and generate better code, and update misleading/outdated comments as well.
This does not even compile for me.
arch/x86/include/asm/uaccess_64.h: In function ‘__untagged_addr’:
arch/x86/include/asm/uaccess_64.h:25:28: error: implicit declaration
of function ‘__my_cpu_var’; did you mean ‘put_cpu_var’?
[-Werror=implicit-function-declaration]
WTH?
Maybe this has worked in your tree by mistake because there was some
branch dependency that just happened to work out because you had
merged things in a different order.
But that would very much not be ok regardless. Those branches should
be tested independently, and clearly they were not.
Linus
On Mon, 8 Jan 2024 at 18:06, Linus Torvalds
<[email protected]> wrote:
>
> This does not even compile for me.
>
> arch/x86/include/asm/uaccess_64.h: In function ‘__untagged_addr’:
> arch/x86/include/asm/uaccess_64.h:25:28: error: implicit declaration
> of function ‘__my_cpu_var’; did you mean ‘put_cpu_var’?
> [-Werror=implicit-function-declaration]
Side note: the whole __my_cpu_var() reminds me of the attached patch
that I have in my testing tree, and have been carrying along for a
number of months now.
I definitely think it's the right thing to do, so here it is again,
even if it is only tangentially related to the build failure wrt this
broken pull request.
Linus
* Linus Torvalds <[email protected]> wrote:
> On Mon, 8 Jan 2024 at 18:06, Linus Torvalds
> <[email protected]> wrote:
> >
> > This does not even compile for me.
> >
> > arch/x86/include/asm/uaccess_64.h: In function ‘__untagged_addr’:
> > arch/x86/include/asm/uaccess_64.h:25:28: error: implicit declaration
> > of function ‘__my_cpu_var’; did you mean ‘put_cpu_var’?
> > [-Werror=implicit-function-declaration]
>
> Side note: the whole __my_cpu_var() reminds me of the attached patch
> that I have in my testing tree, and have been carrying along for a
> number of months now.
>
> I definitely think it's the right thing to do, so here it is again,
Yeah, that's a good patch I have queued up in tip:x86/percpu:
24b8a23638cb ("x86/fpu: Clean up FPU switching in the middle of task switching")
Merged it shortly after you sent it:
commit 24b8a23638cbf92449c353f828b1d309548c78f4
Author: Linus Torvalds <[email protected]>
AuthorDate: Wed Oct 18 20:41:58 2023 +0200
Commit: Ingo Molnar <[email protected]>
CommitDate: Fri Oct 20 11:24:22 2023 +0200
I planned to send an RFC pull request for these bits in this merge window,
after all the other x86 trees.
Thanks,
Ingo
* Linus Torvalds <[email protected]> wrote:
> On Mon, 8 Jan 2024 at 03:35, Ingo Molnar <[email protected]> wrote:
> >
> > - Robustify pfn_to_kaddr()
> >
> > - Improve the __untagged_addr() code: RIP-relative addresses are fine these days
> > and generate better code, and update misleading/outdated comments as well.
>
> This does not even compile for me.
>
> arch/x86/include/asm/uaccess_64.h: In function ‘__untagged_addr’:
> arch/x86/include/asm/uaccess_64.h:25:28: error: implicit declaration
> of function ‘__my_cpu_var’; did you mean ‘put_cpu_var’?
> [-Werror=implicit-function-declaration]
>
> WTH?
>
> Maybe this has worked in your tree by mistake because there was some
> branch dependency that just happened to work out because you had
> merged things in a different order.
>
> But that would very much not be ok regardless. Those branches should
> be tested independently, and clearly they were not.
Sorry about that and agreed. Indeed the build failure was hidden by another
branch, and while I did test-build and test-boot the x86/mm branch before
sending it out, but my test config didn't have CONFIG_ADDRESS_MASKING=y ...
which ... masked the build failure. The bots that do per-tree testing
didn't catch this either.
I've now sorted it out in our trees, will send the new x86/mm in a few days.
Thanks,
Ingo