1. 28 6月, 2006 2 次提交
    • I
      [PATCH] vdso: randomize the i386 vDSO by moving it into a vma · e6e5494c
      Ingo Molnar 提交于
      Move the i386 VDSO down into a vma and thus randomize it.
      
      Besides the security implications, this feature also helps debuggers, which
      can COW a vma-backed VDSO just like a normal DSO and can thus do
      single-stepping and other debugging features.
      
      It's good for hypervisors (Xen, VMWare) too, which typically live in the same
      high-mapped address space as the VDSO, hence whenever the VDSO is used, they
      get lots of guest pagefaults and have to fix such guest accesses up - which
      slows things down instead of speeding things up (the primary purpose of the
      VDSO).
      
      There's a new CONFIG_COMPAT_VDSO (default=y) option, which provides support
      for older glibcs that still rely on a prelinked high-mapped VDSO.  Newer
      distributions (using glibc 2.3.3 or later) can turn this option off.  Turning
      it off is also recommended for security reasons: attackers cannot use the
      predictable high-mapped VDSO page as syscall trampoline anymore.
      
      There is a new vdso=[0|1] boot option as well, and a runtime
      /proc/sys/vm/vdso_enabled sysctl switch, that allows the VDSO to be turned
      on/off.
      
      (This version of the VDSO-randomization patch also has working ELF
      coredumping, the previous patch crashed in the coredumping code.)
      
      This code is a combined work of the exec-shield VDSO randomization
      code and Gerd Hoffmann's hypervisor-centric VDSO patch. Rusty Russell
      started this patch and i completed it.
      
      [akpm@osdl.org: cleanups]
      [akpm@osdl.org: compile fix]
      [akpm@osdl.org: compile fix 2]
      [akpm@osdl.org: compile fix 3]
      [akpm@osdl.org: revernt MAXMEM change]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NArjan van de Ven <arjan@infradead.org>
      Cc: Gerd Hoffmann <kraxel@suse.de>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Zachary Amsden <zach@vmware.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Jan Beulich <jbeulich@novell.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e6e5494c
    • J
      [PATCH] fix subarchitecture breakage with CONFIG_SCHED_SMT · 96c52749
      James Bottomley 提交于
      Commit 1e9f28fa ("[PATCH] sched: new
      sched domain for representing multi-core") incorrectly made SCHED_SMT
      and some of the structures it uses dependent on SMP.
      
      However, this is wrong, the structures are only defined if X86_HT, so
      SCHED_SMT has to depend on that as well.
      
      The patch broke voyager, since it doesn't provide any of the multi-core
      or hyperthreading structures.
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      96c52749
  2. 27 6月, 2006 5 次提交
  3. 23 6月, 2006 2 次提交
  4. 16 5月, 2006 1 次提交
  5. 28 4月, 2006 2 次提交
    • A
      [PATCH] Mark VMSPLIT EMBEDDED · 9539d4e7
      Andi Kleen 提交于
      Running abnormal VM splits causes weird problems - people can set non-standard
      splits by accident, then lots of time gets wasted diagnosing it - see the long
      "[stable] 2.6.16.6 breaks java...  sort of" email thread.
      
      So we need to make this option harder to set.  Use CONFIG_EMBEDDED for this.
      
      CONFIG_EMBEDDED isn't really the right thing to use, but there's nothing else
      obvious and avoiding these problems is more important than Kconfig purity.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Cc: Adrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9539d4e7
    • A
      [PATCH] enable X86_PC for HOTPLUG_CPU · 35076bdf
      Ashok Raj 提交于
      CPU_HOTPLUG has race conditions when we use broadcast mode IPI.
      
      - First we introduced no_broadcast option
          (see include/asm-i386/mach-default/mach_ipi.h)
      
      - x86_64 solved it by using physical flat mode (same as bigsmp on i386)
        since this will not use broadcast shortcuts for IPI.
      
      - We switched to use bigsmp on i386 so that we can have same handling as
        x86_64, but apparently this caused an error message, if kernel was
        compiled without X86_GENERICARCH, X86_BIGSMP.  The message "You have >8
        CPUS..." which was bogus and misleading, and only indicated one of the
        above ARCH wasnt selected.
      
      So we do not switch to automatic bigsmp for HOTPLUG_CPU support in i386
      until the other related config dependencies for SMP_SUSPEND etc can be done
      right.
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      35076bdf
  6. 11 4月, 2006 3 次提交
  7. 28 3月, 2006 1 次提交
    • S
      [PATCH] sched: new sched domain for representing multi-core · 1e9f28fa
      Siddha, Suresh B 提交于
      Add a new sched domain for representing multi-core with shared caches
      between cores.  Consider a dual package system, each package containing two
      cores and with last level cache shared between cores with in a package.  If
      there are two runnable processes, with this appended patch those two
      processes will be scheduled on different packages.
      
      On such systems, with this patch we have observed 8% perf improvement with
      specJBB(2 warehouse) benchmark and 35% improvement with CFP2000 rate(with 2
      users).
      
      This new domain will come into play only on multi-core systems with shared
      caches.  On other systems, this sched domain will be removed by domain
      degeneration code.  This new domain can be also used for implementing power
      savings policy (see OLS 2005 CMP kernel scheduler paper for more details..
      I will post another patch for power savings policy soon)
      
      Most of the arch/* file changes are for cpu_coregroup_map() implementation.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1e9f28fa
  8. 27 3月, 2006 1 次提交
  9. 26 3月, 2006 1 次提交
    • A
      [PATCH] x86: make CONFIG_HOTPLUG_CPU depend on !X86_PC · d3f4aaa3
      Ashok Raj 提交于
      Make CONFIG_HOTPLUG_CPU depend on !X86_PC, so we need to turn on either
      CONFIG_GENERICARCH, CONFIG_BIGSMP or any other subarch except X86_PC when
      CONFIG_HOTPLUG_CPU=y
      
      With 2.6.15+ kernels when CONFIG_HOTPLUG_CPU is turned on we switch to
      bigsmp mode for sending IPI's and ioapic configurations that caused the
      following error message.
      
      >> More than 8 CPUs detected and CONFIG_X86_PC cannot handle it.
      >> Use CONFIG_X86_GENERICARCH or CONFIG_X86_BIGSMP.
      
      Originally bigsmp was added just to handle >8 cpus, but now with hotplug
      cpu support we need to use bigsmp mode (why?  see below), that cause the
      above error message even if there were less than 8 cpus in the system.
      
      The message is bogus, but we are cannot use logical flat mode due to issues
      with broadcast IPI can confuse a CPU just comming up.  We use flat physical
      mode just like x86_64 case.  More details on why bigsmp now uses flat
      physical mode (vs.  cluster mode) in following link.
      
      http://marc.theaimsgroup.com/?l=linux-kernel&m=113261865814107&w=2Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d3f4aaa3
  10. 23 3月, 2006 3 次提交
  11. 27 2月, 2006 2 次提交
  12. 06 2月, 2006 1 次提交
  13. 02 2月, 2006 2 次提交
    • M
      [PATCH] VMSPLIT config options · 975b3d3d
      Mark Lord 提交于
      Enable selection of different user/kernel VM splits for i386, including an
      optimized mode for 1GB physical RAM, which gives the kernel a direct (non
      HIGHMEM) mapping to the entire 1GB rather than just the first 896MB.
      
      There is a similarly a similarly optimized mode for machines with exactly 2GB
      of physical RAM.
      
      This can speed up the kernel by avoiding having to create/destroy temporary
      HIGHMEM mappings, and by not having to include HIGHMEM support at all on such
      machines.  The flip side is that there's less virtual addressing left for
      userspace in these alternatives, and some binary-only kernel modules may
      misbehave unless rebuilt with the same VMSPLIT option as the main kernel
      image.
      
      Original idea/patch from Jens Axboe, modified based on suggestions from Linus
      et al.
      Signed-off-by: NMark Lord <mlord@pobox.com>
      Signed-off-by: NJens Axboe <axboe@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      975b3d3d
    • I
      [PATCH] CONFIG_DOUBLEFAULT Kconfig fix · 389d1ea5
      Ingo Molnar 提交于
      Move CONFIG_DOUBLEFAULT from the main Kconfig menu (!) into its proper
      place: the "Processor Type and features" submenu.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      389d1ea5
  14. 15 1月, 2006 1 次提交
  15. 12 1月, 2006 2 次提交
  16. 11 1月, 2006 2 次提交
  17. 09 1月, 2006 3 次提交
  18. 07 1月, 2006 1 次提交
  19. 14 11月, 2005 1 次提交
  20. 07 11月, 2005 1 次提交
  21. 01 11月, 2005 1 次提交
  22. 31 10月, 2005 2 次提交