linux-stable.git/arch/mips/include/asm/pgtable-64.h, branch linux-4.2.y

MIPS: Expand __swp_offset() to carry 40 significant bits for 64-bit kernel.

2015-04-01T15:21:59+00:00

With CONFIG_MIGRATION, the PFN of the migrating pages is stored in
__swp_offset(), so we must have enough bits to store the largest
possible PFN.  OCTEON NUMA systems have 41 bits of physical address
space, so with 4K pages (12-bits), we need at least 29 bits to store
the PFN.

The current width of 24-bits is too narrow, so expand it all the way
out to 40-bits.  This leaves the low order 16 bits as zero which does
not interfere with any of the PTE bits.

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

mips: drop _PAGE_FILE and pte_file()-related helpers

2015-02-10T22:30:32+00:00

We've replaced remap_file_pages(2) implementation with emulation.  Nobody
creates non-linear mapping anymore.

Signed-off-by: Kirill A. Shutemov 
Cc: Ralf Baechle 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

MIPS: Whitespace cleanup.

2013-02-01T09:00:22+00:00

Having received another series of whitespace patches I decided to do this
once and for all rather than dealing with this kind of patches trickling
in forever.

Signed-off-by: Ralf Baechle

MIPS: Fix build failure by adding definition of pfn_pmd().

2013-01-23T10:56:44+00:00

With CONFIG_TRANSPARENT_HUGEPAGE=y and CONFIG_HUGETLBFS=y we get the
following build failure:

  CC      mm/huge_memory.o
mm/huge_memory.c: In function 'set_huge_zero_page':
mm/huge_memory.c:780:2: error: implicit declaration of function 'pfn_pmd' [-Werror=implicit-function-declaration]
mm/huge_memory.c:780:8: error: incompatible types when assigning to type 'pmd_t' from type 'int'

Add a definition of pfn_pmd() for 64-bit kernels (the only place huge
pages are currently supported).

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

MIPS: Transparent Huge Pages support

2012-12-12T15:48:52+00:00

Signed-off-by: Ralf Baechle

MIPS: Hugetlbfs: Handle huge pages correctly in pmd_bad()

2012-10-16T23:01:12+00:00

Signed-off-by: Ralf Baechle

MIPS: Remove unused empty_bad_pmd_table[] declaration.

2012-10-11T09:14:12+00:00

Signed-off-by: Ralf Baechle

MIPS: Make TASK_SIZE reflect proper size for both 32 and 64 bit processes.

2010-10-29T18:08:53+00:00

The TASK_SIZE macro should reflect the size of a user process virtual
address space.  Previously for 64-bit kernels, this was not the case.
The immediate cause of pain was in
hugetlbfs/inode.c:hugetlb_get_unmapped_area() where 32-bit processes
trying to mmap a huge page would be served a page with an address
outside of the 32-bit address range.  But there are other uses of
TASK_SIZE in the kernel as well that would like an accurate value.

The new definition is nice because it now makes TASK_SIZE and
TASK_SIZE_OF() yield the same value for any given process.

For 32-bit kernels there should be no change, although I did factor
out some code in asm/processor.h that became identical for the 32-bit and
64-bit cases.

__UA_LIMIT is now set to ~((1 << SEGBITS) - 1) for 64-bit kernels.
This should eliminate the possibility of getting a
AddressErrorException in the kernel for addresses that pass the
access_ok() test.

With the patch applied, I can still run o32, n32 and n64 processes,
and have an o32 shell fork/exec both n32 and n64 processes.

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

mm: remove pte_*map_nested()

2010-10-26T23:52:08+00:00

Since we no longer need to provide KM_type, the whole pte_*map_nested()
API is now redundant, remove it.

Signed-off-by: Peter Zijlstra 
Acked-by: Chris Metcalf 
Cc: David Howells 
Cc: Hugh Dickins 
Cc: Rik van Riel 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: "H. Peter Anvin" 
Cc: Steven Rostedt 
Cc: Russell King 
Cc: Ralf Baechle 
Cc: David Miller 
Cc: Paul Mackerras 
Cc: Benjamin Herrenschmidt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

MIPS: Don't vmap things at address zero.

2010-04-30T19:52:41+00:00

In the 64-bit kernel we use swapper_pg_dir for three different things.

1) xuseg mappings for kernel threads.

2) vmap mappings for all kernel-space accesses in xkseg.

3) vmap mappings for kernel modules in ksseg (kseg2).

Due to how the TLB refill handlers work, any mapping established in
xkseg or ksseg will also establish a xuseg mapping that should never
be used by the kernel.

In order to be able to use exceptions to trap NULL pointer
dereferences, we need to ensure that nothing is mapped at address
zero.  Since vmap mappings in xkseg are reflected in xuseg, this means
we need to ensure that there are no vmap mappings established at the
start of xkseg.  So we move back VMALLOC_START to avoid establishing
vmap mappings at the start of xkseg.

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