1. 05 10月, 2009 1 次提交
  2. 22 9月, 2009 1 次提交
  3. 21 9月, 2009 1 次提交
  4. 20 9月, 2009 1 次提交
  5. 10 9月, 2009 1 次提交
    • J
      xen: make -fstack-protector work under Xen · 577eebea
      Jeremy Fitzhardinge 提交于
      -fstack-protector uses a special per-cpu "stack canary" value.
      gcc generates special code in each function to test the canary to make
      sure that the function's stack hasn't been overrun.
      
      On x86-64, this is simply an offset of %gs, which is the usual per-cpu
      base segment register, so setting it up simply requires loading %gs's
      base as normal.
      
      On i386, the stack protector segment is %gs (rather than the usual kernel
      percpu %fs segment register).  This requires setting up the full kernel
      GDT and then loading %gs accordingly.  We also need to make sure %gs is
      initialized when bringing up secondary cpus too.
      
      To keep things consistent, we do the full GDT/segment register setup on
      both architectures.
      
      Because we need to avoid -fstack-protected code before setting up the GDT
      and because there's no way to disable it on a per-function basis, several
      files need to have stack-protector inhibited.
      
      [ Impact: allow Xen booting with stack-protector enabled ]
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      577eebea
  6. 01 7月, 2009 1 次提交
    • P
      xen: Use kcalloc() in xen_init_IRQ() · a70c352a
      Pekka Enberg 提交于
      The init_IRQ() function is now called with slab allocator initialized.
      Therefore, we must not use the bootmem allocator in xen_init_IRQ().
      
      Fixes the following boot-time warning:
      
        ------------[ cut here ]------------
        WARNING: at mm/bootmem.c:535 alloc_arch_preferred_bootmem+0x27/0x45()
        Modules linked in:
        Pid: 0, comm: swapper Not tainted 2.6.30 #1
        Call Trace:
         [<ffffffff8102d6e3>] ? warn_slowpath_common+0x73/0xb0
         [<ffffffff810210d9>] ? pvclock_clocksource_read+0x49/0x90
         [<ffffffff812e522f>] ? alloc_arch_preferred_bootmem+0x27/0x45
         [<ffffffff812e5761>] ? ___alloc_bootmem_nopanic+0x39/0xc9
         [<ffffffff812e57fa>] ? ___alloc_bootmem+0x9/0x2f
         [<ffffffff812e9e21>] ? xen_init_IRQ+0x25/0x61
         [<ffffffff812d69ee>] ? start_kernel+0x1b5/0x29e
        ---[ end trace 4eaa2a86a8e2da22 ]---
      Acked-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Tested-by: NChristian Kujau <lists@nerdbynature.de>
      Reported-by: NChristian Kujau <lists@nerdbynature.de>
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      Cc: lists@nerdbynature.de
      Cc: jeremy.fitzhardinge@citrix.com
      LKML-Reference: <1246438278.22417.28.camel@penberg-laptop>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a70c352a
  7. 24 6月, 2009 2 次提交
    • T
      percpu: clean up percpu variable definitions · 245b2e70
      Tejun Heo 提交于
      Percpu variable definition is about to be updated such that all percpu
      symbols including the static ones must be unique.  Update percpu
      variable definitions accordingly.
      
      * as,cfq: rename ioc_count uniquely
      
      * cpufreq: rename cpu_dbs_info uniquely
      
      * xen: move nesting_count out of xen_evtchn_do_upcall() and rename it
      
      * mm: move ratelimits out of balance_dirty_pages_ratelimited_nr() and
        rename it
      
      * ipv4,6: rename cookie_scratch uniquely
      
      * x86 perf_counter: rename prev_left to pmc_prev_left, irq_entry to
        pmc_irq_entry and nmi_entry to pmc_nmi_entry
      
      * perf_counter: rename disable_count to perf_disable_count
      
      * ftrace: rename test_event_disable to ftrace_test_event_disable
      
      * kmemleak: rename test_pointer to kmemleak_test_pointer
      
      * mce: rename next_interval to mce_next_interval
      
      [ Impact: percpu usage cleanups, no duplicate static percpu var names ]
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reviewed-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: linux-mm <linux-mm@kvack.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Steven Rostedt <srostedt@redhat.com>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      245b2e70
    • T
      percpu: cleanup percpu array definitions · 204fba4a
      Tejun Heo 提交于
      Currently, the following three different ways to define percpu arrays
      are in use.
      
      1. DEFINE_PER_CPU(elem_type[array_len], array_name);
      2. DEFINE_PER_CPU(elem_type, array_name[array_len]);
      3. DEFINE_PER_CPU(elem_type, array_name)[array_len];
      
      Unify to #1 which correctly separates the roles of the two parameters
      and thus allows more flexibility in the way percpu variables are
      defined.
      
      [ Impact: cleanup ]
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reviewed-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
      Cc: linux-mm@kvack.org
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: David S. Miller <davem@davemloft.net>
      204fba4a
  8. 13 6月, 2009 2 次提交
    • A
      PM core: rename suspend and resume functions · d1616302
      Alan Stern 提交于
      This patch (as1241) renames a bunch of functions in the PM core.
      Rather than go through a boring list of name changes, suffice it to
      say that in the end we have a bunch of pairs of functions:
      
      	device_resume_noirq	dpm_resume_noirq
      	device_resume		dpm_resume
      	device_complete		dpm_complete
      	device_suspend_noirq	dpm_suspend_noirq
      	device_suspend		dpm_suspend
      	device_prepare		dpm_prepare
      
      in which device_X does the X operation on a single device and dpm_X
      invokes device_X for all devices in the dpm_list.
      
      In addition, the old dpm_power_up and device_resume_noirq have been
      combined into a single function (dpm_resume_noirq).
      
      Lastly, dpm_suspend_start and dpm_resume_end are the renamed versions
      of the former top-level device_suspend and device_resume routines.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NMagnus Damm <damm@igel.co.jp>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      d1616302
    • M
      PM: Rename device_power_down/up() · e39a71ef
      Magnus Damm 提交于
      Rename the functions performing "_noirq" dev_pm_ops
      operations from device_power_down() and device_power_up()
      to device_suspend_noirq() and device_resume_noirq().
      
      The new function names are chosen to show that the functions
      are responsible for calling the _noirq() versions to finalize
      the suspend/resume operation. The current function names do
      not perform power down/up anymore so the names may be misleading.
      
      Global function renames:
      - device_power_down() -> device_suspend_noirq()
      - device_power_up() -> device_resume_noirq()
      
      Static function renames:
      - suspend_device_noirq() -> __device_suspend_noirq()
      - resume_device_noirq() -> __device_resume_noirq()
      Signed-off-by: NMagnus Damm <damm@igel.co.jp>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: NLen Brown <lenb@kernel.org>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      e39a71ef
  9. 06 5月, 2009 1 次提交
  10. 28 4月, 2009 2 次提交
    • Y
      x86/irq: change irq_desc_alloc() to take node instead of cpu · 85ac16d0
      Yinghai Lu 提交于
      This simplifies the node awareness of the code. All our allocators
      only deal with a NUMA node ID locality not with CPU ids anyway - so
      there's no need to maintain (and transform) a CPU id all across the
      IRq layer.
      
      v2: keep move_irq_desc related
      
      [ Impact: cleanup, prepare IRQ code to be NUMA-aware ]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      LKML-Reference: <49F65536.2020300@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      85ac16d0
    • Y
      irq: change ->set_affinity() to return status · d5dedd45
      Yinghai Lu 提交于
      according to Ingo, change set_affinity() in irq_chip should return int,
      because that way we can handle failure cases in a much cleaner way, in
      the genirq layer.
      
      v2: fix two typos
      
      [ Impact: extend API ]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: linux-arch@vger.kernel.org
      LKML-Reference: <49F654E9.4070809@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d5dedd45
  11. 09 4月, 2009 2 次提交
  12. 03 4月, 2009 1 次提交
    • I
      xen: honour VCPU availability on boot · 53152f95
      Ian Campbell 提交于
      If a VM is booted with offline VCPUs then unplug them during boot. Determining
      the availability of a VCPU requires access to XenStore which is not available
      at the point smp_prepare_cpus() is called, therefore we bring up all VCPUS
      initially and unplug the offline ones as soon as XenStore becomes available.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      53152f95
  13. 31 3月, 2009 12 次提交
  14. 30 3月, 2009 1 次提交
  15. 13 3月, 2009 1 次提交
  16. 23 2月, 2009 1 次提交
  17. 09 2月, 2009 6 次提交
  18. 29 1月, 2009 1 次提交
  19. 26 1月, 2009 1 次提交
  20. 24 1月, 2009 1 次提交
反馈
建议
客服 返回
顶部