1. 08 8月, 2009 2 次提交
    • C
      vfs: add __destroy_inode · 2e00c97e
      Christoph Hellwig 提交于
      When we want to tear down an inode that lost the add to the cache race
      in XFS we must not call into ->destroy_inode because that would delete
      the inode that won the race from the inode cache radix tree.
      
      This patch provides the __destroy_inode helper needed to fix this,
      the actual fix will be in th next patch.  As XFS was the only reason
      destroy_inode was exported we shift the export to the new __destroy_inode.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NEric Sandeen <sandeen@sandeen.net>
      2e00c97e
    • C
      vfs: fix inode_init_always calling convention · 54e34621
      Christoph Hellwig 提交于
      Currently inode_init_always calls into ->destroy_inode if the additional
      initialization fails.  That's not only counter-intuitive because
      inode_init_always did not allocate the inode structure, but in case of
      XFS it's actively harmful as ->destroy_inode might delete the inode from
      a radix-tree that has never been added.  This in turn might end up
      deleting the inode for the same inum that has been instanciated by
      another process and cause lots of cause subtile problems.
      
      Also in the case of re-initializing a reclaimable inode in XFS it would
      free an inode we still want to keep alive.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NEric Sandeen <sandeen@sandeen.net>
      54e34621
  2. 05 8月, 2009 31 次提交
  3. 04 8月, 2009 7 次提交
    • S
      x86: Work around compilation warning in arch/x86/kernel/apm_32.c · dc731fbb
      Subrata Modak 提交于
      The following fix was initially inspired by David Howells fix
      few days back:
      
        http://lkml.org/lkml/2009/7/9/109
      
      However, Ingo disapproves such fixes as it's dangerous (it can
      hide future, relevant warnings) - in something as
      performance-uncritical.
      
      So, initialize 'err' to '0' to work around a GCC false positive
      warning:
      
        http://lkml.org/lkml/2009/7/18/89
      
      Signed-off-by: Subrata Modak<subrata@linux.vnet.ibm.com>
      Cc: Sachin P Sant <sachinp@linux.vnet.ibm.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      LKML-Reference: <20090721023226.31855.67236.sendpatchset@subratamodak.linux.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dc731fbb
    • J
      x86, UV: Complete IRQ interrupt migration in arch_enable_uv_irq() · 2a5ef416
      Jack Steiner 提交于
      In uv_setup_irq(), the call to create_irq() initially assigns
      IRQ vectors to cpu 0. The subsequent call to
      assign_irq_vector() in arch_enable_uv_irq() migrates the IRQ to
      another cpu and frees the cpu 0 vector - at least it will be
      freed as soon as the "IRQ move" completes.
      
      arch_enable_uv_irq() needs to send a cleanup IPI to complete
      the IRQ move. Otherwise, assignment of GRU interrupts on large
      systems (>200 cpus) will exhaust the cpu 0 interrupt vectors
      and initialization of the GRU driver will fail.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      LKML-Reference: <20090720142840.GA8885@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2a5ef416
    • J
      x86, 32-bit: Fix double accounting in reserve_top_address() · 6abf6551
      Jan Beulich 提交于
      With VMALLOC_END included in the calculation of MAXMEM (as of
      2.6.28) it is no longer correct to also bump __VMALLOC_RESERVE
      in reserve_top_address(). Doing so results in needlessly small
      lowmem.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      LKML-Reference: <4A71DD2A020000780000D482@vpn.id2.novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6abf6551
    • Y
      x86: Don't use current_cpu_data in x2apic phys_pkg_id · d8c7eb34
      Yinghai Lu 提交于
      One system has socket 1 come up as BSP.
      
      kexeced kernel reports BSP as:
      
      [    1.524550] Initializing cgroup subsys cpuacct
      [    1.536064] initial_apicid:20
      [    1.537135] ht_mask_width:1
      [    1.538128] core_select_mask:f
      [    1.539126] core_plus_mask_width:5
      [    1.558479] CPU: Physical Processor ID: 0
      [    1.559501] CPU: Processor Core ID: 0
      [    1.560539] CPU: L1 I cache: 32K, L1 D cache: 32K
      [    1.579098] CPU: L2 cache: 256K
      [    1.580085] CPU: L3 cache: 24576K
      [    1.581108] CPU 0/0x20 -> Node 0
      [    1.596193] CPU 0 microcode level: 0xffff0008
      
      It doesn't have correct physical processor id and will get an
      error:
      
      [   38.840859] CPU0 attaching sched-domain:
      [   38.848287]  domain 0: span 0,8,72 level SIBLING
      [   38.851151]   groups: 0 8 72
      [   38.858137]   domain 1: span 0,8-15,72-79 level MC
      [   38.868944]    groups: 0,8,72 9,73 10,74 11,75 12,76 13,77 14,78 15,79
      [   38.881383] ERROR: parent span is not a superset of domain->span
      [   38.890724]    domain 2: span 0-7,64-71 level CPU
      [   38.899237] ERROR: domain->groups does not contain CPU0
      [   38.909229]     groups: 8-15,72-79
      [   38.912547] ERROR: groups don't span domain->span
      [   38.919665]     domain 3: span 0-127 level NODE
      [   38.930739]      groups: 0-7,64-71 8-15,72-79 16-23,80-87 24-31,88-95 32-39,96-103 40-47,104-111 48-55,112-119 56-63,120-127
      
      it turns out: we can not use current_cpu_data in phys_pgd_id
      for x2apic.
      
      identify_boot_cpu() is called by check_bugs() before
      smp_prepare_cpus() and till smp_prepare_cpus() current_cpu_data
      for bsp is assigned with boot_cpu_data.
      
      Just make phys_pkg_id for x2apic is aligned to xapic.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <4A6ADD0D.10002@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d8c7eb34
    • J
      x86, UV: Fix UV apic mode · c5997fa8
      Jack Steiner 提交于
      Change SGI UV default apicid mode to "physical". This is
      required to match settings in the UV hub chip.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      LKML-Reference: <20090727143856.GA8905@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c5997fa8
    • J
      x86, UV: Fix macros for accessing large node numbers · 67e83f30
      Jack Steiner 提交于
      The UV chipset automatically supplies the upper bits on nodes
      being referenced by MMR accesses. These bit can be deleted from
      the hub addressing macros.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      LKML-Reference: <20090727143808.GA8076@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      67e83f30
    • J
      x86, UV: Delete mapping of MMR rangs mapped by BIOS · cc5e4fa1
      Jack Steiner 提交于
      The UV BIOS has added additional MMR ranges that are mapped via
      EFI virtual mode mappings. These ranges should be deleted from
      ranges mapped by uv_system_init().
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Cc: linux-mm@kvack.org
      LKML-Reference: <20090727143656.GA7698@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cc5e4fa1
反馈
建议
客服 返回
顶部