linux-toradex.git/include/linux/poison.h, branch v4.14-rc5

locking/mutex: Initialize mutex_waiter::ww_ctx with poison when debugging

2017-01-14T10:14:53+00:00

Help catch cases where mutex_lock is used directly on w/w mutexes, which
otherwise result in the w/w tasks reading uninitialized data.

Signed-off-by: Nicolai Hähnle 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Andrew Morton 
Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Linus Torvalds 
Cc: Maarten Lankhorst 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: dri-devel@lists.freedesktop.org
Link: http://lkml.kernel.org/r/1482346000-9927-12-git-send-email-nhaehnle@gmail.com
Signed-off-by: Ingo Molnar

mm/page_poisoning.c: allow for zero poisoning

2016-03-15T23:55:16+00:00

By default, page poisoning uses a poison value (0xaa) on free.  If this
is changed to 0, the page is not only sanitized but zeroing on alloc
with __GFP_ZERO can be skipped as well.  The tradeoff is that detecting
corruption from the poisoning is harder to detect.  This feature also
cannot be used with hibernation since pages are not guaranteed to be
zeroed after hibernation.

Credit to Grsecurity/PaX team for inspiring this work

Signed-off-by: Laura Abbott 
Acked-by: Rafael J. Wysocki 
Cc: "Kirill A. Shutemov" 
Cc: Vlastimil Babka 
Cc: Michal Hocko 
Cc: Kees Cook 
Cc: Mathias Krause 
Cc: Dave Hansen 
Cc: Jianyu Zhan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

include/linux/poison.h: use POISON_POINTER_DELTA for poison pointers

2016-01-16T19:17:22+00:00

TIMER_ENTRY_STATIC and TAIL_MAPPING are defined as poison pointers which
should point to nowhere.  Redefine them using POISON_POINTER_DELTA
arithmetics to make sure they really point to non-mappable area declared
by the target architecture.

Signed-off-by: Vasily Kulikov 
Acked-by: Thomas Gleixner 
Cc: Solar Designer 
Cc: "Kirill A. Shutemov" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: sanitize page->mapping for tail pages

2016-01-16T01:56:32+00:00

We don't define meaning of page->mapping for tail pages.  Currently it's
always NULL, which can be inconsistent with head page and potentially
lead to problems.

Let's poison the pointer to catch all illigal uses.

page_rmapping(), page_mapping() and page_anon_vma() are changed to look
on head page.

The only illegal use I've caught so far is __GPF_COMP pages from sound
subsystem, mapped with PTEs.  do_shared_fault() is changed to use
page_rmapping() instead of direct access to fault_page->mapping.

Signed-off-by: Kirill A. Shutemov 
Reviewed-by: Jérôme Glisse 
Cc: Andrea Arcangeli 
Cc: Hugh Dickins 
Cc: Dave Hansen 
Cc: Mel Gorman 
Cc: Rik van Riel 
Cc: Vlastimil Babka 
Cc: Christoph Lameter 
Cc: Naoya Horiguchi 
Cc: Steve Capper 
Cc: "Aneesh Kumar K.V" 
Cc: Johannes Weiner 
Cc: Michal Hocko 
Cc: Jerome Marchand 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

include/linux/poison.h: remove not-used poison pointer macros

2015-09-10T20:29:01+00:00

Signed-off-by: Vasily Kulikov 
Cc: Solar Designer 
Cc: Thomas Gleixner 
Cc: "Kirill A. Shutemov" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

include/linux/poison.h: fix LIST_POISON{1,2} offset

2015-09-10T20:29:01+00:00

Poison pointer values should be small enough to find a room in
non-mmap'able/hardly-mmap'able space.  E.g.  on x86 "poison pointer space"
is located starting from 0x0.  Given unprivileged users cannot mmap
anything below mmap_min_addr, it should be safe to use poison pointers
lower than mmap_min_addr.

The current poison pointer values of LIST_POISON{1,2} might be too big for
mmap_min_addr values equal or less than 1 MB (common case, e.g.  Ubuntu
uses only 0x10000).  There is little point to use such a big value given
the "poison pointer space" below 1 MB is not yet exhausted.  Changing it
to a smaller value solves the problem for small mmap_min_addr setups.

The values are suggested by Solar Designer:
http://www.openwall.com/lists/oss-security/2015/05/02/6

Signed-off-by: Vasily Kulikov 
Cc: Solar Designer 
Cc: Thomas Gleixner 
Cc: "Kirill A. Shutemov" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memblock: Kill sentinel entries at the end of static region arrays

2011-12-08T18:22:07+00:00

memblock no longer depends on having one more entry at the end during
addition making the sentinel entries at the end of region arrays not
too useful.  Remove the sentinels.  This eases further updates.

Signed-off-by: Tejun Heo 
Cc: Benjamin Herrenschmidt 
Cc: Yinghai Lu

mm/memblock.c: avoid abuse of RED_INACTIVE

2011-07-26T03:57:09+00:00

RED_INACTIVE is a slab thing, and reusing it for memblock was
inappropriate, because memblock is dealing with phys_addr_t's which have a
Kconfigurable sizeof().

Create a new poison type for this application.  Fixes the sparse warning

    warning: cast truncates bits from constant value (9f911029d74e35b becomes 9d74e35b)

Reported-by: H Hartley Sweeten 
Tested-by: H Hartley Sweeten 
Acked-by: Pekka Enberg 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

hugetlb, rmap: add reverse mapping for hugepage

2010-08-11T07:21:15+00:00

This patch adds reverse mapping feature for hugepage by introducing
mapcount for shared/private-mapped hugepage and anon_vma for
private-mapped hugepage.

While hugepage is not currently swappable, reverse mapping can be useful
for memory error handler.

Without this patch, memory error handler cannot identify processes
using the bad hugepage nor unmap it from them. That is:
- for shared hugepage:
  we can collect processes using a hugepage through pagecache,
  but can not unmap the hugepage because of the lack of mapcount.
- for privately mapped hugepage:
  we can neither collect processes nor unmap the hugepage.
This patch solves these problems.

This patch include the bug fix given by commit 23be7468e8, so reverts it.

Dependency:
  "hugetlb: move definition of is_vm_hugetlb_page() to hugepage_inline.h"

ChangeLog since May 24.
- create hugetlb_inline.h and move is_vm_hugetlb_index() in it.
- move functions setting up anon_vma for hugepage into mm/rmap.c.

ChangeLog since May 13.
- rebased to 2.6.34
- fix logic error (in case that private mapping and shared mapping coexist)
- move is_vm_hugetlb_page() into include/linux/mm.h to use this function
  from linear_page_index()
- define and use linear_hugepage_index() instead of compound_order()
- use page_move_anon_rmap() in hugetlb_cow()
- copy exclusive switch of __set_page_anon_rmap() into hugepage counterpart.
- revert commit 24be7468 completely

Signed-off-by: Naoya Horiguchi 
Cc: Andi Kleen 
Cc: Andrew Morton 
Cc: Mel Gorman 
Cc: Andrea Arcangeli 
Cc: Larry Woodman 
Cc: Lee Schermerhorn 
Acked-by: Fengguang Wu 
Acked-by: Mel Gorman 
Signed-off-by: Andi Kleen

hugetlb: fix infinite loop in get_futex_key() when backed by huge pages

2010-04-24T18:31:25+00:00

If a futex key happens to be located within a huge page mapped
MAP_PRIVATE, get_futex_key() can go into an infinite loop waiting for a
page->mapping that will never exist.

See https://bugzilla.redhat.com/show_bug.cgi?id=552257 for more details
about the problem.

This patch makes page->mapping a poisoned value that includes
PAGE_MAPPING_ANON mapped MAP_PRIVATE.  This is enough for futex to
continue but because of PAGE_MAPPING_ANON, the poisoned value is not
dereferenced or used by futex.  No other part of the VM should be
dereferencing the page->mapping of a hugetlbfs page as its page cache is
not on the LRU.

This patch fixes the problem with the test case described in the bugzilla.

[akpm@linux-foundation.org: mel cant spel]
Signed-off-by: Mel Gorman 
Acked-by: Peter Zijlstra 
Acked-by: Darren Hart 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds