kernel/git/stable/linux-stable.git/arch/tile/mm, branch linux-3.16.y

tile: drop pte_file()-related helpers

2018-10-03T03:09:57+00:00

commit eb12f4872a3845a8803f689646dea5b92a30aff7 upstream. We've replaced remap_file_pages(2) implementation with emulation. Nobody creates non-linear mapping anymore. Signed-off-by: Kirill A. Shutemov Acked-by: Chris Metcalf Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings

mm: larger stack guard gap, between vmas

2017-07-02T16:13:02+00:00

commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream. Stack guard page is a useful feature to reduce a risk of stack smashing into a different mapping. We have been using a single page gap which is sufficient to prevent having stack adjacent to a different mapping. But this seems to be insufficient in the light of the stack usage in userspace. E.g. glibc uses as large as 64kB alloca() in many commonly used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX] which is 256kB or stack strings with MAX_ARG_STRLEN. This will become especially dangerous for suid binaries and the default no limit for the stack size limit because those applications can be tricked to consume a large portion of the stack and a single glibc call could jump over the guard page. These attacks are not theoretical, unfortunatelly. Make those attacks less probable by increasing the stack guard gap to 1MB (on systems with 4k pages; but make it depend on the page size because systems with larger base pages might cap stack allocations in the PAGE_SIZE units) which should cover larger alloca() and VLA stack allocations. It is obviously not a full fix because the problem is somehow inherent, but it should reduce attack space a lot. One could argue that the gap size should be configurable from userspace, but that can be done later when somebody finds that the new 1MB is wrong for some special case applications. For now, add a kernel command line option (stack_guard_gap) to specify the stack gap size (in page units). Implementation wise, first delete all the old code for stack guard page: because although we could get away with accounting one extra page in a stack vma, accounting a larger gap can break userspace - case in point, a program run with "ulimit -S -v 20000" failed when the 1MB gap was counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK and strict non-overcommit mode. Instead of keeping gap inside the stack vma, maintain the stack guard gap as a gap between vmas: using vm_start_gap() in place of vm_start (or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few places which need to respect the gap - mainly arch_get_unmapped_area(), and and the vma tree's subtree_gap support for that. Original-patch-by: Oleg Nesterov Original-patch-by: Michal Hocko Signed-off-by: Hugh Dickins Acked-by: Michal Hocko Tested-by: Helge Deller # parisc Signed-off-by: Linus Torvalds [Hugh Dickins: Backported to 3.16] Signed-off-by: Ben Hutchings

vm: add VM_FAULT_SIGSEGV handling support

2015-02-04T10:58:27+00:00

commit 33692f27597fcab536d7cbbcc8f52905133e4aa7 upstream. The core VM already knows about VM_FAULT_SIGBUS, but cannot return a "you should SIGSEGV" error, because the SIGSEGV case was generally handled by the caller - usually the architecture fault handler. That results in lots of duplication - all the architecture fault handlers end up doing very similar "look up vma, check permissions, do retries etc" - but it generally works. However, there are cases where the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV. In particular, when accessing the stack guard page, libsigsegv expects a SIGSEGV. And it usually got one, because the stack growth is handled by that duplicated architecture fault handler. However, when the generic VM layer started propagating the error return from the stack expansion in commit fee7e49d4514 ("mm: propagate error from stack expansion even for guard page"), that now exposed the existing VM_FAULT_SIGBUS result to user space. And user space really expected SIGSEGV, not SIGBUS. To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those duplicate architecture fault handlers about it. They all already have the code to handle SIGSEGV, so it's about just tying that new return value to the existing code, but it's all a bit annoying. This is the mindless minimal patch to do this. A more extensive patch would be to try to gather up the mostly shared fault handling logic into one generic helper routine, and long-term we really should do that cleanup. Just from this patch, you can generally see that most architectures just copied (directly or indirectly) the old x86 way of doing things, but in the meantime that original x86 model has been improved to hold the VM semaphore for shorter times etc and to handle VM_FAULT_RETRY and other "newer" things, so it would be a good idea to bring all those improvements to the generic case and teach other architectures about them too. Reported-and-tested-by: Takashi Iwai Tested-by: Jan Engelhardt Acked-by: Heiko Carstens # "s390 still compiles and boots" Cc: linux-arch@vger.kernel.org Signed-off-by: Linus Torvalds [ luis: backported to 3.16: - file renamed: arch/powerpc/mm/copro_fault.c -> arch/powerpc/platforms/cell/spu_fault.c - dropped changes to arch/nios2/mm/fault.c ] Signed-off-by: Luis Henriques

Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile

2014-06-11T23:50:01+00:00

Pull arch/tile changes from Chris Metcalf: "These mostly just address smaller issues reported to me" * git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile: arch: tile: kernel: unaligned.c: Cleaning up uninitialized variables drivers/tty/hvc/hvc_tile.c: use PTR_ERR_OR_ZERO replace strict_strto* call with kstrto* tile: Update comments for generic idle conversion tile: cleanup the comment in init_pgprot tile: use BOOTMEM_DEFAULT instead of magic number 0 for reserve_bootmem flags

mm: page_alloc: convert hot/cold parameter and immediate callers to bool

2014-06-04T23:54:09+00:00

cold is a bool, make it one. Make the likely case the "if" part of the block instead of the else as according to the optimisation manual this is preferred. Signed-off-by: Mel Gorman Acked-by: Rik van Riel Cc: Johannes Weiner Cc: Vlastimil Babka Cc: Jan Kara Cc: Michal Hocko Cc: Hugh Dickins Cc: Dave Hansen Cc: Theodore Ts'o Cc: "Paul E. McKenney" Cc: Oleg Nesterov Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

hugetlb: restrict hugepage_migration_support() to x86_64

2014-06-04T23:53:51+00:00

Currently hugepage migration is available for all archs which support pmd-level hugepage, but testing is done only for x86_64 and there're bugs for other archs. So to avoid breaking such archs, this patch limits the availability strictly to x86_64 until developers of other archs get interested in enabling this feature. Simply disabling hugepage migration on non-x86_64 archs is not enough to fix the reported problem where sys_move_pages() hits the BUG_ON() in follow_page(FOLL_GET), so let's fix this by checking if hugepage migration is supported in vma_migratable(). Signed-off-by: Naoya Horiguchi Reported-by: Michael Ellerman Tested-by: Michael Ellerman Acked-by: Hugh Dickins Cc: Benjamin Herrenschmidt Cc: Tony Luck Cc: Russell King Cc: Martin Schwidefsky Cc: James Hogan Cc: Ralf Baechle Cc: David Miller Cc: [3.12+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

replace strict_strto* call with kstrto*

2014-05-28T19:47:16+00:00

remove obsolete calls to strict_strto* and replace them with kstrto* calls accordingly. Signed-off-by: Daniel Walter Signed-off-by: Chris Metcalf

tile: cleanup the comment in init_pgprot

2014-05-13T15:51:10+00:00

In tile vmlinux, the rodata area start after the _sdata. The rodata area is included between [_sdata, __end_rodata), and is handled at an earlier point. The page walk starts at __end_rodata, not _sdata. Signed-off-by: Wang Sheng-Hui Signed-off-by: Chris Metcalf

tile: handle pgtable_page_ctor() fail

2013-11-15T00:32:19+00:00

Signed-off-by: Kirill A. Shutemov Acked-by: Chris Metcalf Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

tile: remove HUGE_VMAP dead code

2013-09-13T15:15:24+00:00

A config option to allow a variant vmap() using huge pages that was never upstreamed had some bits of code related to it scattered around the tile architecture; the config option was removed downstream and this commit cleans up the scattered evidence of it from the upstream as well. Signed-off-by: Chris Metcalf