linux-stable.git/arch, branch v6.6.71

x86/hyperv: Fix hv tsc page based sched_clock for hibernation

2025-01-10T13:31:36+00:00

commit bcc80dec91ee745b3d66f3e48f0ec2efdea97149 upstream.

read_hv_sched_clock_tsc() assumes that the Hyper-V clock counter is
bigger than the variable hv_sched_clock_offset, which is cached during
early boot, but depending on the timing this assumption may be false
when a hibernated VM starts again (the clock counter starts from 0
again) and is resuming back (Note: hv_init_tsc_clocksource() is not
called during hibernation/resume); consequently,
read_hv_sched_clock_tsc() may return a negative integer (which is
interpreted as a huge positive integer since the return type is u64)
and new kernel messages are prefixed with huge timestamps before
read_hv_sched_clock_tsc() grows big enough (which typically takes
several seconds).

Fix the issue by saving the Hyper-V clock counter just before the
suspend, and using it to correct the hv_sched_clock_offset in
resume. This makes hv tsc page based sched_clock continuous and ensures
that post resume, it starts from where it left off during suspend.
Override x86_platform.save_sched_clock_state and
x86_platform.restore_sched_clock_state routines to correct this as soon
as possible.

Note: if Invariant TSC is available, the issue doesn't happen because
1) we don't register read_hv_sched_clock_tsc() for sched clock:
See commit e5313f1c5404 ("clocksource/drivers/hyper-v: Rework
clocksource and sched clock setup");
2) the common x86 code adjusts TSC similarly: see
__restore_processor_state() ->  tsc_verify_tsc_adjust(true) and
x86_platform.restore_sched_clock_state().

Cc: stable@vger.kernel.org
Fixes: 1349401ff1aa ("clocksource/drivers/hyper-v: Suspend/resume Hyper-V clocksource for hibernation")
Co-developed-by: Dexuan Cui 
Signed-off-by: Dexuan Cui 
Signed-off-by: Naman Jain 
Reviewed-by: Michael Kelley 
Link: https://lore.kernel.org/r/20240917053917.76787-1-namjain@linux.microsoft.com
Signed-off-by: Wei Liu 
Message-ID: <20240917053917.76787-1-namjain@linux.microsoft.com>
Signed-off-by: Greg Kroah-Hartman

Revert "x86, crash: wrap crash dumping code into crash related ifdefs"

2025-01-10T13:31:36+00:00

This reverts commit e5b1574a8ca28c40cf53eda43f6c3b016ed41e27 which is
commit a4eeb2176d89fdf2785851521577b94b31690a60 upstream.

When this change is backported to the 6.6.y tree, it can cause build
errors on some configurations when KEXEC is not enabled, so revert it
for now.

Reported-by: Ignat Korchagin 
Link: https://lore.kernel.org/r/3DB3A6D3-0D3A-4682-B4FA-407B2D3263B2@cloudflare.com
Reported-by: Lars Wendler 
Link: https://lore.kernel.org/r/20250110103328.0e3906a8@chagall.paradoxon.rec
Reported-by: Chris Clayton 
Link: https://lore.kernel.org/r/10c7be00-b1f8-4389-801b-fb2d0b22468d@googlemail.com
Cc: Al Viro 
Cc: Andrew Morton 
Cc: Dexuan Cui 
Cc: Eric W. Biederman 
Cc: Hari Bathini 
Cc: Klara Modin 
Cc: Michael Kelley 
Cc: Michael Kelley 
Cc: Naman Jain 
Cc: Nathan Chancellor 
Cc: Pingfan Liu 
Cc: Sasha Levin 
Cc: Stephen Rothwell 
Cc: Wei Liu 
Cc: Yang Li 
Signed-off-by: Greg Kroah-Hartman

Revert "x86/hyperv: Fix hv tsc page based sched_clock for hibernation"

2025-01-10T13:31:36+00:00

This reverts commit 6681113633dc738ec95fe33104843a1e25acef3b which is
commit bcc80dec91ee745b3d66f3e48f0ec2efdea97149 upstream.

The dependant patch before this one caused build errors in the 6.6.y
tree, so revert this for now so that we can fix them up properly.

Reported-by: Ignat Korchagin 
Link: https://lore.kernel.org/r/3DB3A6D3-0D3A-4682-B4FA-407B2D3263B2@cloudflare.com
Reported-by: Lars Wendler 
Link: https://lore.kernel.org/r/20250110103328.0e3906a8@chagall.paradoxon.rec
Reported-by: Chris Clayton 
Link: https://lore.kernel.org/r/10c7be00-b1f8-4389-801b-fb2d0b22468d@googlemail.com
Cc: Dexuan Cui 
Cc: Naman Jain 
Cc: Michael Kelley 
Cc: Wei Liu 
Cc: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

ARC: build: Try to guess GCC variant of cross compiler

2025-01-09T12:32:05+00:00

[ Upstream commit 824927e88456331c7a999fdf5d9d27923b619590 ]

ARC GCC compiler is packaged starting from Fedora 39i and the GCC
variant of cross compile tools has arc-linux-gnu- prefix and not
arc-linux-. This is causing that CROSS_COMPILE variable is left unset.

This change allows builds without need to supply CROSS_COMPILE argument
if distro package is used.

Before this change:
$ make -j 128 ARCH=arc W=1 drivers/infiniband/hw/mlx4/
  gcc: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead
  gcc: error: unrecognized command-line option ‘-mmedium-calls’
  gcc: error: unrecognized command-line option ‘-mlock’
  gcc: error: unrecognized command-line option ‘-munaligned-access’

[1] https://packages.fedoraproject.org/pkgs/cross-gcc/gcc-arc-linux-gnu/index.html
Signed-off-by: Leon Romanovsky 
Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin

powerpc: Remove initialisation of readpos

2025-01-09T12:31:55+00:00

[ Upstream commit 0f7f544af60a6082cfaa3ed4c8f4ca1a858807ee ]

While powerpc doesn't use the seq_buf readpos, it did explicitly
initialise it for no good reason.

Link: https://lore.kernel.org/linux-trace-kernel/20231024145600.739451-1-willy@infradead.org

Cc: Christoph Hellwig 
Cc: Justin Stitt 
Cc: Kent Overstreet 
Cc: Petr Mladek 
Cc: Andy Shevchenko 
Cc: Rasmus Villemoes 
Cc: Sergey Senozhatsky 
Cc: Michael Ellerman 
Reviewed-by: Kees Cook 
Fixes: d0ed46b60396 ("tracing: Move readpos from seq_buf to trace_seq")
Signed-off-by: Matthew Wilcox (Oracle) 
Signed-off-by: Steven Rostedt (Google) 
Signed-off-by: Sasha Levin

x86/fred: Clear WFE in missing-ENDBRANCH #CPs

2025-01-09T12:31:52+00:00

[ Upstream commit dc81e556f2a017d681251ace21bf06c126d5a192 ]

An indirect branch instruction sets the CPU indirect branch tracker
(IBT) into WAIT_FOR_ENDBRANCH (WFE) state and WFE stays asserted
across the instruction boundary.  When the decoder finds an
inappropriate instruction while WFE is set ENDBR, the CPU raises a #CP
fault.

For the "kernel IBT no ENDBR" selftest where #CPs are deliberately
triggered, the WFE state of the interrupted context needs to be
cleared to let execution continue.  Otherwise when the CPU resumes
from the instruction that just caused the previous #CP, another
missing-ENDBRANCH #CP is raised and the CPU enters a dead loop.

This is not a problem with IDT because it doesn't preserve WFE and
IRET doesn't set WFE.  But FRED provides space on the entry stack
(in an expanded CS area) to save and restore the WFE state, thus the
WFE state is no longer clobbered, so software must clear it.

Clear WFE to avoid dead looping in ibt_clear_fred_wfe() and the
!ibt_fatal code path when execution is allowed to continue.

Clobbering WFE in any other circumstance is a security-relevant bug.

[ dhansen: changelog rewording ]

Fixes: a5f6c2ace997 ("x86/shstk: Add user control-protection fault handler")
Signed-off-by: Xin Li (Intel) 
Signed-off-by: Dave Hansen 
Signed-off-by: Ingo Molnar 
Acked-by: Dave Hansen 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/all/20241113175934.3897541-1-xin%40zytor.com
Signed-off-by: Sasha Levin

x86/ptrace: Add FRED additional information to the pt_regs structure

2025-01-09T12:31:52+00:00

[ Upstream commit 3c77bf02d0c03beb3efdf7a5b427fb2e1a76c265 ]

FRED defines additional information in the upper 48 bits of cs/ss
fields. Therefore add the information definitions into the pt_regs
structure.

Specifically introduce a new structure fred_ss to denote the FRED flags
above SS selector, which avoids FRED_SSX_ macros and makes the code
simpler and easier to read.

Suggested-by: Thomas Gleixner 
Originally-by: H. Peter Anvin (Intel) 
Signed-off-by: Xin Li 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Borislav Petkov (AMD) 
Tested-by: Shan Kang 
Link: https://lore.kernel.org/r/20231205105030.8698-15-xin3.li@intel.com
Stable-dep-of: dc81e556f2a0 ("x86/fred: Clear WFE in missing-ENDBRANCH #CPs")
Signed-off-by: Sasha Levin

x86/ptrace: Cleanup the definition of the pt_regs structure

2025-01-09T12:31:51+00:00

[ Upstream commit ee63291aa8287cb7ded767d340155fe8681fc075 ]

struct pt_regs is hard to read because the member or section related
comments are not aligned with the members.

The 'cs' and 'ss' members of pt_regs are type of 'unsigned long' while
in reality they are only 16-bit wide. This works so far as the
remaining space is unused, but FRED will use the remaining bits for
other purposes.

To prepare for FRED:

  - Cleanup the formatting
  - Convert 'cs' and 'ss' to u16 and embed them into an union
    with a u64
  - Fixup the related printk() format strings

Suggested-by: Thomas Gleixner 
Originally-by: H. Peter Anvin (Intel) 
Signed-off-by: Xin Li 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Borislav Petkov (AMD) 
Tested-by: Shan Kang 
Link: https://lore.kernel.org/r/20231205105030.8698-14-xin3.li@intel.com
Stable-dep-of: dc81e556f2a0 ("x86/fred: Clear WFE in missing-ENDBRANCH #CPs")
Signed-off-by: Sasha Levin

x86/hyperv: Fix hv tsc page based sched_clock for hibernation

2025-01-09T12:31:49+00:00

[ Upstream commit bcc80dec91ee745b3d66f3e48f0ec2efdea97149 ]

read_hv_sched_clock_tsc() assumes that the Hyper-V clock counter is
bigger than the variable hv_sched_clock_offset, which is cached during
early boot, but depending on the timing this assumption may be false
when a hibernated VM starts again (the clock counter starts from 0
again) and is resuming back (Note: hv_init_tsc_clocksource() is not
called during hibernation/resume); consequently,
read_hv_sched_clock_tsc() may return a negative integer (which is
interpreted as a huge positive integer since the return type is u64)
and new kernel messages are prefixed with huge timestamps before
read_hv_sched_clock_tsc() grows big enough (which typically takes
several seconds).

Fix the issue by saving the Hyper-V clock counter just before the
suspend, and using it to correct the hv_sched_clock_offset in
resume. This makes hv tsc page based sched_clock continuous and ensures
that post resume, it starts from where it left off during suspend.
Override x86_platform.save_sched_clock_state and
x86_platform.restore_sched_clock_state routines to correct this as soon
as possible.

Note: if Invariant TSC is available, the issue doesn't happen because
1) we don't register read_hv_sched_clock_tsc() for sched clock:
See commit e5313f1c5404 ("clocksource/drivers/hyper-v: Rework
clocksource and sched clock setup");
2) the common x86 code adjusts TSC similarly: see
__restore_processor_state() ->  tsc_verify_tsc_adjust(true) and
x86_platform.restore_sched_clock_state().

Cc: stable@vger.kernel.org
Fixes: 1349401ff1aa ("clocksource/drivers/hyper-v: Suspend/resume Hyper-V clocksource for hibernation")
Co-developed-by: Dexuan Cui 
Signed-off-by: Dexuan Cui 
Signed-off-by: Naman Jain 
Reviewed-by: Michael Kelley 
Link: https://lore.kernel.org/r/20240917053917.76787-1-namjain@linux.microsoft.com
Signed-off-by: Wei Liu 
Message-ID: <20240917053917.76787-1-namjain@linux.microsoft.com>
Signed-off-by: Sasha Levin

x86, crash: wrap crash dumping code into crash related ifdefs

2025-01-09T12:31:49+00:00

[ Upstream commit a4eeb2176d89fdf2785851521577b94b31690a60 ]

Now crash codes under kernel/ folder has been split out from kexec
code, crash dumping can be separated from kexec reboot in config
items on x86 with some adjustments.

Here, also change some ifdefs or IS_ENABLED() check to more appropriate
ones, e,g
 - #ifdef CONFIG_KEXEC_CORE -> #ifdef CONFIG_CRASH_DUMP
 - (!IS_ENABLED(CONFIG_KEXEC_CORE)) - > (!IS_ENABLED(CONFIG_CRASH_RESERVE))

[bhe@redhat.com: don't nest CONFIG_CRASH_DUMP ifdef inside CONFIG_KEXEC_CODE ifdef scope]
  Link: https://lore.kernel.org/all/SN6PR02MB4157931105FA68D72E3D3DB8D47B2@SN6PR02MB4157.namprd02.prod.outlook.com/T/#u
Link: https://lkml.kernel.org/r/20240124051254.67105-7-bhe@redhat.com
Signed-off-by: Baoquan He 
Cc: Al Viro 
Cc: Eric W. Biederman 
Cc: Hari Bathini 
Cc: Pingfan Liu 
Cc: Klara Modin 
Cc: Michael Kelley 
Cc: Nathan Chancellor 
Cc: Stephen Rothwell 
Cc: Yang Li 
Signed-off-by: Andrew Morton 
Stable-dep-of: bcc80dec91ee ("x86/hyperv: Fix hv tsc page based sched_clock for hibernation")
Signed-off-by: Sasha Levin