1. 19 2月, 2014 1 次提交
  2. 08 1月, 2014 1 次提交
  3. 20 12月, 2013 1 次提交
  4. 10 12月, 2013 1 次提交
  5. 31 10月, 2013 1 次提交
    • L
      ACPICA: Cleanup asmlinkage for ACPICA APIs. · 40bce100
      Lv Zheng 提交于
      Add an asmlinkage wrapper around acpi_enter_sleep_state() to prevent
      an empty stub from being called by assmebly code for ACPI_REDUCED_HARDWARE
      set.
      
      As arch/x86/kernel/acpi/wakeup_xx.S is only compiled when CONFIG_ACPI=y
      and there are no users of ACPI_HARDWARE_REDUCED, currently this is in
      fact not a real issue, but a cleanup to reduce source code differences
      between Linux and ACPICA upstream.
      
      [rjw: Changelog]
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      40bce100
  6. 01 10月, 2013 1 次提交
  7. 24 9月, 2013 2 次提交
  8. 26 8月, 2013 1 次提交
  9. 27 7月, 2013 1 次提交
  10. 23 7月, 2013 1 次提交
  11. 16 7月, 2013 1 次提交
  12. 15 7月, 2013 1 次提交
    • P
      x86: delete __cpuinit usage from all x86 files · 148f9bb8
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      are flagged as __cpuinit  -- so if we remove the __cpuinit from
      arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      content into no-ops as early as possible, since that will get rid
      of these warnings.  In any case, they are temporary and harmless.
      
      This removes all the arch/x86 uses of the __cpuinit macros from
      all C files.  x86 only had the one __CPUINIT used in assembly files,
      and it wasn't paired off with a .previous or a __FINIT, so we can
      delete it directly w/o any corresponding additional change there.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NH. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      148f9bb8
  13. 09 7月, 2013 1 次提交
  14. 20 6月, 2013 1 次提交
  15. 12 4月, 2013 2 次提交
    • K
      x86, xen, gdt: Remove the pvops variant of store_gdt. · 357d1226
      Konrad Rzeszutek Wilk 提交于
      The two use-cases where we needed to store the GDT were during ACPI S3 suspend
      and resume. As the patches:
       x86/gdt/i386: store/load GDT for ACPI S3 or hibernation/resume path is not needed
       x86/gdt/64-bit: store/load GDT for ACPI S3 or hibernate/resume path is not needed.
      
      have demonstrated - there are other mechanism by which the GDT is
      saved and reloaded during early resume path.
      
      Hence we do not need to worry about the pvops call-chain for saving the
      GDT and can and can eliminate it. The other areas where the store_gdt is
      used are never going to be hit when running under the pvops platforms.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Link: http://lkml.kernel.org/r/1365194544-14648-4-git-send-email-konrad.wilk@oracle.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      357d1226
    • K
      x86-32, gdt: Store/load GDT for ACPI S3 or hibernation/resume path is not needed · 84e70971
      Konrad Rzeszutek Wilk 提交于
      During the ACPI S3 suspend, we store the GDT in the wakup_header (see
      wakeup_asm.s) field called 'pmode_gdt'.
      
      Which is then used during the resume path and has the same exact
      value as what the store/load_gdt do with the saved_context
      (which is saved/restored via save/restore_processor_state()).
      
      The flow during resume from ACPI S3 is simpler than the 64-bit
      counterpart. We only use the early bootstrap once (wakeup_gdt) and
      do various checks in real mode.
      
      After the checks are completed, we load the saved GDT ('pmode_gdt') and
      continue on with the resume (by heading to startup_32 in trampoline_32.S) -
      which quickly jumps to what was saved in 'pmode_entry'
      aka 'wakeup_pmode_return'.
      
      The 'wakeup_pmode_return' restores the GDT (saved_gdt) again (which was
      saved in do_suspend_lowlevel initially). After that it ends up calling
      the 'ret_point' which calls 'restore_processor_state()'.
      
      We have two opportunities to remove code where we restore the same GDT
      twice.
      
      Here is the call chain:
       wakeup_start
             |- lgdtl wakeup_gdt [the work-around broken BIOSes]
             |
             | - lgdtl pmode_gdt [the real one]
             |
             \-- startup_32 (in trampoline_32.S)
                    \-- wakeup_pmode_return (in wakeup_32.S)
                             |- lgdtl saved_gdt [the real one]
                             \-- ret_point
                                   |..
                                   |- call restore_processor_state
      
      The hibernate path is much simpler. During the saving of the hibernation
      image we call save_processor_state() and save the contents of that
      along with the rest of the kernel in the hibernation image destination.
      We save the EIP of 'restore_registers' (restore_jump_address) and
      cr3 (restore_cr3).
      
      During hibernate resume, the 'restore_registers' (via the
      'restore_jump_address) in hibernate_asm_32.S is invoked which
      restores the contents of most registers. Naturally the resume path benefits
      from already being in 32-bit mode, so it does not have to reload the GDT.
      
      It only reloads the cr3 (from restore_cr3) and continues on. Note
      that the restoration of the restore image page-tables is done prior to
      this.
      
      After the 'restore_registers' it returns and we end up called
      restore_processor_state() - where we reload the GDT. The reload of
      the GDT is not needed as bootup kernel has already loaded the GDT
      which is at the same physical location as the the restored kernel.
      
      Note that the hibernation path assumes the GDT is correct during its
      'restore_registers'. The assumption in the code is that the restored
      image is the same as saved - meaning we are not trying to restore
      an different kernel in the virtual address space of a new kernel.
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Link: http://lkml.kernel.org/r/1365194544-14648-3-git-send-email-konrad.wilk@oracle.com
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      84e70971
  16. 11 3月, 2013 1 次提交
  17. 24 2月, 2013 1 次提交
    • W
      cpu_hotplug: clear apicid to node when the cpu is hotremoved · c4c60524
      Wen Congyang 提交于
      When a cpu is hotpluged, we call acpi_map_cpu2node() in
      _acpi_map_lsapic() to store the cpu's node and apicid's node.  But we
      don't clear the cpu's node in acpi_unmap_lsapic() when this cpu is
      hotremoved.  If the node is also hotremoved, we will get the following
      messages:
      
        kernel BUG at include/linux/gfp.h:329!
        invalid opcode: 0000 [#1] SMP
        Modules linked in: ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle bridge stp llc sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel microcode pcspkr i2c_i801 i2c_core lpc_ich mfd_core ioatdma e1000e i7core_edac edac_core sg acpi_memhotplug igb dca sd_mod crc_t10dif megaraid_sas mptsas mptscsih mptbase scsi_transport_sas scsi_mod
        Pid: 3126, comm: init Not tainted 3.6.0-rc3-tangchen-hostbridge+ #13 FUJITSU-SV PRIMEQUEST 1800E/SB
        RIP: 0010:[<ffffffff811bc3fd>]  [<ffffffff811bc3fd>] allocate_slab+0x28d/0x300
        RSP: 0018:ffff88078a049cf8  EFLAGS: 00010246
        RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
        RDX: 0000000000000001 RSI: 0000000000000001 RDI: 0000000000000246
        RBP: ffff88078a049d38 R08: 00000000000040d0 R09: 0000000000000001
        R10: 0000000000000000 R11: 0000000000000b5f R12: 00000000000052d0
        R13: ffff8807c1417300 R14: 0000000000030038 R15: 0000000000000003
        FS:  00007fa9b1b44700(0000) GS:ffff8807c3800000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
        CR2: 00007fa9b09acca0 CR3: 000000078b855000 CR4: 00000000000007e0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
        Process init (pid: 3126, threadinfo ffff88078a048000, task ffff8807bb6f2650)
        Call Trace:
          new_slab+0x30/0x1b0
          __slab_alloc+0x358/0x4c0
          kmem_cache_alloc_node_trace+0xb4/0x1e0
          alloc_fair_sched_group+0xd0/0x1b0
          sched_create_group+0x3e/0x110
          sched_autogroup_create_attach+0x4d/0x180
          sys_setsid+0xd4/0xf0
          system_call_fastpath+0x16/0x1b
        Code: 89 c4 e9 73 fe ff ff 31 c0 89 de 48 c7 c7 45 de 9e 81 44 89 45 c8 e8 22 05 4b 00 85 db 44 8b 45 c8 0f 89 4f ff ff ff 0f 0b eb fe <0f> 0b 90 eb fd 0f 0b eb fe 89 de 48 c7 c7 45 de 9e 81 31 c0 44
        RIP  [<ffffffff811bc3fd>] allocate_slab+0x28d/0x300
         RSP <ffff88078a049cf8>
        ---[ end trace adf84c90f3fea3e5 ]---
      
      The reason is that the cpu's node is not NUMA_NO_NODE, we will call
      alloc_pages_exact_node() to alloc memory on the node, but the node is
      offlined.
      
      If the node is onlined, we still need cpu's node.  For example: a task
      on the cpu is sleeped when the cpu is hotremoved.  We will choose
      another cpu to run this task when it is waked up.  If we know the cpu's
      node, we will choose the cpu on the same node first.  So we should clear
      cpu-to-node mapping when the node is offlined.
      
      This patch only clears apicid-to-node mapping when the cpu is
      hotremoved.
      
      [akpm@linux-foundation.org: fix section error]
      Signed-off-by: NWen Congyang <wency@cn.fujitsu.com>
      Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Jiang Liu <liuj97@gmail.com>
      Cc: Minchan Kim <minchan.kim@gmail.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c4c60524
  18. 18 11月, 2012 1 次提交
  19. 17 11月, 2012 1 次提交
  20. 15 11月, 2012 2 次提交
  21. 01 10月, 2012 1 次提交
  22. 27 9月, 2012 1 次提交
  23. 26 9月, 2012 1 次提交
  24. 31 7月, 2012 1 次提交
  25. 12 6月, 2012 3 次提交
  26. 18 5月, 2012 1 次提交
    • P
      MCA: delete all remaining traces of microchannel bus support. · bb8187d3
      Paul Gortmaker 提交于
      Hardware with MCA bus is limited to 386 and 486 class machines
      that are now 20+ years old and typically with less than 32MB
      of memory.  A quick search on the internet, and you see that
      even the MCA hobbyist/enthusiast community has lost interest
      in the early 2000 era and never really even moved ahead from
      the 2.4 kernels to the 2.6 series.
      
      This deletes anything remaining related to CONFIG_MCA from core
      kernel code and from the x86 architecture.  There is no point in
      carrying this any further into the future.
      
      One complication to watch for is inadvertently scooping up
      stuff relating to machine check, since there is overlap in
      the TLA name space (e.g. arch/x86/boot/mca.c).
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: James Bottomley <JBottomley@Parallels.com>
      Cc: x86@kernel.org
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      bb8187d3
  27. 09 5月, 2012 3 次提交
  28. 08 5月, 2012 1 次提交
  29. 24 4月, 2012 2 次提交
  30. 30 3月, 2012 1 次提交
    • P
      ACPI: Fix use-after-free in acpi_map_lsapic · ac909ec3
      Petr Vandrovec 提交于
      When processor is being hot-added to the system, acpi_map_lsapic invokes
      ACPI _MAT method to find APIC ID and flags, verifies that returned structure
      is indeed ACPI's local APIC structure, and that flags contain MADT_ENABLED
      bit.  Then saves APIC ID, frees structure - and accesses structure when
      computing arguments for acpi_register_lapic call.  Which sometime leads
      to acpi_register_lapic call being made with second argument zero, failing
      to bring processor online with error 'Unable to map lapic to logical cpu
      number'.
      
      As lapic->lapic_flags & ACPI_MADT_ENABLED was already confirmed to be non-zero
      few lines above, we can just pass unconditional ACPI_MADT_ENABLED to the
      acpi_register_lapic.
      Signed-off-by: NPetr Vandrovec <petr@vmware.com>
      Signed-off-by: NAlok N Kataria <akataria@vmware.com>
      Reviewed-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      ac909ec3
  31. 29 3月, 2012 1 次提交
  32. 23 3月, 2012 1 次提交
    • S
      x86/apic: Add separate apic_id_valid() functions for selected apic drivers · b7157acf
      Steffen Persvold 提交于
      As suggested by Suresh Siddha and Yinghai Lu:
      
      For x2apic pre-enabled systems, apic driver is set already early
      through early_acpi_boot_init()/early_acpi_process_madt()/
      acpi_parse_madt()/default_acpi_madt_oem_check() path so that
      apic_id_valid() checking will be sufficient during MADT and SRAT
      parsing.
      
      For non-x2apic pre-enabled systems, all apic ids should be less
      than 255.
      
      This allows us to substitute the checks in
      arch/x86/kernel/acpi/boot.c::acpi_parse_x2apic() and
      arch/x86/mm/srat.c::acpi_numa_x2apic_affinity_init() with
      apic->apic_id_valid().
      
      In addition we can avoid feigning the x2apic cpu feature in the
      NumaChip apic code.
      
      The following apic drivers have separate apic_id_valid()
      functions which will accept x2apic type IDs :
      
       x2apic_phys
       x2apic_cluster
       x2apic_uv_x
       apic_numachip
      Signed-off-by: NSteffen Persvold <sp@numascale.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Daniel J Blueman <daniel@numascale-asia.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Jack Steiner <steiner@sgi.com>
      Link: http://lkml.kernel.org/r/1331925935-13372-1-git-send-email-sp@numascale.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      b7157acf