[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC PATCH 1/1] x86/traps: Get rid of exception handlers' second argument error code
On Fri, Aug 04, 2023 at 05:35:11PM +0000, Li, Xin3 wrote: > > > The IDT event delivery of X86_TRAP_DF, X86_TRAP_TS, X86_TRAP_NP, > > > X86_TRAP_SS, X86_TRAP_GP, X86_TRAP_AC and X86_TRAP_CP pushes an error > > > code into the orig_ax member of the pt_regs structure, and the error > > > code is passed as the second argument of their C-handlers, although > > > the pt_regs structure is already passed as the first argument. > > > > > > The asm entry code of such faults does the following > > > > > > movq ORIG_RAX(%rsp), %rsi /* get error code into 2nd argument*/ > > > movq $-1, ORIG_RAX(%rsp) /* no syscall to restart */ > > > > > > to set the orig_ax member to -1 just before calling the C-handler. > > > > > > In addition, the IRQ entry code uses the second error code argument as > > > its IRQ vector, as the IRQ asm entry code pushes its IRQ vector into > > > the orig_ax member. > > > > > > The commit d99015b1abbad ("x86: move entry_64.S register saving out of > > > the macros") introduced the changes to set orig_ax to -1, but I can't > > > see why it's required. Our tests on x86_64 and x86_32 seem fine if > > > orig_ax is left unchanged instead of set to -1. > > > > That means that SYSCALL_NUM(regs) get to be garbage; or something like that. > > I find SYSCALL_NUM(regs) in tools/testing/selftests/seccomp/seccomp_bpf.c, > but nothing obvious to me. > > I think it's clear that once exceptions and IRQs are handled, the original > context will be fully recovered in a normal case. > > Is it related to preemption after such a event? > > I must have missed something; can you please elaborate it? arch/x86/include/asm/syscall.h syscall_get_nr() syscall_rollback()
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |