linux-stable.git/arch/arm/include, branch v3.10.78

ARM: 8320/1: fix integer overflow in ELF_ET_DYN_BASE

2015-05-06T19:56:21+00:00

commit 8defb3367fcd19d1af64c07792aade0747b54e0f upstream.

Usually ELF_ET_DYN_BASE is 2/3 of TASK_SIZE. With 3G/1G user/kernel
split this is not so, because 2*TASK_SIZE overflows 32 bits,
so the actual value of ELF_ET_DYN_BASE is:
	(2 * TASK_SIZE / 3) = 0x2a000000

When ASLR is disabled PIE binaries will load at ELF_ET_DYN_BASE address.
On 32bit platforms AddressSanitzer uses addresses [0x20000000 - 0x40000000]
for shadow memory [1]. So ASan doesn't work for PIE binaries when ASLR disabled
as it fails to map shadow memory.
Also after Kees's 'split ET_DYN ASLR from mmap ASLR' patchset PIE binaries
has a high chance of loading somewhere in between [0x2a000000 - 0x40000000]
even if ASLR enabled. This makes ASan with PIE absolutely incompatible.

Fix overflow by dividing TASK_SIZE prior to multiplying.
After this patch ELF_ET_DYN_BASE equals to (for CONFIG_VMSPLIT_3G=y):
	(TASK_SIZE / 3 * 2) = 0x7f555554

[1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm#Mapping

Signed-off-by: Andrey Ryabinin 
Reported-by: Maria Guseva 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 8109/1: mm: Modify pte_write and pmd_write logic for LPAE

2015-02-06T06:35:39+00:00

commit ded9477984690d026e46dd75e8157392cea3f13f upstream.

For LPAE, we have the following means for encoding writable or dirty
ptes:
                              L_PTE_DIRTY       L_PTE_RDONLY
    !pte_dirty && !pte_write        0               1
    !pte_dirty && pte_write         0               1
    pte_dirty && !pte_write         1               1
    pte_dirty && pte_write          1               0

So we can't distinguish between writeable clean ptes and read only
ptes. This can cause problems with ptes being incorrectly flagged as
read only when they are writeable but not dirty.

This patch renumbers L_PTE_RDONLY from AP[2] to a software bit #58,
and adds additional logic to set AP[2] whenever the pte is read only
or not dirty. That way we can distinguish between clean writeable ptes
and read only ptes.

HugeTLB pages will use this new logic automatically.

We need to add some logic to Transparent HugePages to ensure that they
correctly interpret the revised pgprot permissions (L_PTE_RDONLY has
moved and no longer matches PMD_SECT_AP2). In the process of revising
THP, the names of the PMD software bits have been prefixed with L_ to
make them easier to distinguish from their hardware bit counterparts.


Signed-off-by: Steve Capper 
Reviewed-by: Will Deacon 
Signed-off-by: Russell King 
[hpy: Backported to 3.10
 - adjust the context
 - ignore change related to pmd, because 3.10 does not support HugePage ]
Signed-off-by: Hou Pengyang 
Signed-off-by: Greg Kroah-Hartman

ARM: 8108/1: mm: Introduce {pte,pmd}_isset and {pte,pmd}_isclear

2015-02-06T06:35:39+00:00

commit f2950706871c4b6e8c0f0d7c3f62d35930b8de63 upstream.

Long descriptors on ARM are 64 bits, and some pte functions such as
pte_dirty return a bitwise-and of a flag with the pte value. If the
flag to be tested resides in the upper 32 bits of the pte, then we run
into the danger of the result being dropped if downcast.

For example:
	gather_stats(page, md, pte_dirty(*pte), 1);
where pte_dirty(*pte) is downcast to an int.

This patch introduces a new macro pte_isset which performs the bitwise
and, then performs a double logical invert (where needed) to ensure
predictable downcasting. The logical inverse pte_isclear is also
introduced.

Equivalent pmd functions for Transparent HugePages have also been
added.

Signed-off-by: Steve Capper 
Reviewed-by: Will Deacon 
Signed-off-by: Russell King 
[hpy: Backported to 3.10:
 - adjust the context
 - ignore change to pmd, because 3.10 does not support HugePage.]
Signed-off-by: Hou Pengyang 
Signed-off-by: Greg Kroah-Hartman

ARM: 7931/1: Correct virt_addr_valid

2015-02-06T06:35:39+00:00

commit efea3403d4b7c6d1dd5d5ac3234c161e8b314d66 upstream.

The definition of virt_addr_valid is that virt_addr_valid should
return true if and only if virt_to_page returns a valid pointer.
The current definition of virt_addr_valid only checks against the
virtual address range. There's no guarantee that just because a
virtual address falls bewteen PAGE_OFFSET and high_memory the
associated physical memory has a valid backing struct page. Follow
the example of other architectures and convert to pfn_valid to
verify that the virtual address is actually valid. The check for
an address between PAGE_OFFSET and high_memory is still necessary
as vmalloc/highmem addresses are not valid with virt_to_page.

Cc: Will Deacon 
Cc: Nicolas Pitre 
Acked-by: Will Deacon 
Signed-off-by: Laura Abbott 
Signed-off-by: Russell King 
Cc: Hou Pengyang 
Signed-off-by: Greg Kroah-Hartman

ARM: fix asm/memory.h build error

2015-02-06T06:35:39+00:00

commit b713aa0b15015a65ad5421543b80df86de043d62 upstream.

Jason Gunthorpe reports a build failure when ARM_PATCH_PHYS_VIRT is
not defined:

In file included from arch/arm/include/asm/page.h:163:0,
                 from include/linux/mm_types.h:16,
                 from include/linux/sched.h:24,
                 from arch/arm/kernel/asm-offsets.c:13:
arch/arm/include/asm/memory.h: In function '__virt_to_phys':
arch/arm/include/asm/memory.h:244:40: error: 'PHYS_OFFSET' undeclared (first use in this function)
arch/arm/include/asm/memory.h:244:40: note: each undeclared identifier is reported only once for each function it appears in
arch/arm/include/asm/memory.h: In function '__phys_to_virt':
arch/arm/include/asm/memory.h:249:13: error: 'PHYS_OFFSET' undeclared (first use in this function)

Fixes: ca5a45c06cd4 ("ARM: mm: use phys_addr_t appropriately in p2v and v2p conversions")
Tested-By: Jason Gunthorpe 
Signed-off-by: Russell King 
[hpy: Backported to 3.10:
 - adjust the context
 - MPU is not supported by 3.10, so ignore fix to MPU compared with the original patch.]
Signed-off-by: Hou Pengyang 
Signed-off-by: Greg Kroah-Hartman

ARM: 7867/1: include: asm: use 'int' instead of 'unsigned long' for 'oldval' in atomic_cmpxchg().

2015-02-06T06:35:38+00:00

commit 4dcc1cf7316a26e112f5c9fcca531ff98ef44700 upstream.

For atomic_cmpxchg(), the type of 'oldval' need be 'int' to match the
type of "*ptr" (used by 'ldrex' instruction) and 'old' (used by 'teq'
instruction).

Reviewed-by: Will Deacon 
Signed-off-by: Chen Gang 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Cc: Hou Pengyang 
Signed-off-by: Greg Kroah-Hartman

ARM: 7866/1: include: asm: use 'long long' instead of 'u64' within atomic.h

2015-02-06T06:35:38+00:00

commit 237f12337cfa2175474e4dd015bc07a25eb9080d upstream.

atomic* value is signed value, and atomic* functions need also process
signed value (parameter value, and return value), so 32-bit arm need
use 'long long' instead of 'u64'.

After replacement, it will also fix a bug for atomic64_add_negative():
"u64 is never less than 0".

The modifications are:

  in vim, use "1,% s/\/long long/g" command.
  remove '__aligned(8)' which is useless for 64-bit.
  be sure of 80 column limitation after replacement.

Acked-by: Will Deacon 
Signed-off-by: Chen Gang 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Cc: Hou Pengyang 
Signed-off-by: Greg Kroah-Hartman

ARM: lpae: fix definition of PTE_HWTABLE_PTRS

2015-02-06T06:35:38+00:00

commit e38a517578d6c0f764b0d0f6e26dcdf9f70c69d7 upstream.

For 2-level page tables, PTE_HWTABLE_PTRS describes the offset between
Linux PTEs and hardware PTEs. On LPAE, there is no distinction (since
we have 64-bit descriptors with plenty of space) so PTE_HWTABLE_PTRS
should be 0. Unfortunately, it is wrongly defined as PTRS_PER_PTE,
meaning that current pte table flushing is off by a page. Luckily,
all current LPAE implementations are SMP, so the hardware walker can
snoop L1.

This patch fixes the broken definition.

Acked-by: Catalin Marinas 
Signed-off-by: Will Deacon 
Cc: Hou Pengyang 
Signed-off-by: Greg Kroah-Hartman

ARM: fix type of PHYS_PFN_OFFSET to unsigned long

2015-02-06T06:35:38+00:00

commit 5b20c5b2f014ecc0a6310988af69cd7ede9e7c67 upstream.

On LPAE machines, PHYS_OFFSET evaluates to a phys_addr_t and this type is
inherited by the PHYS_PFN_OFFSET definition as well.  Consequently, the kernel
build emits warnings of the form:

init/main.c: In function 'start_kernel':
init/main.c:588:7: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'phys_addr_t' [-Wformat]

This patch fixes this warning by pinning down the PFN type to unsigned long.

Signed-off-by: Cyril Chemparathy 
Acked-by: Nicolas Pitre 
Tested-by: Santosh Shilimkar 
Tested-by: Subash Patel 
Signed-off-by: Will Deacon 
Cc: Hou Pengyang 
Signed-off-by: Greg Kroah-Hartman

ARM: LPAE: use signed arithmetic for mask definitions

2015-02-06T06:35:38+00:00

commit 926edcc747e2efb3c9add7ed4dbc4e7a3a959d02 upstream.

This patch applies to PAGE_MASK, PMD_MASK, and PGDIR_MASK, where forcing
unsigned long math truncates the mask at the 32-bits.  This clearly does bad
things on PAE systems.

This patch fixes this problem by defining these masks as signed quantities.
We then rely on sign extension to do the right thing.

Signed-off-by: Cyril Chemparathy 
Signed-off-by: Vitaly Andrianov 
Reviewed-by: Nicolas Pitre 
Reviewed-by: Catalin Marinas 
Tested-by: Santosh Shilimkar 
Tested-by: Subash Patel 
Signed-off-by: Will Deacon 
Cc: Hou Pengyang 
Signed-off-by: Greg Kroah-Hartman