[GIT,PULL] x86/urgent for 6.1

  Hi Linus,

as it is usually the case, right after a major release, the tip urgent
branches accumulate a couple more fixes than normal. And here is the
x86, a bit bigger, urgent pile.

Please pull,
thx.

---

The following changes since commit 9abf2313adc1ca1b6180c508c25f22f9395cc780:

  Linux 6.1-rc1 (2022-10-16 15:36:24 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/x86_urgent_for_v6.0_rc2

for you to fetch changes up to 471f0aa7fa64e23766a1473b32d9ec3f0718895a:

  x86/fpu: Fix copy_xstate_to_uabi() to copy init states correctly (2022-10-21 15:22:09 -0700)

----------------------------------------------------------------
- Use the correct CPU capability clearing function on the error path in
  Intel perf LBR

- A CFI fix to ftrace along with a simplification

- Adjust handling of zero capacity bit mask for resctrl cache allocation
  on AMD

- A fix to the AMD microcode loader to attempt patch application on
  every logical thread

- A couple of topology fixes to handle CPUID leaf 0x1f enumeration info
  properly

- Drop a -mabi=ms compiler option check as both compilers support it now
  anyway

- A couple of fixes to how the initial, statically allocated FPU buffer
  state is setup and its interaction with dynamic states at runtime

----------------------------------------------------------------
Babu Moger (1):
      x86/resctrl: Fix min_cbm_bits for AMD

Borislav Petkov (1):
      x86/microcode/AMD: Apply the patch early on every logical thread

Chang S. Bae (4):
      x86/fpu: Configure init_fpstate attributes orderly
      x86/fpu: Fix the init_fpstate size check with the actual size
      x86/fpu: Exclude dynamic states from init_fpstate
      x86/fpu: Fix copy_xstate_to_uabi() to copy init states correctly

Maxim Levitsky (1):
      perf/x86/intel/lbr: Use setup_clear_cpu_cap() instead of clear_cpu_cap()

Nathan Chancellor (1):
      x86/Kconfig: Drop check for -mabi=ms for CONFIG_EFI_STUB

Peter Zijlstra (2):
      x86/ftrace: Remove ftrace_epilogue()
      ftrace,kcfi: Separate ftrace_stub() and ftrace_stub_graph()

Zhang Rui (3):
      hwmon/coretemp: Handle large core ID value
      x86/topology: Fix multiple packages shown on a single-package system
      x86/topology: Fix duplicated core ID within a package

 arch/arm64/kernel/entry-ftrace.S    |  7 ++++-
 arch/x86/Kconfig                    |  1 -
 arch/x86/events/intel/lbr.c         |  2 +-
 arch/x86/kernel/cpu/microcode/amd.c | 16 +++++++++--
 arch/x86/kernel/cpu/resctrl/core.c  |  8 ++----
 arch/x86/kernel/cpu/topology.c      | 16 +++++++----
 arch/x86/kernel/fpu/init.c          |  8 ------
 arch/x86/kernel/fpu/xstate.c        | 42 +++++++++++++++-------------
 arch/x86/kernel/ftrace_64.S         | 34 +++++++++-------------
 drivers/hwmon/coretemp.c            | 56 +++++++++++++++++++++++++++----------
 include/asm-generic/vmlinux.lds.h   | 18 ++++++++----
 11 files changed, 122 insertions(+), 86 deletions(-)
  

On Sun, Oct 23, 2022 at 11:36:41AM +0200, Borislav Petkov wrote:
> Hi Linus,
> 
> as it is usually the case, right after a major release, the tip urgent
> branches accumulate a couple more fixes than normal. And here is the
> x86, a bit bigger, urgent pile.
> 
> Please pull,
> thx.
> 
> ---
> 
> The following changes since commit 9abf2313adc1ca1b6180c508c25f22f9395cc780:
> 
>   Linux 6.1-rc1 (2022-10-16 15:36:24 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/x86_urgent_for_v6.0_rc2
									          ^^^^^

Whoops, I mistyped the version in the tag. Lemme know if you need a
properly renamed tag: x86_urgent_for_v6.1_rc2

Thx.
  

On Sun, Oct 23, 2022 at 2:54 AM Borislav Petkov <bp@suse.de> wrote:
>
> Whoops, I mistyped the version in the tag. Lemme know if you need a
> properly renamed tag: x86_urgent_for_v6.1_rc2

Heh, no, it doesn't matter. As long as the pull request is unambiguous
(which is only really an issue at the end of the release window when I
start getting a mix of last-minute fixes, and early pull requests for
the next merge window), it's all good.

Nobody will look at the tag name afterwards, so the tag-name being a
bit odd doesn't really matter. In fact I often edit out the free-form
commentary in the form of "This pull request for version Xyz does.."
from merge commit messages people send me, because it's not relevant
or interesting in the history.

But hey, I appreciate the heads-up about the name mix-up (although,
again, the only time it tends to actually matter is for that
end-or-release time frame where there can be actual confusion).

                       Linus
  

The pull request you sent on Sun, 23 Oct 2022 11:36:41 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/x86_urgent_for_v6.0_rc2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/295dad10bfb5bc35ef0d051aec61299ebeb88855

Thank you!
  

On Sun, Oct 23, 2022 at 10:06:37AM -0700, Linus Torvalds wrote:
> Nobody will look at the tag name afterwards, so the tag-name being a
> bit odd doesn't really matter. 

I was gonna say, let's have a fixed tag name so that there are no
multiple tags with the same name, per chance, which would confuse. But
it seems that when you pull a tag, it remains a remote tag and doesn't
appear in your tree. Which would be silly because if it did, your tree
would be full of all those tags you're pulling.

It sometimes is kinda annoying in my repo here after I've added a bunch
of repos and fetch from them and all those tags from there appear
locally too and I wonder what those even are.

> But hey, I appreciate the heads-up about the name mix-up

I had a hunch you would. :)

> (although, again, the only time it tends to actually matter is for
> that end-or-release time frame where there can be actual confusion).

Right.

Thx.
  

On Sun, Oct 23, 2022 at 11:14 AM Borislav Petkov <bp@suse.de> wrote:
>
> I was gonna say, let's have a fixed tag name so that there are no
> multiple tags with the same name, per chance, which would confuse.

Several trees do that already, and jst call the tags "for-linus" or similar.

> But it seems that when you pull a tag, it remains a remote tag and
> doesn't appear in your tree.

I obviously don't want to distribute these temporary tags as tags, no.
That's a git default behavior thing, because it would be very annoying
to get hundreds of irrelevant tags that get distributed with the
kernel.

But the tag name does show up in the commit message itself, so it now
does show up in the logs:

    Merge tag 'x86_urgent_for_v6.0_rc2' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

    Pull x86 fixes from Borislav Petkov:
     "As usually the case, right after a major release, the tip urgent
      branches accumulate a couple more fixes than normal. And here is the
      x86, a bit bigger, urgent pile.
    ...

and you can see it even more if you do

    git show --show-signature 295dad10bfb5

(or "git cat-file commit 295dad10bfb5) which will show some details
that are normally suppressed by a plain "git log".

And that's the part I mean when I said "Nobody will look at the tag
name afterwards". Yes, there are signs of that incorrect tag name in
there, but it's not like I suspect anybody would have ever even
noticed hadn't you brought it up.

                 Linus
  

On Sun, Oct 23, 2022 at 11:42:25AM -0700, Linus Torvalds wrote:
> Several trees do that already, and jst call the tags "for-linus" or similar.

Yap, exactly. And I have had a bunch of times a git warning in my tree
complaining about "master" being an ambiguous reference which was fun to
chase down the first time.

In tip we opted for either calling the tag "<branch-name>-<date>" -
which I still think is suboptimal because then you have to go and
match the date to the release which was current at the time.

Or use my vastly superior idea of <branch-name>_for_<kernel-version>
which tells you everything you wanna know. :-)

> I obviously don't want to distribute these temporary tags as tags, no.
> That's a git default behavior thing, because it would be very annoying
> to get hundreds of irrelevant tags that get distributed with the
> kernel.

Yap, exactly.

> And that's the part I mean when I said "Nobody will look at the tag
> name afterwards". Yes, there are signs of that incorrect tag name in
> there, but it's not like I suspect anybody would have ever even
> noticed hadn't you brought it up.

Yes, makes perfect sense to me. I had a hunch that it would be something
along the lines of: the tag doesn't really need to be a 1st class object
in the pulling repo and it is good enough if it is part of the pull
request text only.

So thanks for explaining.