linux-toradex.git/arch/x86/kernel/process.c, branch v6.16

x86/process: Move the buffer clearing before MONITOR

2025-06-17T15:17:12+00:00

Move the VERW clearing before the MONITOR so that VERW doesn't disarm it
and the machine never enters C1.

Original idea by Kim Phillips .

Suggested-by: Andrew Cooper 
Signed-off-by: Borislav Petkov (AMD)

x86/iopl: Cure TIF_IO_BITMAP inconsistencies

2025-06-03T13:56:39+00:00

io_bitmap_exit() is invoked from exit_thread() when a task exists or
when a fork fails. In the latter case the exit_thread() cleans up
resources which were allocated during fork().

io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up
in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the
current task. If current has TIF_IO_BITMAP set, but no bitmap installed,
tss_update_io_bitmap() crashes with a NULL pointer dereference.

There are two issues, which lead to that problem:

  1) io_bitmap_exit() should not invoke task_update_io_bitmap() when
     the task, which is cleaned up, is not the current task. That's a
     clear indicator for a cleanup after a failed fork().

  2) A task should not have TIF_IO_BITMAP set and neither a bitmap
     installed nor IOPL emulation level 3 activated.

     This happens when a kernel thread is created in the context of
     a user space thread, which has TIF_IO_BITMAP set as the thread
     flags are copied and the IO bitmap pointer is cleared.

     Other than in the failed fork() case this has no impact because
     kernel threads including IO workers never return to user space and
     therefore never invoke tss_update_io_bitmap().

Cure this by adding the missing cleanups and checks:

  1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if
     the to be cleaned up task is not the current task.

  2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user
     space forks it is set later, when the IO bitmap is inherited in
     io_bitmap_share().

For paranoia sake, add a warning into tss_update_io_bitmap() to catch
the case, when that code is invoked with inconsistent state.

Fixes: ea5f1cd7ab49 ("x86/ioperm: Remove bitmap if all permissions dropped")
Reported-by: syzbot+e2b1803445d236442e54@syzkaller.appspotmail.com
Signed-off-by: Thomas Gleixner 
Signed-off-by: Borislav Petkov (AMD) 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/87wmdceom2.ffs@tglx

x86/cpuid: Set as the main CPUID header

2025-05-15T16:23:55+00:00

The main CPUID header  was originally a storefront for the
headers:

    
    

Now that the latter CPUID(0x2) header has been merged into the former,
there is no practical difference between  and
.

Migrate all users to the  header, in preparation of
the removal of .

Don't remove  just yet, in case some new code in -next
started using it.

Suggested-by: Ingo Molnar 
Signed-off-by: Ahmed S. Darwish 
Signed-off-by: Ingo Molnar 
Cc: Andrew Cooper 
Cc: H. Peter Anvin 
Cc: John Ogness 
Cc: x86-cpuid@lists.linux.dev
Link: https://lore.kernel.org/r/20250508150240.172915-3-darwi@linutronix.de

Merge branch 'x86/msr' into x86/core, to resolve conflicts

2025-05-13T08:42:06+00:00

 Conflicts:
	arch/x86/boot/startup/sme.c
	arch/x86/coco/sev/core.c
	arch/x86/kernel/fpu/core.c
	arch/x86/kernel/fpu/xstate.c

 Semantic conflict:
	arch/x86/include/asm/sev-internal.h

Signed-off-by: Ingo Molnar

Merge branch 'x86/mm' into x86/core, to resolve conflicts

2025-05-13T08:39:22+00:00

 Conflicts:
	arch/x86/mm/numa.c
	arch/x86/mm/pgtable.c

Signed-off-by: Ingo Molnar

x86/fpu: Always use memcpy_and_pad() in arch_dup_task_struct()

2025-05-04T08:29:25+00:00

It makes no sense to copy the bytes after sizeof(struct task_struct),
FPU state will be initialized in fpu_clone().

A plain memcpy(dst, src, sizeof(struct task_struct)) should work too,
but "_and_pad" looks safer.

[ mingo: Simplify it a bit more. ]

Signed-off-by: Oleg Nesterov 
Signed-off-by: Ingo Molnar 
Cc: Andy Lutomirski 
Cc: Brian Gerst 
Cc: Chang S . Bae 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Link: https://lore.kernel.org/r/20250503143850.GA8997@redhat.com

x86/msr: Add explicit includes of

2025-05-02T08:23:47+00:00

For historic reasons there are some TSC-related functions in the
 header, even though there's an  header.

To facilitate the relocation of rdtsc{,_ordered}() from 
to  and to eventually eliminate the inclusion of
 in , add an explicit  dependency
to the source files that reference definitions from .

[ mingo: Clarified the changelog. ]

Signed-off-by: Xin Li (Intel) 
Signed-off-by: Ingo Molnar 
Acked-by: Dave Hansen 
Acked-by: Peter Zijlstra (Intel) 
Acked-by: Ilpo Järvinen 
Cc: Andy Lutomirski 
Cc: Brian Gerst 
Cc: Juergen Gross 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Kees Cook 
Cc: Peter Zijlstra 
Cc: Borislav Petkov 
Cc: Thomas Gleixner 
Cc: Josh Poimboeuf 
Cc: Uros Bizjak 
Link: https://lore.kernel.org/r/20250501054241.1245648-1-xin@zytor.com

x86/fpu: Make sure x86_task_fpu() doesn't get called for PF_KTHREAD|PF_USER_WORKER tasks during exit

2025-04-14T06:18:29+00:00

fpu__drop() and arch_release_task_struct() calls x86_task_fpu()
unconditionally, while the FPU context area will not be present
if it's the init task, and should not be in use when it's some
other type of kthread.

Return early for PF_KTHREAD or PF_USER_WORKER tasks. The debug
warning in x86_task_fpu() will catch any kthreads attempting to
use the FPU save area.

Fixed-by: Chang S. Bae 
Signed-off-by: Ingo Molnar 
Cc: Andy Lutomirski 
Cc: Brian Gerst 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Link: https://lore.kernel.org/r/20250409211127.3544993-7-mingo@kernel.org

x86/fpu: Push 'fpu' pointer calculation into the fpu__drop() call

2025-04-14T06:18:29+00:00

This encapsulates the fpu__drop() functionality better, and it
will also enable other changes that want to check a task for
PF_KTHREAD before calling x86_task_fpu().

Signed-off-by: Ingo Molnar 
Cc: Andy Lutomirski 
Cc: Brian Gerst 
Cc: Chang S. Bae 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Link: https://lore.kernel.org/r/20250409211127.3544993-6-mingo@kernel.org

x86/fpu: Remove the thread::fpu pointer

2025-04-14T06:18:29+00:00

As suggested by Oleg, remove the thread::fpu pointer, as we can
calculate it via x86_task_fpu() at compile-time.

This improves code generation a bit:

   kepler:~/tip> size vmlinux.before vmlinux.after
   text        data        bss        dec         hex        filename
   26475405    10435342    1740804    38651551    24dc69f    vmlinux.before
   26475339    10959630    1216516    38651485    24dc65d    vmlinux.after

Suggested-by: Oleg Nesterov 
Signed-off-by: Ingo Molnar 
Cc: Andy Lutomirski 
Cc: Brian Gerst 
Cc: Chang S. Bae 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Uros Bizjak 
Link: https://lore.kernel.org/r/20250409211127.3544993-5-mingo@kernel.org