1. 11 12月, 2012 1 次提交
    • P
      mm: numa: Add fault driven placement and migration · cbee9f88
      Peter Zijlstra 提交于
      NOTE: This patch is based on "sched, numa, mm: Add fault driven
      	placement and migration policy" but as it throws away all the policy
      	to just leave a basic foundation I had to drop the signed-offs-by.
      
      This patch creates a bare-bones method for setting PTEs pte_numa in the
      context of the scheduler that when faulted later will be faulted onto the
      node the CPU is running on.  In itself this does nothing useful but any
      placement policy will fundamentally depend on receiving hints on placement
      from fault context and doing something intelligent about it.
      Signed-off-by: NMel Gorman <mgorman@suse.de>
      Acked-by: NRik van Riel <riel@redhat.com>
      cbee9f88
  2. 09 10月, 2012 1 次提交
  3. 25 7月, 2012 1 次提交
    • P
      sh: Fix up recursive fault in oops with unset TTB. · 90eed7d8
      Paul Mundt 提交于
      Presently the oops code looks for the pgd either from the mm context or
      the cached TTB value. There are presently cases where the TTB can be
      unset or otherwise cleared by hardware, which we weren't handling,
      resulting in recursive faults on the NULL pgd. In these cases we can
      simply reload from swapper_pg_dir and continue on as normal.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      90eed7d8
  4. 14 6月, 2012 1 次提交
    • P
      sh64: Fix up section mismatch warnings. · 0412ddc8
      Paul Mundt 提交于
      WARNING: vmlinux.o(.cpuinit.text+0x280): Section mismatch in reference from the function cpu_probe() to the function .init.text:sh64_tlb_init()
      The function __cpuinit cpu_probe() references
      a function __init sh64_tlb_init().
      If sh64_tlb_init is only used by cpu_probe then
      annotate sh64_tlb_init with a matching annotation.
      
      sh64_tlb_init() simply needs to be __cpuinit annotated, so fix that up.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      0412ddc8
  5. 18 5月, 2012 2 次提交
  6. 14 5月, 2012 11 次提交
  7. 19 4月, 2012 3 次提交
    • P
      sh64: Kill off unused trap_no/error_code from thread_struct. · b2212ea4
      Paul Mundt 提交于
      While the trap number and error code are passed around for debugging
      purposes, this occurs wholly independently of the thread struct values.
      These values were never part of the sigcontext ABI and are thus never
      passed anywhere, so we can just kill them off across the board.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      b2212ea4
    • S
      sh: Improve oops error reporting · 45c0e0e2
      Stuart Menefy 提交于
      In some cases the opps error reporting doesn't give enough information
      to diagnose the problem, only printing information if it is thought
      to be valid. Replace the current code with more detailed output.
      
      This code is based on the ARM reporting, with minor changes for the SH.
      
      [lethal@linux-sh.org: fixed up for 64-bit PTEs and pte_offset_kernel()]
      Signed-off-by: NStuart Menefy <stuart.menefy@st.com>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      45c0e0e2
    • S
      sh: Fix error synchronising kernel page tables · 8d9a784d
      Stuart Menefy 提交于
      The problem is caused by the interaction of two features in the Linux
      memory management code.
      
      A processes address space is described by a struct mm_struct, and
      every thread has a pointer to the mm it should run in. The exception
      to this are kernel threads, which don't have an mm, and so borrow
      the mm from the last thread which ran. The system is bootstrapped
      by the initial kernel thread using init's mm (even though init hasn't
      been created yet, its mm is the static init_mm).
      
      The other feature is how the kernel handles the page table which
      describes the portion of the address space which is only visible when
      executing inside the kernel, and which is shared by all threads. On
      the SH4 the only portion of the kernel's address space which described
      using the page table is called P3, from 0xc0000000 to 0xdfffffff. This
      portion of the address space is divided into three:
        - mappings for dma_alloc_coherent()
        - mappings for vmalloc() and ioremap()
        - fixmap mappings, primarily used in copy_user_pages() to create
          kernel mappings of user pages with the correct cache colour.
      
      To optimise the TLB miss handler we don't want to add an additional
      condition which checks whether the faulting address is in the user or
      the kernel portion of the address space, and so all page tables have a
      common portion which describes the kernel part of the address
      space. As the SH4 uses a two level page table, only the kernel portion
      of first level page table (the pgd entries) is duplicated. These all
      point to the same second level entries (the pte's), and so no memory
      is wasted.
      
      The reference page table for the kernel is called the swapper_pg_dir,
      and when a new page table is created for a new process the kernel
      portion of the page table is copied from swapper_pg_dir. This works
      fine when changes only occur in the second level of the kernel's page
      table, or the first level entries are created before any new user
      processes. However if a change occurs to the first level of the page
      table, and there are existing processes which don't have this entry in
      their page table, this new entry needs to be added. This is done on
      demand, when the kernel accesses a P3 address which isn't mapped using
      the current page table, the code in vmalloc_fault() copies the entry
      from the reference page table (swapper_pg_dir) into the current
      processes page table.
      
      The bug which this patch addresses is that the code in vmalloc_fault()
      was not copying addresses which fell in the dma_alloc_coherent()
      portion of the address space, and it should have been copying any P3
      address.
      
      Why we hadn't seen this before, and what made this hard to reproduce,
      is that normally the kernel will have called dma_alloc_coherent(), and
      accessed the memory mapping created, before any user process
      runs. Typically drivers such as USB or SATA will have created and used
      mappings of this type during the kernel initialisation, when probing
      for the attached devices, before init runs. Ethernet is slightly
      different, as it normally only creates and accesses
      dma_alloc_coherent() mappings when the network is brought up, but if
      kernel level IP configuration is used this will also occur before any
      user space process runs. So the first reproduction of this problem
      which we saw was occurred when USB and SATA were removed from the
      kernel, and then bring up Ethernet from user space using ifconfig.
      I'd like to thank Joseph Bormolini who did the hard work reducing the
      problem to this simple to reproduce criteria.
      
      In your case the situation is slightly different, and turns out to
      depends on the exact kernel configuration (which we had) and your
      ramdisk contents (which we didn't - hence the need for some assumptions).
      
      In this case the problem is a side effect of kernel level module
      loading. Kernel subsystems sometimes trigger the load of kernel
      modules directly, for example the crypto subsystem tries to load the
      cryptomgr and MTD tries to load modules for Flash partitioning if
      these are not built into the kernel. This is done by the kernel
      creating a user process which runs insmod to try and load the
      appropriate module.
      
      In order for this to cause problems the system must be running with a
      initrd or initramfs, which contains an insmod executable - if the
      kernel can't find an insmod to run, no user process is created, and
      the problem doesn't occur.  If an insmod is found, a process is
      created to run it, which will inherit the kernel portion of the
      swapper_pg_dir first level page table. It doesn't matter whether the
      inmod is successful or not, but when the the kernel scheduler context
      switches back to the kernel initialisation thread, the insmod's mm is
      'borrowed' by the kernel thread, as it doesn't have an address space
      of its own. (Reference counting is used to ensure this mm is not
      destroyed, even though the user process which caused its creation may no
      longer exist.) If this address space doesn't have a first level page
      table entry for the consistent mappings, and a driver tries to access
      such a mapping, we are in the same situation as described above,
      except this time in a kernel thread rather than a user thread
      executing inside the kernel.
      
      See bugzilla: 15425, 15836, 15862, 16106, 16793
      Signed-off-by: NStuart Menefy <stuart.menefy@st.com>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      8d9a784d
  8. 11 4月, 2012 3 次提交
  9. 30 3月, 2012 1 次提交
  10. 29 3月, 2012 1 次提交
  11. 28 3月, 2012 1 次提交
  12. 20 3月, 2012 1 次提交
  13. 24 2月, 2012 1 次提交
  14. 12 1月, 2012 1 次提交
    • P
      sh: sh2a: Improve cache flush/invalidate functions · c1537b48
      Phil Edworthy 提交于
      The cache functions lock out interrupts for long periods; this patch
      reduces the impact when operating on large address ranges. In such
      cases it will:
      - Invalidate the entire cache rather than individual addresses.
      - Do nothing when flushing the operand cache in write-through mode.
      - When flushing the operand cache in write-back mdoe, index the
        search for matching addresses on the cache entires instead of the
        addresses to flush
      
      Note: sh2a__flush_purge_region was only invalidating the operand
      cache, this adds flush.
      Signed-off-by: NPhil Edworthy <phil.edworthy@renesas.com>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      c1537b48
  15. 09 12月, 2011 3 次提交
    • T
      memblock: Kill early_node_map[] · 0ee332c1
      Tejun Heo 提交于
      Now all ARCH_POPULATES_NODE_MAP archs select HAVE_MEBLOCK_NODE_MAP -
      there's no user of early_node_map[] left.  Kill early_node_map[] and
      replace ARCH_POPULATES_NODE_MAP with HAVE_MEMBLOCK_NODE_MAP.  Also,
      relocate for_each_mem_pfn_range() and helper from mm.h to memblock.h
      as page_alloc.c would no longer host an alternative implementation.
      
      This change is ultimately one to one mapping and shouldn't cause any
      observable difference; however, after the recent changes, there are
      some functions which now would fit memblock.c better than page_alloc.c
      and dependency on HAVE_MEMBLOCK_NODE_MAP instead of HAVE_MEMBLOCK
      doesn't make much sense on some of them.  Further cleanups for
      functions inside HAVE_MEMBLOCK_NODE_MAP in mm.h would be nice.
      
      -v2: Fix compile bug introduced by mis-spelling
       CONFIG_HAVE_MEMBLOCK_NODE_MAP to CONFIG_MEMBLOCK_HAVE_NODE_MAP in
       mmzone.h.  Reported by Stephen Rothwell.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Chen Liqin <liqin.chen@sunplusct.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      0ee332c1
    • T
      memblock: s/memblock_analyze()/memblock_allow_resize()/ and update users · 1aadc056
      Tejun Heo 提交于
      The only function of memblock_analyze() is now allowing resize of
      memblock region arrays.  Rename it to memblock_allow_resize() and
      update its users.
      
      * The following users remain the same other than renaming.
      
        arm/mm/init.c::arm_memblock_init()
        microblaze/kernel/prom.c::early_init_devtree()
        powerpc/kernel/prom.c::early_init_devtree()
        openrisc/kernel/prom.c::early_init_devtree()
        sh/mm/init.c::paging_init()
        sparc/mm/init_64.c::paging_init()
        unicore32/mm/init.c::uc32_memblock_init()
      
      * In the following users, analyze was used to update total size which
        is no longer necessary.
      
        powerpc/kernel/machine_kexec.c::reserve_crashkernel()
        powerpc/kernel/prom.c::early_init_devtree()
        powerpc/mm/init_32.c::MMU_init()
        powerpc/mm/tlb_nohash.c::__early_init_mmu()  
        powerpc/platforms/ps3/mm.c::ps3_mm_add_memory()
        powerpc/platforms/embedded6xx/wii.c::wii_memory_fixups()
        sh/kernel/machine_kexec.c::reserve_crashkernel()
      
      * x86/kernel/e820.c::memblock_x86_fill() was directly setting
        memblock_can_resize before populating memblock and calling analyze
        afterwards.  Call memblock_allow_resize() before start populating.
      
      memblock_can_resize is now static inside memblock.c.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      1aadc056
    • T
      memblock: Kill memblock_init() · fe091c20
      Tejun Heo 提交于
      memblock_init() initializes arrays for regions and memblock itself;
      however, all these can be done with struct initializers and
      memblock_init() can be removed.  This patch kills memblock_init() and
      initializes memblock with struct initializer.
      
      The only difference is that the first dummy entries don't have .nid
      set to MAX_NUMNODES initially.  This doesn't cause any behavior
      difference.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      fe091c20
  16. 01 11月, 2011 1 次提交
  17. 28 10月, 2011 1 次提交
    • S
      sh: kexec: Add PHYSICAL_START · e66ac3f2
      Simon Horman 提交于
      Add PHYSICAL_START kernel configuration parameter to set the address at
      which the kernel should be loaded.
      
      It has been observed on an sh7757lcr that simply modifying MEMORY_START
      does not achieve this goal for 32bit sh. This is due to MEMORY_OFFSET in
      arch/sh/kernel/vmlinux.lds.S bot being based on MEMORY_START on such
      systems.
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      e66ac3f2
  18. 01 7月, 2011 1 次提交
    • P
      perf: Remove the nmi parameter from the swevent and overflow interface · a8b0ca17
      Peter Zijlstra 提交于
      The nmi parameter indicated if we could do wakeups from the current
      context, if not, we would set some state and self-IPI and let the
      resulting interrupt do the wakeup.
      
      For the various event classes:
      
        - hardware: nmi=0; PMI is in fact an NMI or we run irq_work_run from
          the PMI-tail (ARM etc.)
        - tracepoint: nmi=0; since tracepoint could be from NMI context.
        - software: nmi=[0,1]; some, like the schedule thing cannot
          perform wakeups, and hence need 0.
      
      As one can see, there is very little nmi=1 usage, and the down-side of
      not using it is that on some platforms some software events can have a
      jiffy delay in wakeup (when arch_irq_work_raise isn't implemented).
      
      The up-side however is that we can remove the nmi parameter and save a
      bunch of conditionals in fast paths.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Michael Cree <mcree@orcon.net.nz>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Eric B Munson <emunson@mgebm.net>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Link: http://lkml.kernel.org/n/tip-agjev8eu666tvknpb3iaj0fg@git.kernel.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>
      a8b0ca17
  19. 30 6月, 2011 1 次提交
  20. 06 6月, 2011 1 次提交
  21. 31 5月, 2011 1 次提交
  22. 25 5月, 2011 1 次提交
  23. 23 3月, 2011 1 次提交