1. 15 5月, 2012 2 次提交
  2. 09 5月, 2012 1 次提交
    • T
      percpu, x86: don't use PMD_SIZE as embedded atom_size on 32bit · d5e28005
      Tejun Heo 提交于
      With the embed percpu first chunk allocator, x86 uses either PAGE_SIZE
      or PMD_SIZE for atom_size.  PMD_SIZE is used when CPU supports PSE so
      that percpu areas are aligned to PMD mappings and possibly allow using
      PMD mappings in vmalloc areas in the future.  Using larger atom_size
      doesn't waste actual memory; however, it does require larger vmalloc
      space allocation later on for !first chunks.
      
      With reasonably sized vmalloc area, PMD_SIZE shouldn't be a problem
      but x86_32 at this point is anything but reasonable in terms of
      address space and using larger atom_size reportedly leads to frequent
      percpu allocation failures on certain setups.
      
      As there is no reason to not use PMD_SIZE on x86_64 as vmalloc space
      is aplenty and most x86_64 configurations support PSE, fix the issue
      by always using PMD_SIZE on x86_64 and PAGE_SIZE on x86_32.
      
      v2: drop cpu_has_pse test and make x86_64 always use PMD_SIZE and
          x86_32 PAGE_SIZE as suggested by hpa.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NYanmin Zhang <yanmin.zhang@intel.com>
      Reported-by: NShuoX Liu <shuox.liu@intel.com>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      LKML-Reference: <4F97BA98.6010001@intel.com>
      Cc: stable@vger.kernel.org
      d5e28005
  3. 08 5月, 2012 2 次提交
  4. 07 5月, 2012 5 次提交
  5. 06 5月, 2012 2 次提交
  6. 05 5月, 2012 1 次提交
  7. 04 5月, 2012 1 次提交
    • L
      vfs: make word-at-a-time accesses handle a non-existing page · e419b4cc
      Linus Torvalds 提交于
      It turns out that there are more cases than CONFIG_DEBUG_PAGEALLOC that
      can have holes in the kernel address space: it seems to happen easily
      with Xen, and it looks like the AMD gart64 code will also punch holes
      dynamically.
      
      Actually hitting that case is still very unlikely, so just do the
      access, and take an exception and fix it up for the very unlikely case
      of it being a page-crosser with no next page.
      
      And hey, this abstraction might even help other architectures that have
      other issues with unaligned word accesses than the possible missing next
      page.  IOW, this could do the byte order magic too.
      
      Peter Anvin fixed a thinko in the shifting for the exception case.
      Reported-and-tested-by: NJana Saout <jana@saout.de>
      Cc:  Peter Anvin <hpa@zytor.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e419b4cc
  8. 01 5月, 2012 1 次提交
  9. 28 4月, 2012 1 次提交
  10. 27 4月, 2012 3 次提交
    • A
      x86/amd: Re-enable CPU topology extensions in case BIOS has disabled it · f7f286a9
      Andreas Herrmann 提交于
      BIOS will switch off the corresponding feature flag on family
      15h models 10h-1fh non-desktop CPUs.
      
      The topology extension CPUID leafs are required to detect which
      cores belong to the same compute unit. (thread siblings mask is
      set accordingly and also correct information about L1i and L2
      cache sharing depends on this).
      
      W/o this patch we wouldn't see which cores belong to the same
      compute unit and also cache sharing information for L1i and L2
      would be incorrect on such systems.
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      f7f286a9
    • K
      xen/smp: Fix crash when booting with ACPI hotplug CPUs. · cf405ae6
      Konrad Rzeszutek Wilk 提交于
      When we boot on a machine that can hotplug CPUs and we
      are using 'dom0_max_vcpus=X' on the Xen hypervisor line
      to clip the amount of CPUs available to the initial domain,
      we get this:
      
      (XEN) Command line: com1=115200,8n1 dom0_mem=8G noreboot dom0_max_vcpus=8 sync_console mce_verbosity=verbose console=com1,vga loglvl=all guest_loglvl=all
      .. snip..
      DMI: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x032.072520111118 07/25/2011
      .. snip.
      SMP: Allowing 64 CPUs, 32 hotplug CPUs
      installing Xen timer for CPU 7
      cpu 7 spinlock event irq 361
      NMI watchdog: disabled (cpu7): hardware events not enabled
      Brought up 8 CPUs
      .. snip..
      	[acpi processor finds the CPUs are not initialized and starts calling
      	arch_register_cpu, which creates /sys/devices/system/cpu/cpu8/online]
      CPU 8 got hotplugged
      CPU 9 got hotplugged
      CPU 10 got hotplugged
      .. snip..
      initcall 1_acpi_battery_init_async+0x0/0x1b returned 0 after 406 usecs
      calling  erst_init+0x0/0x2bb @ 1
      
      	[and the scheduler sticks newly started tasks on the new CPUs, but
      	said CPUs cannot be initialized b/c the hypervisor has limited the
      	amount of vCPUS to 8 - as per the dom0_max_vcpus=8 flag.
      	The spinlock tries to kick the other CPU, but the structure for that
      	is not initialized and we crash.]
      BUG: unable to handle kernel paging request at fffffffffffffed8
      IP: [<ffffffff81035289>] xen_spin_lock+0x29/0x60
      PGD 180d067 PUD 180e067 PMD 0
      Oops: 0002 [#1] SMP
      CPU 7
      Modules linked in:
      
      Pid: 1, comm: swapper/0 Not tainted 3.4.0-rc2upstream-00001-gf5154e8 #1 Intel Corporation S2600CP/S2600CP
      RIP: e030:[<ffffffff81035289>]  [<ffffffff81035289>] xen_spin_lock+0x29/0x60
      RSP: e02b:ffff8801fb9b3a70  EFLAGS: 00010282
      
      With this patch, we cap the amount of vCPUS that the initial domain
      can run, to exactly what dom0_max_vcpus=X has specified.
      
      In the future, if there is a hypercall that will allow a running
      domain to expand past its initial set of vCPUS, this patch should
      be re-evaluated.
      
      CC: stable@kernel.org
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      cf405ae6
    • K
      xen/enlighten: Disable MWAIT_LEAF so that acpi-pad won't be loaded. · df88b2d9
      Konrad Rzeszutek Wilk 提交于
      There are exactly four users of __monitor and __mwait:
      
       - cstate.c (which allows acpi_processor_ffh_cstate_enter to be called
         when the cpuidle API drivers are used. However patch
         "cpuidle: replace xen access to x86 pm_idle and default_idle"
         provides a mechanism to disable the cpuidle and use safe_halt.
       - smpboot (which allows mwait_play_dead to be called). However
         safe_halt is always used so we skip that.
       - intel_idle (same deal as above).
       - acpi_pad.c. This the one that we do not want to run as we
         will hit the below crash.
      
      Why do we want to expose MWAIT_LEAF in the first place?
      We want it for the xen-acpi-processor driver - which uploads
      C-states to the hypervisor. If MWAIT_LEAF is set, the cstate.c
      sets the proper address in the C-states so that the hypervisor
      can benefit from using the MWAIT functionality. And that is
      the sole reason for using it.
      
      Without this patch, if a module performs mwait or monitor we
      get this:
      
      invalid opcode: 0000 [#1] SMP
      CPU 2
      .. snip..
      Pid: 5036, comm: insmod Tainted: G           O 3.4.0-rc2upstream-dirty #2 Intel Corporation S2600CP/S2600CP
      RIP: e030:[<ffffffffa000a017>]  [<ffffffffa000a017>] mwait_check_init+0x17/0x1000 [mwait_check]
      RSP: e02b:ffff8801c298bf18  EFLAGS: 00010282
      RAX: ffff8801c298a010 RBX: ffffffffa03b2000 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: ffff8801c29800d8 RDI: ffff8801ff097200
      RBP: ffff8801c298bf18 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
      R13: ffffffffa000a000 R14: 0000005148db7294 R15: 0000000000000003
      FS:  00007fbb364f2700(0000) GS:ffff8801ff08c000(0000) knlGS:0000000000000000
      CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 000000000179f038 CR3: 00000001c9469000 CR4: 0000000000002660
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process insmod (pid: 5036, threadinfo ffff8801c298a000, task ffff8801c29cd7e0)
      Stack:
       ffff8801c298bf48 ffffffff81002124 ffffffffa03b2000 00000000000081fd
       000000000178f010 000000000178f030 ffff8801c298bf78 ffffffff810c41e6
       00007fff3fb30db9 00007fff3fb30db9 00000000000081fd 0000000000010000
      Call Trace:
       [<ffffffff81002124>] do_one_initcall+0x124/0x170
       [<ffffffff810c41e6>] sys_init_module+0xc6/0x220
       [<ffffffff815b15b9>] system_call_fastpath+0x16/0x1b
      Code: <0f> 01 c8 31 c0 0f 01 c9 c9 c3 00 00 00 00 00 00 00 00 00 00 00 00
      RIP  [<ffffffffa000a017>] mwait_check_init+0x17/0x1000 [mwait_check]
       RSP <ffff8801c298bf18>
      ---[ end trace 16582fc8a3d1e29a ]---
      Kernel panic - not syncing: Fatal exception
      
      With this module (which is what acpi_pad.c would hit):
      
      MODULE_AUTHOR("Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>");
      MODULE_DESCRIPTION("mwait_check_and_back");
      MODULE_LICENSE("GPL");
      MODULE_VERSION();
      
      static int __init mwait_check_init(void)
      {
      	__monitor((void *)&current_thread_info()->flags, 0, 0);
      	__mwait(0, 0);
      	return 0;
      }
      static void __exit mwait_check_exit(void)
      {
      }
      module_init(mwait_check_init);
      module_exit(mwait_check_exit);
      Reported-by: NLiu, Jinsong <jinsong.liu@intel.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      df88b2d9
  11. 25 4月, 2012 2 次提交
  12. 24 4月, 2012 4 次提交
  13. 21 4月, 2012 4 次提交
  14. 20 4月, 2012 2 次提交
  15. 19 4月, 2012 2 次提交
  16. 18 4月, 2012 1 次提交
  17. 17 4月, 2012 3 次提交
  18. 16 4月, 2012 3 次提交