1. 05 Nov, 2008 7 commits
  2. 03 Nov, 2008 1 commit
  3. 02 Nov, 2008 2 commits
  4. 01 Nov, 2008 5 commits
    • Al Viro's avatar
    • Hugh Dickins's avatar
      sparc64: Fix __copy_{to,from}_user_inatomic defines. · 145e1c00
      Hugh Dickins authored
      Alexander Beregalov reports oops in __bzero() called from
      copy_from_user_fixup() called from iov_iter_copy_from_user_atomic(),
      when running dbench on tmpfs on sparc64: its __copy_from_user_inatomic
      and __copy_to_user_inatomic should be avoiding, not calling, the fixups.
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Al Viro's avatar
    • Linus Torvalds's avatar
      x86: Clean up late e820 resource allocation · 1f987577
      Linus Torvalds authored
      This makes the late e820 resources use 'insert_resource_expand_to_fit()'
      instead of doing a 'reserve_region_with_split()', and also avoids
      marking them as IORESOURCE_BUSY.
      This results in us being perfectly happy to use pre-existing PCI
      resources even if they were marked as being in a reserved region, while
      still avoiding any _new_ allocations in the reserved regions.  It also
      makes for a simpler and more accurate resource tree.
      Example resource allocation from Jonathan Corbet, who has firmware that
      has an e820 reserved entry that covered a big range (e0000000-fed003ff),
      and that had various PCI resources in it set up by firmware.
      With old kernels, the reserved range would force us to re-allocate all
      pre-existing PCI resources, and his reserved range would end up looking
      like this:
      	e0000000-fed003ff : reserved
      	  fec00000-fec00fff : IOAPIC 0
      	  fed00000-fed003ff : HPET 0
      where only the pre-allocated special regions (IOAPIC and HPET) were kept
      With 2.6.28-rc2, which uses 'reserve_region_with_split()', Jonathan's
      resource tree looked like this:
      	e0000000-fe7fffff : reserved
      	fe800000-fe8fffff : PCI Bus 0000:01
      	 fe800000-fe8fffff : reserved
      	fe900000-fe9d9aff : reserved
      	fe9d9b00-fe9d9bff : 0000:00:1f.3
      	 fe9d9b00-fe9d9bff : reserved
      	fe9d9c00-fe9d9fff : 0000:00:1a.7
      	 fe9d9c00-fe9d9fff : reserved
      	fe9da000-fe9dafff : 0000:00:03.3
      	 fe9da000-fe9dafff : reserved
      	fe9db000-fe9dbfff : 0000:00:19.0
      	 fe9db000-fe9dbfff : reserved
      	fe9dc000-fe9dffff : 0000:00:1b.0
      	 fe9dc000-fe9dffff : reserved
      	fe9e0000-fe9fffff : 0000:00:19.0
      	 fe9e0000-fe9fffff : reserved
      	fea00000-fea7ffff : 0000:00:02.0
      	 fea00000-fea7ffff : reserved
      	fea80000-feafffff : 0000:00:02.1
      	 fea80000-feafffff : reserved
      	feb00000-febfffff : 0000:00:02.0
      	 feb00000-febfffff : reserved
      	fec00000-fed003ff : reserved
      	 fec00000-fec00fff : IOAPIC 0
      	 fed00000-fed003ff : HPET 0
      and because the reserved entry had been split and moved into the
      individual resources, and because it used the IORESOURCE_BUSY flag, the
      drivers that actually wanted to _use_ those resources couldn't actually
      attach to them:
      	e1000e 0000:00:19.0: BAR 0: can't reserve mem region [0xfe9e0000-0xfe9fffff]
      	HDA Intel 0000:00:1b.0: BAR 0: can't reserve mem region [0xfe9dc000-0xfe9dffff]
      with this patch, the resource tree instead becomes
      	e0000000-fed003ff : reserved
      	  fe800000-fe8fffff : PCI Bus 0000:01
      	  fe9d9b00-fe9d9bff : 0000:00:1f.3
      	  fe9d9c00-fe9d9fff : 0000:00:1a.7
      	    fe9d9c00-fe9d9fff : ehci_hcd
      	  fe9da000-fe9dafff : 0000:00:03.3
      	  fe9db000-fe9dbfff : 0000:00:19.0
      	    fe9db000-fe9dbfff : e1000e
      	  fe9dc000-fe9dffff : 0000:00:1b.0
      	    fe9dc000-fe9dffff : ICH HD audio
      	  fe9e0000-fe9fffff : 0000:00:19.0
      	    fe9e0000-fe9fffff : e1000e
      	  fea00000-fea7ffff : 0000:00:02.0
      	  fea80000-feafffff : 0000:00:02.1
      	  feb00000-febfffff : 0000:00:02.0
      	  fec00000-fec00fff : IOAPIC 0
      	  fed00000-fed003ff : HPET 0
      ie the one reserved region now ends up surrounding all the PCI resources
      that were allocated inside of it by firmware, and because it is not
      marked BUSY, drivers have no problem attaching to the pre-allocated
      Reported-and-tested-by: default avatarJonathan Corbet <corbet@lwn.net>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Robert Hancock <hancockr@shaw.ca>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Al Viro's avatar
      saner FASYNC handling on file close · 233e70f4
      Al Viro authored
      As it is, all instances of ->release() for files that have ->fasync()
      need to remember to evict file from fasync lists; forgetting that
      creates a hole and we actually have a bunch that *does* forget.
      So let's keep our lives simple - let __fput() check FASYNC in
      file->f_flags and call ->fasync() there if it's been set.  And lose that
      crap in ->release() instances - leaving it there is still valid, but we
      don't have to bother anymore.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  5. 31 Oct, 2008 16 commits
  6. 30 Oct, 2008 9 commits
    • David S. Miller's avatar
    • Carl Love's avatar
      powerpc/cell/OProfile: Fix on-stack array size in activate spu profiling function · 210434d7
      Carl Love authored
      The size of the pm_signal_local array should be equal to the
      number of SPUs being configured in the array.  Currently, the
      array is of size 4 (NR_PHYS_CTRS) but being indexed by a for
      loop from 0 to 7 (NUM_SPUS_PER_NODE).  This could potentially
      cause an oops or random memory corruption since the pm_signal_local
      array is on the stack.  This fixes it.
      Signed-off-by: default avatarCarl Love <carll@us.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Kumar Gala's avatar
      powerpc/mpic: Fix regression caused by change of default IRQ affinity · 3c10c9c4
      Kumar Gala authored
      The Freescale implementation of MPIC only allows a single CPU destination
      for non-IPI interrupts.  We add a flag to the mpic_init to distinquish
      these variants of MPIC.  We pull in the irq_choose_cpu from sparc64 to
      select a single CPU as the destination of the interrupt.
      This is to deal with the fact that the default smp affinity was
      changed by commit 18404756
      Expose default irq affinity mask (take 3)") to be all CPUs.
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Mark Nelson's avatar
      powerpc: Update remaining dma_mapping_ops to use map/unmap_page · f9226d57
      Mark Nelson authored
      After the merge of the 32 and 64bit DMA code, dma_direct_ops lost
      their map/unmap_single() functions but gained map/unmap_page().  This
      caused a problem for Cell because Cell's dma_iommu_fixed_ops called
      the dma_direct_ops if the fixed linear mapping was to be used or the
      iommu ops if the dynamic window was to be used.  So in order to fix
      this problem we need to update the 64bit DMA code to use
      First, we update the generic IOMMU code so that iommu_map_single()
      becomes iommu_map_page() and iommu_unmap_single() becomes
      iommu_unmap_page().  Then we propagate these changes up through all
      the callers of these two functions and in the process update all the
      dma_mapping_ops so that they have map/unmap_page rahter than
      map/unmap_single.  We can do this because on 64bit there is no HIGHMEM
      memory so map/unmap_page ends up performing exactly the same function
      as map/unmap_single, just taking different arguments.
      This has no affect on drivers because the dma_map_single_attrs() just
      ends up calling the map_page() function of the appropriate
      dma_mapping_ops and similarly the dma_unmap_single_attrs() calls
      This fixes an oops on Cell blades, which oops on boot without this
      because they call dma_direct_ops.map_single, which is NULL.
      Signed-off-by: default avatarMark Nelson <markn@au1.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Benjamin Herrenschmidt's avatar
      powerpc/pci: Fix unmapping of IO space on 64-bit · b30115ea
      Benjamin Herrenschmidt authored
      A typo/thinko made us pass the wrong argument to __flush_hash_table_range
      when unplugging bridges, thus not flushing all the translations for
      the IO space on unplug.  The third parameter to __flush_hash_table_range
      is `end', not `size'.
      This causes the hypervisor to refuse unplugging slots.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Nathan Fontenot's avatar
      powerpc/pci: Properly allocate bus resources for hotplug PHBs · e90a1318
      Nathan Fontenot authored
      Resources for PHB's that are dynamically added to a system are not
      properly allocated in the resource tree.
      Not having these resources allocated causes an oops when removing
      the PHB when we try to release them.
      The diff appears a bit messy, this is mainly due to moving everything
      one tab to the left in the pcibios_allocate_bus_resources routine.
      The functionality change in this routine is only that the
      list_for_each_entry() loop is pulled out and moved to the necessary
      calling routine.
      Signed-off-by: default avatarNathan Fontenot <nfont@austin.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Jeremy Kerr's avatar
      OF-device: Don't overwrite numa_node in device registration · 6098e2ee
      Jeremy Kerr authored
      Currently, the numa_node of OF-devices will be overwritten during
      device_register, which simply sets the node to -1.  On cell machines,
      this means that devices can't find their IOMMU, which is referenced
      through the device's numa node.
      Set the numa node for OF devices with no parent, and use the
      lower-level device_initialize and device_add functions, so that the
      node is preserved.
      We can remove the call to set_dev_node in of_device_alloc, as it
      will be overwritten during register.
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Michael Neuling's avatar
      powerpc: Fix swapcontext system for VSX + old ucontext size · 16c29d18
      Michael Neuling authored
      Since VSX support was added, we now have two sizes of ucontext_t;
      the older, smaller size without the extra VSX state, and the new
      larger size with the extra VSX state.  A program using the
      sys_swapcontext system call and supplying smaller ucontext_t
      structures will currently get an EINVAL error if the task has
      used VSX (e.g. because of calling library code that uses VSX) and
      the old_ctx argument is non-NULL (i.e. the program is asking for
      its current context to be saved).  Thus the program will start
      getting EINVAL errors on calls that previously worked.
      This commit changes this behaviour so that we don't send an EINVAL in
      this case.  It will now return the smaller context but the VSX MSR bit
      will always be cleared to indicate that the ucontext_t doesn't include
      the extra VSX state, even if the task has executed VSX instructions.
      Both 32 and 64 bit cases are updated.
      [paulus@samba.org - also fix some access_ok() and get_user() calls]
      Thanks to Ben Herrenschmidt for noticing this problem.
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Michael Neuling's avatar
      powerpc: Fix compiler warning for the relocatable kernel · b160544c
      Michael Neuling authored
      Fixes this warning:
       arch/powerpc/kernel/setup_64.c:447:5: warning: "kernstart_addr" is not defined
      which arises because PHYSICAL_START is no longer a constant when
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>