linux.git/arch/arc/include/asm/pgtable.h, branch v4.11

arch, mm: convert all architectures to use 5level-fixup.h

2017-03-09T19:48:47+00:00

If an architecture uses 4level-fixup.h we don't need to do anything as
it includes 5level-fixup.h.

If an architecture uses pgtable-nop*d.h, define __ARCH_USE_5LEVEL_HACK
before inclusion of the header. It makes asm-generic code to use
5level-fixup.h.

If an architecture has 4-level paging or folds levels on its own,
include 5level-fixup.h directly.

Signed-off-by: Kirill A. Shutemov 
Acked-by: Michal Hocko 
Signed-off-by: Linus Torvalds

ARC: mm: PAE40: Fix crash at munmap

2016-11-29T17:12:08+00:00

commit 1c3c90930392 broke PAE40. Macro pfn_pte(pfn, prot) creates paddr
from pfn, but the page shift was getting truncated to 32 bits since we lost
the proper cast to 64 bits (for PAE400

Instead of reverting that commit, use a better helper which is 32/64 bits
safe just like ARM implementation.

Fixes: 1c3c90930392 ("ARC: mm: fix build breakage with STRICT_MM_TYPECHECKS")
Cc:    #4.4+
Signed-off-by: Yuriy Kolerov 
[vgupta: massaged changelog]
Signed-off-by: Vineet Gupta

ARC: mm: fix build breakage with STRICT_MM_TYPECHECKS

2016-08-19T18:04:57+00:00

|  CC      mm/memory.o
| In file included from ../mm/memory.c:53:0:
| ../include/linux/pfn_t.h: In function ‘pfn_t_pte’:
| ../include/linux/pfn_t.h:78:2: error: conversion to non-scalar type requested
|  return pfn_pte(pfn_t_to_pfn(pfn), pgprot);

With STRICT_MM_TYPECHECKS pte_t is a struct and the offending code
forces a cast which ends up shifting a struct and hence the gcc warning.

Note that in recent past some of the arches (aarch64, s390) made
STRICT_MM_TYPECHECKS default, but we don't for ARC as this leads to slightly
worse generated code, given ARC ABI definition of returning structs
(which pte_t would become)

Quoting from ARC ABI...

  "Results of type struct are returned in a caller-supplied temporary
  variable whose address is passed in r0.
  For such functions, the arguments are shifted so that they are
  passed in r1 and up."

So
 - struct to be returned would be allocated on stack requiring extra
   code at call sites
 - callee updates stack memory to facilitate the return (vs. simple
   MOV into return reg r0)

Hence STRICT_MM_TYPECHECKS is not enabled by default for ARC

Cc:    #4.4+
Signed-off-by: Vineet Gupta

ARC: mm: don't loose PTE_SPECIAL in pte_modify()

2016-07-28T19:38:17+00:00

LTP madvise05 was generating mm splat

| [ARCLinux]# /sd/ltp/testcases/bin/madvise05
| BUG: Bad page map in process madvise05  pte:80e08211 pmd:9f7d4000
| page:9fdcfc90 count:1 mapcount:-1 mapping:  (null) index:0x0 flags: 0x404(referenced|reserved)
| page dumped because: bad pte
| addr:200b8000 vm_flags:00000070 anon_vma:  (null) mapping:  (null) index:1005c
| file:  (null) fault:  (null) mmap:  (null) readpage:  (null)
| CPU: 2 PID: 6707 Comm: madvise05

And for newer kernels, the system was rendered unusable afterwards.

The problem was mprotect->pte_modify() clearing PTE_SPECIAL (which is
set to identify the special zero page wired to the pte).
When pte was finally unmapped, special casing for zero page was not
done, and instead it was treated as a "normal" page, tripping on the
map counts etc.

This fixes ARC STAR 9001053308

Cc: 
Signed-off-by: Vineet Gupta

Fix typos

2016-05-30T04:37:32+00:00

Signed-off-by: Andrea Gelmini 
Signed-off-by: Vineet Gupta

ARC: Make vmalloc size configurable

2016-05-09T04:02:32+00:00

On ARC, lower 2G of address space is translated and used for
 - user vaddr space (region 0 to 5)
 - unused kernel-user gutter (region 6)
 - kernel vaddr space (region 7)

where each region simply represents 256MB of address space.

The kernel vaddr space of 256MB is used to implement vmalloc, modules
So far this was enough, but not on EZChip system with 4K CPUs (given
that per cpu mechanism uses vmalloc for allocating chunks)

So allow VMALLOC_SIZE to be configurable by expanding down into the unused
kernel-user gutter region which at default 256M was excessive anyways.

Also use _BITUL() to fix a build error since PGDIR_SIZE cannot use "1UL"
as called from assembly code in mm/tlbex.S

Signed-off-by: Noam Camus 
[vgupta: rewrote changelog, debugged bootup crash due to int vs. hex]
Acked-by: Vineet Gupta

ARC: Fix PAE40 boot failures due to PTE truncation

2016-05-05T11:05:45+00:00

So a benign looking cleanup which macro'ized PAGE_SHIFT shifts turned
out to be bad (since it was done non-sensically across the board).

It caused boot failures with PAE40 as forced cast to (unsigned long)
from newly introduced virt_to_pfn() was causing truncatiion of the
(long long) pte/paddr values.

It is OK to use this in accessors dealing with kernel virtual address,
pointers etc, but not for PTE values themelves.

Fixes: cJ2ff5cf2735c ("ARC: mm: Use virt_to_pfn() for addr >> PAGE_SHIFT pattern)
Signed-off-by: Vineet Gupta

ARC: mm: Use virt_to_pfn() for addr >> PAGE_SHIFT pattern

2016-03-12T06:29:47+00:00

Signed-off-by: Vineet Gupta

ARC: Fix misspellings in comments.

2016-03-11T09:29:53+00:00

Signed-off-by: Adam Buchbinder 
Signed-off-by: Vineet Gupta

ARC: mm: Introduce explicit super page size support

2016-02-12T06:40:25+00:00

MMUv4 supports 2 concurrent page sizes: Normal and Super [4K to 16M]

So far Linux supported a single super page size for a given Normal page,
depending on the software page walking address split.
e.g. we had 11:8:13 address split for 8K page, which meant super page
was 2 ^(8+13) = 2M (given that THP size has to be PMD_SHIFT)

Now we turn this around, by allowing multiple Super Pages in Kconfig
(currently 2M and 16M only) and forcing page walker address split to
PGDIR_SHIFT and PAGE_SHIFT

For configs without Super page, things are same as before and
PGDIR_SHIFT can be hacked to get non default address split

The motivation for this change is a customer who needs 16M super page
and a 8K Normal page combo.

Signed-off-by: Vineet Gupta