1. 21 4月, 2009 1 次提交
  2. 09 3月, 2009 1 次提交
    • Y
      x86: fix warning about nodeid · e954ef20
      Yinghai Lu 提交于
      Impact: cleanup
      
      Ingo found there warning about nodeid with some configs.
      
      try to use for_each_online_node for non numa too. in that case
      nodeid will be 0.
      
      also move out boundary checking from setup_node_bootmem(), so
      non-numa config will not check it.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <49B03069.80001@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e954ef20
  3. 05 3月, 2009 23 次提交
  4. 04 3月, 2009 1 次提交
  5. 03 3月, 2009 5 次提交
  6. 24 2月, 2009 1 次提交
    • T
      x86: update populate_extra_pte() and add populate_extra_pmd() · 458a3e64
      Tejun Heo 提交于
      Impact: minor change to populate_extra_pte() and addition of pmd flavor
      
      Update populate_extra_pte() to return pointer to the pte_t for the
      specified address and add populate_extra_pmd() which only populates
      till the pmd and returns pointer to the pmd entry for the address.
      
      For 64bit, pud/pmd/pte fill functions are separated out from
      set_pte_vaddr[_pud]() and used for set_pte_vaddr[_pud]() and
      populate_extra_{pte|pmd}().
      Signed-off-by: NTejun Heo <tj@kernel.org>
      458a3e64
  7. 21 2月, 2009 1 次提交
    • S
      ftrace, x86: make kernel text writable only for conversions · 16239630
      Steven Rostedt 提交于
      Impact: keep kernel text read only
      
      Because dynamic ftrace converts the calls to mcount into and out of
      nops at run time, we needed to always keep the kernel text writable.
      
      But this defeats the point of CONFIG_DEBUG_RODATA. This patch converts
      the kernel code to writable before ftrace modifies the text, and converts
      it back to read only afterward.
      
      The kernel text is converted to read/write, stop_machine is called to
      modify the code, then the kernel text is converted back to read only.
      
      The original version used SYSTEM_STATE to determine when it was OK
      or not to change the code to rw or ro. Andrew Morton pointed out that
      using SYSTEM_STATE is a bad idea since there is no guarantee to what
      its state will actually be.
      
      Instead, I moved the check into the set_kernel_text_* functions
      themselves, and use a local variable to determine when it is
      OK to change the kernel text RW permissions.
      
      [ Update: Ingo Molnar suggested moving the prototypes to cacheflush.h ]
      Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      16239630
  8. 20 2月, 2009 1 次提交
    • T
      x86: convert to the new dynamic percpu allocator · 11124411
      Tejun Heo 提交于
      Impact: use new dynamic allocator, unified access to static/dynamic
              percpu memory
      
      Convert to the new dynamic percpu allocator.
      
      * implement populate_extra_pte() for both 32 and 64
      * update setup_per_cpu_areas() to use pcpu_setup_static()
      * define __addr_to_pcpu_ptr() and __pcpu_ptr_to_addr()
      * define config HAVE_DYNAMIC_PER_CPU_AREA
      Signed-off-by: NTejun Heo <tj@kernel.org>
      11124411
  9. 12 2月, 2009 4 次提交
  10. 16 1月, 2009 1 次提交
    • J
      x86: fix assumed to be contiguous leaf page tables for kmap_atomic region (take 2) · a3c6018e
      Jan Beulich 提交于
      Debugging and original patch from Nick Piggin <npiggin@suse.de>
      
      The early fixmap pmd entry inserted at the very top of the KVA is causing the
      subsequent fixmap mapping code to not provide physically linear pte pages over
      the kmap atomic portion of the fixmap (which relies on said property to
      calculate pte addresses).
      
      This has caused weird boot failures in kmap_atomic much later in the boot
      process (initial userspace faults) on a 32-bit PAE system with a larger number
      of CPUs (smaller CPU counts tend not to run over into the next page so don't
      show up the problem).
      
      Solve this by attempting to clear out the page table, and copy any of its
      entries to the new one. Also, add a bug if a nonlinear condition is encountered
      and can't be resolved, which might save some hours of debugging if this fragile
      scheme ever breaks again...
      
      Once we have such logic, we can also use it to eliminate the early ioremap
      trickery around the page table setup for the fixmap area. This also fixes
      potential issues with FIX_* entries sharing the leaf page table with the early
      ioremap ones getting discarded by early_ioremap_clear() and not restored by
      early_ioremap_reset(). It at once eliminates the temporary (and configuration,
      namely NR_CPUS, dependent) unavailability of early fixed mappings during the
      time the fixmap area page tables get constructed.
      
      Finally, also replace the hard coded calculation of the initial table space
      needed for the fixmap area with a proper one, allowing kernels configured for
      large CPU counts to actually boot.
      
      Based-on: Nick Piggin <npiggin@suse.de>
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a3c6018e
  11. 08 1月, 2009 1 次提交
    • A
      resource: allow MMIO exclusivity for device drivers · e8de1481
      Arjan van de Ven 提交于
      Device drivers that use pci_request_regions() (and similar APIs) have a
      reasonable expectation that they are the only ones accessing their device.
      As part of the e1000e hunt, we were afraid that some userland (X or some
      bootsplash stuff) was mapping the MMIO region that the driver thought it
      had exclusively via /dev/mem or via various sysfs resource mappings.
      
      This patch adds the option for device drivers to cause their reserved
      regions to the "banned from /dev/mem use" list, so now both kernel memory
      and device-exclusive MMIO regions are banned.
      NOTE: This is only active when CONFIG_STRICT_DEVMEM is set.
      
      In addition to the config option, a kernel parameter iomem=relaxed is
      provided for the cases where developers want to diagnose, in the field,
      drivers issues from userspace.
      Reviewed-by: NMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      e8de1481