1. 02 Oct, 2009 6 commits
    • Tejun Heo's avatar
      percpu: kill legacy percpu allocator · 23fb064b
      Tejun Heo authored
      With ia64 converted, there's no arch left which still uses legacy
      percpu allocator.  Kill it.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Delightedly-acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      23fb064b
    • Tejun Heo's avatar
      ia64: convert to dynamic percpu allocator · 52594762
      Tejun Heo authored
      Unlike other archs, ia64 reserves space for percpu areas during early
      memory initialization.  These areas occupy a contiguous region indexed
      by cpu number on contiguous memory model or are grouped by node on
      discontiguous memory model.
      
      As allocation and initialization are done by the arch code, all that
      setup_per_cpu_areas() needs to do is communicating the determined
      layout to the percpu allocator.  This patch implements
      setup_per_cpu_areas() for both contig and discontig memory models and
      drops HAVE_LEGACY_PER_CPU_AREA.
      
      Please note that for contig model, the allocation itself is modified
      only to allocate for possible cpus instead of NR_CPUS.  As dynamic
      percpu allocator can handle non-direct mapping, there's no reason to
      allocate memory for cpus which aren't possible.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarTony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64 <linux-ia64@vger.kernel.org>
      52594762
    • Tejun Heo's avatar
      ia64: allocate percpu area for cpu0 like percpu areas for other cpus · 36886478
      Tejun Heo authored
      cpu0 used special percpu area reserved by the linker, __cpu0_per_cpu,
      which is set up early in boot by head.S.  However, this doesn't
      guarantee that the area will be on the same node as cpu0 and the
      percpu area for cpu0 ends up very far away from percpu areas for other
      cpus which cause problems for congruent percpu allocator.
      
      This patch makes percpu area initialization allocate percpu area for
      cpu0 like any other cpus and copy it from __cpu0_per_cpu which now
      resides in the __init area.  This means that for cpu0, percpu area is
      first setup at __cpu0_per_cpu early by head.S and then moved to an
      area in the linear mapping during memory initialization and it's not
      allowed to take a pointer to percpu variables between head.S and
      memory initialization.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarTony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64 <linux-ia64@vger.kernel.org>
      36886478
    • Tejun Heo's avatar
      ia64: initialize cpu maps early · 12cda817
      Tejun Heo authored
      All information necessary to initialize cpu possible and present maps
      are available once early_acpi_boot_init() is complete.  Reorganize
      setup_arch() and acpi init functions such that,
      
      * CPU information is printed after LAPIC entries are parsed in
        early_acpi_boot_init().
      
      * smp_build_cpu_map() is called by setup_arch() instead of acpi
        functions.
      
      * smp_build_cpu_map() is called once all CPU related information is
        available before memory is initialized.
      
      This is primarily to allow find_memory() to use cpu maps but is also a
      general cleanup.  Please note that with this change, the somewhat
      ad-hoc early_cpu_possible_map defined and used for NUMA configurations
      is probably unnecessary.  Something to clean up another day.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarTony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64 <linux-ia64@vger.kernel.org>
      12cda817
    • Tejun Heo's avatar
      ia64: don't alias VMALLOC_END to vmalloc_end · 126b3fcd
      Tejun Heo authored
      If CONFIG_VIRTUAL_MEM_MAP is enabled, ia64 defines macro VMALLOC_END
      as unsigned long variable vmalloc_end which is adjusted to prepare
      room for vmemmap.  This becomes probnlematic if a local variables
      vmalloc_end is defined in some function (not very unlikely) and
      VMALLOC_END is used in the function - the function thinks its
      referencing the global VMALLOC_END value but would be referencing its
      own local vmalloc_end variable.
      
      There's no reason VMALLOC_END should be a macro.  Just define it as an
      unsigned long variable if CONFIG_VIRTUAL_MEM_MAP is set to avoid nasty
      surprises.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarTony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: linux-ia64 <linux-ia64@vger.kernel.org>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      126b3fcd
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable · 0efe5e32
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable:
        Btrfs: fix data space leak fix
        Btrfs: remove duplicates of filemap_ helpers
        Btrfs: take i_mutex before generic_write_checks
        Btrfs: fix arguments to btrfs_wait_on_page_writeback_range
        Btrfs: fix deadlock with free space handling and user transactions
        Btrfs: fix error cases for ioctl transactions
        Btrfs: Use CONFIG_BTRFS_POSIX_ACL to enable ACL code
        Btrfs: introduce missing kfree
        Btrfs: Fix setting umask when POSIX ACLs are not enabled
        Btrfs: proper -ENOSPC handling
      0efe5e32
  2. 01 Oct, 2009 34 commits