考虑传统INT $0x80系统调用机制和IA 32的现代快速系统调用机制在寄存器和堆栈使用方面的差异：
| 遗留系统调用|快速系统调用| Fast system call |
| --|--| ------------ |
| 系统调用号|系统调用号| system call number |
| arg1| arg1| arg1 |
| arg2| arg2| arg2 |
| arg3| arg3| arg3 |
| arg4| arg4| arg4 |
| arg5| arg5| arg5 |
| arg6|用户栈指针| user stack pointer |
| |arg6| arg6 |
对于快速系统调用机制，当entry_SYSENTER_32在内核堆栈上构造struct pt_regs条目时，sp成员将指向内核堆栈，bp成员将指向用户堆栈。因此，快速系统调用机制修复了sp和bp成员，以便与遗留系统调用机制兼容。在do_SYSENTER_32()中更正了sp成员值：

/* SYSENTER loses RSP, but the vDSO saved it in RBP. */
    regs->sp = regs->bp;

字符串
在__do_fast_syscall_32()中更正了bp成员值，将其设置为用户堆栈中的 * arg 6 * 值：

/* Fetch EBP from where the vDSO stashed it. */
    if (IS_ENABLED(CONFIG_X86_64)) {
        /*
         * Micro-optimization: the pointer we're following is
         * explicitly 32 bits, so it can't be out of range.
         */
        res = __get_user(*(u32 *)&regs->bp,
             (u32 __user __force *)(unsigned long)(u32)regs->sp);
    } else {
        res = get_user(*(u32 *)&regs->bp,
               (u32 __user __force *)(unsigned long)(u32)regs->sp);
    }

型
当从do_int80_syscall_32()（对于传统系统调用机制）或__do_fast_syscall_32()（对于快速系统调用机制）调用do_syscall_32_irqs_on()时，无论使用哪种系统调用机制，regs->bp和regs->sp值都将与预期相同。
另一个针对快速系统调用的修复发生在regs->ip上。EIP寄存器的原始值会被sysenter指令丢失，该指令通常从vDSO中的__kernel_vsyscall()函数执行。在do_fast_syscall_32()中更正了regs->ip：

/*
     * Called using the internal vDSO SYSENTER/SYSCALL32 calling
     * convention.  Adjust regs so it looks like we entered using int80.
     */
    unsigned long landing_pad = (unsigned long)current->mm->context.vdso +
                    vdso_image_32.sym_int80_landing_pad;

    /*
     * SYSENTER loses EIP, and even SYSCALL32 needs us to skip forward
     * so that 'regs->ip -= 2' lands back on an int $0x80 instruction.
     * Fix it up.
     */
    regs->ip = landing_pad;

型
vDSO包含紧接在sysenter指令之后的int $0x80指令。landing_pad值是紧接在int $0x80指令之后的地址，因此从快速系统调用返回时不会到达该指令。
在vDSO中使用int $0x80指令的原因是为了支持缺少sysenter和sysexit指令的旧版CPU。在这种情况下，vDSO中__kernel_vsyscall()中的mov %esp, %ebp; sysenter指令序列将被nop指令替换，CPU将到达紧接着该指令序列的int $0x80指令，有效地将快速系统调用更改为旧CPU的遗留系统调用。该遗留系统调用将返回到int $0x80指令之后的点，就像快速系统调用一样。

18天后，我又做了一次实验，注意到一个奇怪的现象。我用32位ubuntu系统编译了一个程序，简化后的程序是

#include<unistd.h>

int main(int argc, char* argv[]) {
    fork();
    return 0;
}

字符串
将编译好的a.out放入rootfs.img.gz并启动qemu

qemu-system-i386 -m 256m -kernel ./bzImage -initrd ./rootfs.img.gz -append "root=/dev/ram init=/linuxrc nokaslr" -serial file:output.txt -s -S

型
然后使用gdb，设置break copy_thread
我在qemu中的linux shell中输入命令./a.out。
因为copy_thread函数中有一个代码*childregs = *current_pt_regs()，所以我可以通过打印childregs来查看用户堆栈信息
当shell创建一个.out的进程时，Linux内核在copy_thread处停止。当我输入p/x *childregs时

(gdb) p/x *childregs
$10 = {bx = 0x1200011, cx = 0x0, dx = 0x0, si = 0x0, di = 0x9acb3e8, 
  bp = 0x8289000, ax = 0xffffffda, ds = 0x7b, __dsh = 0x0, es = 0x7b, 
  __esh = 0x0, fs = 0x0, __fsh = 0x0, gs = 0x33, __gsh = 0x0, orig_ax = 0x78, 
  ip = 0xb7f93549, cs = 0x73, __csh = 0x0, flags = 0x216, sp = 0xbfe797ec, 
  ss = 0x7b, __ssh = 0x0}

型
shell的堆栈信息是bp = 0x8289000,sp = 0xbfe797ec。bp的值很奇怪。
当.out运行fork（）时，Linux内核再次停止在copy_thread。在输入p/x *childregs时。

(gdb) p/x *childregs
$11 = {bx = 0x1200011, cx = 0x0, dx = 0x0, si = 0x0, di = 0xb7eeb128, 
  bp = 0xbfa23818, ax = 0xffffffda, ds = 0x7b, __dsh = 0x0, es = 0x7b, 
  __esh = 0x0, fs = 0x0, __fsh = 0x0, gs = 0x33, __gsh = 0x0, orig_ax = 0x78, 
  ip = 0xb7ef0549, cs = 0x73, __csh = 0x0, flags = 0x246, sp = 0xbfa237d0, 
  ss = 0x7b, __ssh = 0x0}

型
a.out堆栈信息是bp = 0xbfa23818，sp = 0xbfa237d0。bp值大于sp值，两者相差不大。这正是我所期望的
但是当shell创建一个.out进程时，bp是0x 8289000，我不知道当时到底发生了什么。