08 Dec, 2011

1 commit

  • This patch addresses a couple of related problems:

    1) The kernel may reside in physical memory outside of the ranges set
    by plat_mem_setup(). If this is the case, init mem cannot be
    reused as it resides outside of the range of pages that the kernel
    memory allocators control.

    2) initrd images might be loaded in physical memory outside of the
    ranges set by plat_mem_setup(). The memory likewise cannot be
    reused. The patch doesn't handle this specific case, but the
    infrastructure is useful for future patches that do.

    The crux of the problem is that there are memory regions that need be
    memory_present(), but that cannot be free_bootmem() at the time of
    arch_mem_init(). We create a new type of memory (BOOT_MEM_INIT_RAM)
    for use with add_memory_region(). Then arch_mem_init() adds the init
    mem with this type if the init mem is not already covered by existing
    ranges.

    When memory is being freed into the bootmem allocator, we skip the
    BOOT_MEM_INIT_RAM ranges so they are not clobbered, but we do signal
    them as memory_present(). This way when they are later freed, the
    necessary memory manager structures have initialized and the Sparse
    allocater is prevented from crashing.

    The Octeon specific code that handled this case is removed, because
    the new general purpose code handles the case.

    Signed-off-by: David Daney
    To: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/1988/
    Signed-off-by: Ralf Baechle

    David Daney
     

26 Jul, 2011

2 commits

  • fixrange_init() allocates page tables for all addresses higher than
    FIXADDR_TOP. On processors that override the default FIXADDR_TOP
    address of 0xfffe_0000, this can consume up to 4 pages (1 page per 4MB)
    for pgd's that are never used.

    Signed-off-by: Kevin Cernekee
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/1980/
    Signed-off-by: Ralf Baechle

    Kevin Cernekee
     
  • pfn_valid() compares the PFN to max_mapnr:

    __pfn >= min_low_pfn && __pfn < max_mapnr;

    On HIGHMEM kernels, highend_pfn is used to set the value of max_mapnr.
    Unfortunately, highend_pfn is left at zero if the system does not
    actually have enough RAM to reach into the HIGHMEM range. This causes
    pfn_valid() to always return false, and when debug checks are enabled
    the kernel will fail catastrophically:

    Memory: 22432k/32768k available (2249k kernel code, 10336k reserved, 653k data, 1352k init, 0k highmem)
    NR_IRQS:128
    kfree_debugcheck: out of range ptr 81c02900h.
    Kernel bug detected[#1]:
    Cpu 0
    $ 0 : 00000000 10008400 00000034 00000000
    $ 4 : 8003e160 802a0000 8003e160 00000000
    $ 8 : 00000000 0000003e 00000747 00000747
    ...

    On such a configuration, max_low_pfn should be used to set max_mapnr.

    This was seen on 2.6.34.

    Signed-off-by: Kevin Cernekee
    To: Ralf Baechle
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/1992/
    Signed-off-by: Ralf Baechle

    Kevin Cernekee
     

25 May, 2011

1 commit

  • Fold all the mmu_gather rework patches into one for submission

    Signed-off-by: Peter Zijlstra
    Reported-by: Hugh Dickins
    Cc: Benjamin Herrenschmidt
    Cc: David Miller
    Cc: Martin Schwidefsky
    Cc: Russell King
    Cc: Paul Mundt
    Cc: Jeff Dike
    Cc: Richard Weinberger
    Cc: Tony Luck
    Cc: KAMEZAWA Hiroyuki
    Cc: Mel Gorman
    Cc: KOSAKI Motohiro
    Cc: Nick Piggin
    Cc: Namhyung Kim
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Peter Zijlstra
     

15 Mar, 2011

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

01 Mar, 2010

1 commit

  • * 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
    x86, mm: Unify kernel_physical_mapping_init() API
    x86, mm: Allow highmem user page tables to be disabled at boot time
    x86: Do not reserve brk for DMI if it's not going to be used
    x86: Convert tlbstate_lock to raw_spinlock
    x86: Use the generic page_is_ram()
    x86: Remove BIOS data range from e820
    Move page_is_ram() declaration to mm.h
    Generic page_is_ram: use __weak
    resources: introduce generic page_is_ram()

    Linus Torvalds
     

27 Feb, 2010

2 commits

  • The SmartMIPS ASE specifies how Read Inhibit (RI) and eXecute Inhibit
    (XI) bits in the page tables work. The upper two bits of EntryLo{0,1}
    are RI and XI when the feature is enabled in the PageGrain register.
    SmartMIPS only covers 32-bit systems. Cavium Octeon+ extends this to
    64-bit systems by continuing to place the RI and XI bits in the top of
    EntryLo even when EntryLo is 64-bits wide.

    Because we need to carry the RI and XI bits in the PTE, the layout of
    the PTE is changed. There is a two instruction overhead in the TLB
    refill hot path to get the EntryLo bits into the proper position.
    Also the TLB load exception has to probe the TLB to check if RI or XI
    caused the exception.

    Also of note is that the layout of the PTE bits is done at compile and
    runtime rather than statically. In the 32-bit case this allows for
    the same number of PFN bits as before the patch as the _PAGE_HUGE is
    not supported in 32-bit kernels (we have _PAGE_NO_EXEC and
    _PAGE_NO_READ instead of _PAGE_READ and _PAGE_HUGE).

    The patch is tested on Cavium Octeon+, but should also work on 32-bit
    systems with the Smart-MIPS ASE.

    Signed-off-by: David Daney
    To: linux-mips@linux-mips.org
    Patchwork: http://patchwork.linux-mips.org/patch/952/
    Patchwork: http://patchwork.linux-mips.org/patch/956/
    Patchwork: http://patchwork.linux-mips.org/patch/962/
    Signed-off-by: Ralf Baechle

    David Daney
     
  • For 64-bit kernels with 64KB pages and two level page tables, there are
    42 bits worth of virtual address space This is larger than the 40 bits of
    virtual address space obtained with the default 4KB Page size and three
    levels, so there are no draw backs for using two level tables with this
    configuration.

    Signed-off-by: David Daney
    Cc: linux-mips@linux-mips.org
    Patchwork: http://patchwork.linux-mips.org/patch/761/
    Signed-off-by: Ralf Baechle

    David Daney
     

18 Feb, 2010

1 commit


02 Feb, 2010

1 commit

  • It's based on walk_system_ram_range(), for archs that don't have
    their own page_is_ram().

    The static verions in MIPS and SCORE are also made global.

    v4: prefer plain 1 instead of PAGE_IS_RAM (H. Peter Anvin)
    v3: add comment (KAMEZAWA Hiroyuki)
    "AFAIK, this "System RAM" information has been used for kdump to
    grab valid memory area and seems good for the kernel itself."
    v2: add PAGE_IS_RAM macro (Américo Wang)

    Cc: Chen Liqin
    Cc: Lennox Wu
    Cc: Américo Wang
    Cc: linux-mips@linux-mips.org
    Cc: Yinghai Lu
    Acked-by: Ralf Baechle
    Reviewed-by: KAMEZAWA Hiroyuki
    Signed-off-by: Wu Fengguang
    LKML-Reference:
    Cc: Andrew Morton
    Signed-off-by: H. Peter Anvin

    Wu Fengguang
     

12 Jan, 2010

1 commit

  • Makes it consistent with the extern declaration, used when CONFIG_HIGHMEM
    is set Removes redundant casts in printout messages

    Signed-off-by: Andreas Fenkart
    Acked-by: Russell King
    Cc: Ralf Baechle
    Cc: David Howells
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: "H. Peter Anvin"
    Cc: Chen Liqin
    Cc: Lennox Wu
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andreas Fenkart
     

17 Dec, 2009

1 commit

  • Processors that support the mips64r2 ISA can in four instructions
    convert a shifted PGD pointer stored in the upper bits of c0_context
    into a usable pointer. By doing this we save a memory load and
    associated potential cache miss in the TLB exception handlers.

    Since the upper bits of c0_context were holding the CPU number, we
    move this to the upper bits of c0_xcontext which doesn't have enough
    bits to hold the PGD pointer, but has plenty for the CPU number.

    Signed-off-by: David Daney
    Signed-off-by: Ralf Baechle

    David Daney
     

02 Nov, 2009

1 commit

  • On an SMP system with cache aliases, the following sequence of events may
    happen:

    1) copy_user_highpage() runs on CPU0, invoking kmap_coherent() to create a
    temporary mapping in the fixmap region
    2) copy_page() starts on CPU0
    3) CPU1 sends CPU0 an IPI asking CPU0 to run local_r4k_flush_cache_page()
    4) CPU0 takes the interrupt, interrupting copy_page()
    5) local_r4k_flush_cache_page() on CPU0 calls kmap_coherent() again
    6) The second invocation of kmap_coherent() on CPU0 tries to use the
    same fixmap virtual address that was being used by copy_user_highpage()
    7) CPU0 throws a machine check exception for the TLB address conflict

    Fixed by creating an extra set of fixmap entries for use in interrupt
    handlers. This prevents fixmap VA conflicts between copy_user_highpage()
    running in user context, and local_r4k_flush_cache_page() invoked from an
    SMP IPI.

    Signed-off-by: Kevin Cernekee
    Signed-off-by: Ralf Baechle

    Kevin Cernekee
     

23 Sep, 2009

3 commits

  • For /proc/kcore, each arch registers its memory range by kclist_add().
    In usual,

    - range of physical memory
    - range of vmalloc area
    - text, etc...

    are registered but "range of physical memory" has some troubles. It
    doesn't updated at memory hotplug and it tend to include unnecessary
    memory holes. Now, /proc/iomem (kernel/resource.c) includes required
    physical memory range information and it's properly updated at memory
    hotplug. Then, it's good to avoid using its own code(duplicating
    information) and to rebuild kclist for physical memory based on
    /proc/iomem.

    Signed-off-by: KAMEZAWA Hiroyuki
    Signed-off-by: Jiri Slaby
    Cc: Ralf Baechle
    Cc: Benjamin Herrenschmidt
    Cc: WANG Cong
    Cc: KOSAKI Motohiro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KAMEZAWA Hiroyuki
     
  • For /proc/kcore, vmalloc areas are registered per arch. But, all of them
    registers same range of [VMALLOC_START...VMALLOC_END) This patch unifies
    them. By this. archs which have no kclist_add() hooks can see vmalloc
    area correctly.

    Signed-off-by: KAMEZAWA Hiroyuki
    Cc: Ralf Baechle
    Cc: Benjamin Herrenschmidt
    Cc: WANG Cong
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KAMEZAWA Hiroyuki
     
  • Presently, kclist_add() only eats start address and size as its arguments.
    Considering to make kclist dynamically reconfigulable, it's necessary to
    know which kclists are for System RAM and which are not.

    This patch add kclist types as
    KCORE_RAM
    KCORE_VMALLOC
    KCORE_TEXT
    KCORE_OTHER

    This "type" is used in a patch following this for detecting KCORE_RAM.

    Signed-off-by: KAMEZAWA Hiroyuki
    Cc: Ralf Baechle
    Cc: Benjamin Herrenschmidt
    Cc: WANG Cong
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KAMEZAWA Hiroyuki
     

22 Sep, 2009

1 commit

  • Commit 96177299416dbccb73b54e6b344260154a445375 ("Drop free_pages()")
    modified nr_free_pages() to return 'unsigned long' instead of 'unsigned
    int'. This made the casts to 'unsigned long' in most callers superfluous,
    so remove them.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Geert Uytterhoeven
    Reviewed-by: Christoph Lameter
    Acked-by: Ingo Molnar
    Acked-by: Russell King
    Acked-by: David S. Miller
    Acked-by: Kyle McMartin
    Acked-by: WANG Cong
    Cc: Richard Henderson
    Cc: Ivan Kokshaysky
    Cc: Haavard Skinnemoen
    Cc: Mikael Starvik
    Cc: "Luck, Tony"
    Cc: Hirokazu Takata
    Cc: Ralf Baechle
    Cc: David Howells
    Acked-by: Benjamin Herrenschmidt
    Cc: Martin Schwidefsky
    Cc: Paul Mundt
    Cc: Chris Zankel
    Cc: Michal Simek
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Geert Uytterhoeven
     

18 Sep, 2009

1 commit

  • By combining swapper_pg_dir and module_pg_dir, several if conditions
    can be eliminated from the tlb exception handler. The reason they
    can be combined is that, the effective virtual address of vmalloc
    returned is at the bottom, and of module_alloc returned is at the
    top. It also fixes the bug in vmalloc(), which happens when its
    return address is not covered by the first pgd.

    Signed-off-by: Wu Fei
    Signed-off-by: Ralf Baechle

    Wu Fei
     

25 Jun, 2009

1 commit


14 May, 2009

1 commit

  • Commit 351336929ccf222ae38ff0cb7a8dd5fd5c6236a0 (kernel.org) rsp.
    b3594a089f1c17ff919f8f78505c3f20e1f6f8ce (linux-mips.org):

    > From: Chris Dearman
    > Date: Wed, 19 Sep 2007 00:58:24 +0100
    > Subject: [PATCH] [MIPS] Allow setting of the cache attribute at run time.
    >
    > Slightly tacky, but there is a precedent in the sparc archirecture code.

    introduces the variable _page_cachable_default, which defaults to zero and.
    is used to create the prototype PTE for __kmap_atomic in
    arch/mips/mm/init.c:kmap_init before initialization in
    arch/mips/mm/c-r4k.c:coherency_setup, so the default value of 0 will be
    used as the CCA of kmap atomic pages which on many processors is not a
    defined CCA value and may result in writes to kmap_atomic pages getting
    corrupted. Debugged by Jon Fraser (jfraser@broadcom.com).

    Signed-off-by: Ralf Baechle

    Ralf Baechle
     

30 Mar, 2009

1 commit


16 Jun, 2008

1 commit


29 Apr, 2008

5 commits


20 Feb, 2008

1 commit


27 Nov, 2007

1 commit

  • Sibyte SOCs only have 32-bit PCI. Due to the sparse use of the address
    space only the first 1GB of memory is mapped at physical addresses
    below 1GB. If a system has more than 1GB of memory 32-bit DMA will
    not be able to reach all of it.

    For now this patch is good enough to keep Sibyte users happy but it seems
    eventually something like swiotlb will be needed for Sibyte.

    Signed-off-by: Ralf Baechle

    Ralf Baechle
     

16 Nov, 2007

1 commit


17 Oct, 2007

1 commit

  • Turns out b868868ae0f7272228c95cc760338ffe35bb739d wasn't quite right.
    When called for a page that isn't marked dirty it would artificially
    create an alias instead of doing the obvious thing and access the page
    via KSEG0.

    The same issue also exists in copy_to_user_page and copy_from_user_page
    which was causing the machine to die under rare circumstances for example
    when running ps if the BUG_ON() assertion added by the earlier fix was
    getting triggered.

    Signed-off-by: Ralf Baechle

    Ralf Baechle
     

12 Sep, 2007

1 commit

  • Copy_user_highpage was written assuming it was only being called for
    breaking COW pages in which case the source page isn't cached as in
    marked cachable under it kernel virtual address. If it is called anyway
    the aliasing avoidance strategy implemented by kmap_coherent will fail.
    Avoid the use of kmap_coherent for pages marked dirty and to avoid
    another instance of this sort of bug, place a BUG_ON in kmap_coherent.

    Signed-off-by: Ralf Baechle

    Ralf Baechle
     

27 Aug, 2007

1 commit


24 Jul, 2007

1 commit

  • > WARNING: vmlinux.o(.text+0xbf20): Section mismatch: reference to
    > .init.text:prom_free_prom_memory (between 'free_initmem' and 'copy_from_user_page')

    prom_free_prom_memory() is called _before_ freeing init sections, so
    it is false positive. __init_refok can be used for such cases.

    Signed-off-by: Atsushi Nemoto
    Signed-off-by: Ralf Baechle

    Atsushi Nemoto
     

11 May, 2007

1 commit


27 Apr, 2007

2 commits


25 Mar, 2007

2 commits