1. 11 Jul, 2008 7 commits
    • Ingo Molnar's avatar
      x86: fix savesegment() bug causing crashes on 64-bit · d9fc3fd3
      Ingo Molnar authored
      i spent a fair amount of time chasing a 64-bit bootup crash that manifested
      itself as bootup segfaults:
      
        S10network[1825]: segfault at 7f3e2b5d16b8 ip 00000031108748c9 sp 00007fffb9c14c70 error 4 in libc-2.7.so[3110800000+14d000]
      
      eventually causing init to die and panic the system:
      
        Kernel panic - not syncing: Attempted to kill init!
        Pid: 1, comm: init Not tainted 2.6.26-rc9-tip #13878
      
      after a maratonic bisection session, the bad commit turned out to be:
      
      | b7675791859075418199c7af86a116ea34eaf5bd is first bad commit
      | commit b7675791859075418199c7af86a116ea34eaf5bd
      | Author: Jeremy Fitzhardinge <jeremy@goop.org>
      | Date:   Wed Jun 25 00:19:00 2008 -0400
      |
      |     x86: remove open-coded save/load segment operations
      |
      |     This removes a pile of buggy open-coded implementations of savesegment
      |     and loadsegment.
      
      after some more bisection of this patch itself, it turns out that what
      makes the difference are the savesegment() changes to __switch_to().
      
      Taking a look at this portion of arch/x86/kernel/process_64.o revealed
      this crutial difference:
      
      | good:    99c:       8c e0                   mov    %fs,%eax
      |          99e:       89 45 cc                mov    %eax,-0x34(%rbp)
      |
      | bad:     99c:       8c 65 cc                mov    %fs,-0x34(%rbp)
      
      which is due to:
      
      |                 unsigned fsindex;
      | -               asm volatile("movl %%fs,%0" : "=r" (fsindex));
      | +               savesegment(fs, fsindex);
      
      savesegment() is implemented as:
      
       #define savesegment(seg, value)                                \
                asm("mov %%" #seg ",%0":"=rm" (value) : : "memory")
      
      note the "m" modifier - it allows GCC to generate the segment move
      into a memory operand as well.
      
      But regarding segment operands there's a subtle detail in the x86
      instruction set: the above 16-bit moves are zero-extend, but only
      if it goes to a register.
      
      If it goes to a memory operand, -0x34(%rbp) in the above case, there's
      no zero-extend to 32-bit and the instruction will only save 16 bits
      instead of the intended 32-bit.
      
      The other 16 bits is random data - which can cause problems when that
      value is used later on.
      
      The solution is to only allow segment operands to go to registers.
      This fix allows my test-system to boot up without crashing.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      d9fc3fd3
    • Jeremy Fitzhardinge's avatar
      x86_64: vdso32 cleanup using feature flags · b6ad92d4
      Jeremy Fitzhardinge authored
      Use the X86_FEATURE_SYSENTER32 to remove hard-coded CPU vendor check.
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b6ad92d4
    • Jeremy Fitzhardinge's avatar
      x86_64: add pseudo-features for 32-bit compat syscall · 8d28aab5
      Jeremy Fitzhardinge authored
      Add pseudo-feature bits to describe whether the CPU supports sysenter
      and/or syscall from ia32-compat userspace.  This removes a hardcoded
      test in vdso32-setup.
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      8d28aab5
    • Ingo Molnar's avatar
      x86: fix tsc unification buglet with ftrace and stackprotector · 3d0decc4
      Ingo Molnar authored
      Yinghai Lu reported crashes on 64-bit x86:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
       IP: [<ffffffff80253b17>] hrtick_start_fair+0x89/0x173
       [...]
      
      And with a long session of debugging and a lot of difficulty, tracked it down
      to this commit:
      
       --------------->
       8fbbc4b4 is first bad commit
       commit 8fbbc4b4
       Author: Alok Kataria <akataria@vmware.com>
       Date:   Tue Jul 1 11:43:34 2008 -0700
      
           x86: merge tsc_init and clocksource code
       <--------------
      
      The problem is that the TSC unification missed these Makefile rules
      in arch/x86/kernel/Makefile:
      
        # Do not profile debug and lowlevel utilities
        CFLAGS_REMOVE_tsc_64.o = -pg
        CFLAGS_REMOVE_tsc_32.o = -pg
        ...
        CFLAGS_tsc_64.o         := $(nostackp)
        ...
      
      which rules make sure that various instrumentation and debugging
      facilities are disabled for code that might end up in a VDSO - such as
      the TSC code.
      Reported-and-bisected-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      
      Conflicts:
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      3d0decc4
    • Yinghai Lu's avatar
      x86: introduce max_low_pfn_mapped for 64-bit · f361a450
      Yinghai Lu authored
      when more than 4g memory is installed, don't map the big hole below 4g.
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      f361a450
    • Yinghai Lu's avatar
      x86: reserve SLIT · f302a5bb
      Yinghai Lu authored
      save the SLIT, in case we are using fixmap to read it, and that fixmap
      could be cleared by others.
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      f302a5bb
    • Yinghai Lu's avatar
      x86: e820: user-defined memory maps: remove the range instead of update it to reserved · 69a7704d
      Yinghai Lu authored
      also let mem= to print out modified e820 map too
      Signed-off-by: default avatarYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Bernhard Walle <bwalle@suse.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      69a7704d
  2. 10 Jul, 2008 14 commits
  3. 09 Jul, 2008 19 commits