Eric Lee / smarc-fsl-linux-kernel

07 Jul, 2017

1 commit

  • 94f4a1618   mm: kmemleak: treat vm_struct as alternative reference to vmalloc'ed objects ... Browse Code »

    Kmemleak requires that vmalloc'ed objects have a minimum reference count
    of 2: one in the corresponding vm_struct object and the other owned by
    the vmalloc() caller. There are cases, however, where the original
    vmalloc() returned pointer is lost and, instead, a pointer to vm_struct
    is stored (see free_thread_stack()). Kmemleak currently reports such
    objects as leaks.

    This patch adds support for treating any surplus references to an object
    as additional references to a specified object. It introduces the
    kmemleak_vmalloc() API function which takes a vm_struct pointer and sets
    its surplus reference passing to the actual vmalloc() returned pointer.
    The __vmalloc_node_range() calling site has been modified accordingly.

    Link: http://lkml.kernel.org/r/1495726937-23557-4-git-send-email-catalin.marinas@arm.com
    Signed-off-by: Catalin Marinas
    Reported-by: "Luis R. Rodriguez"
    Cc: Michal Hocko
    Cc: Andy Lutomirski
    Cc: "Luis R. Rodriguez"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Catalin Marinas
     

12 Oct, 2016

1 commit

  • 9099daed9   mm: kmemleak: avoid using __va() on addresses that don't have a lowmem mapping ... Browse Code »

    Some of the kmemleak_*() callbacks in memblock, bootmem, CMA convert a
    physical address to a virtual one using __va(). However, such physical
    addresses may sometimes be located in highmem and using __va() is
    incorrect, leading to inconsistent object tracking in kmemleak.

    The following functions have been added to the kmemleak API and they take
    a physical address as the object pointer. They only perform the
    corresponding action if the address has a lowmem mapping:

    kmemleak_alloc_phys
    kmemleak_free_part_phys
    kmemleak_not_leak_phys
    kmemleak_ignore_phys

    The affected calling places have been updated to use the new kmemleak
    API.

    Link: http://lkml.kernel.org/r/1471531432-16503-1-git-send-email-catalin.marinas@arm.com
    Signed-off-by: Catalin Marinas
    Reported-by: Vignesh R
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Catalin Marinas
     

13 Dec, 2015

1 commit

  • 98e89cf02   mm: kmemleak: mark kmemleak_init prototype as __init ... Browse Code »

    The kmemleak_init() definition in mm/kmemleak.c is marked __init but its
    prototype in include/linux/kmemleak.h is marked __ref since commit
    a6186d89c913 ("kmemleak: Mark the early log buffer as __initdata").

    This causes a section mismatch which is reported as a warning when
    building with clang -Wsection, because kmemleak_init() is declared in
    section .ref.text but defined in .init.text.

    Fix this by marking kmemleak_init() prototype __init.

    Signed-off-by: Nicolas Iooss
    Signed-off-by: Catalin Marinas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nicolas Iooss
     

25 Jun, 2015

1 commit

  • 8a8c35fad   mm: kmemleak_alloc_percpu() should follow the gfp from per_alloc() ... Browse Code »

    Beginning at commit d52d3997f843 ("ipv6: Create percpu rt6_info"), the
    following INFO splat is logged:

    ===============================
    [ INFO: suspicious RCU usage. ]
    4.1.0-rc7-next-20150612 #1 Not tainted
    -------------------------------
    kernel/sched/core.c:7318 Illegal context switch in RCU-bh read-side critical section!
    other info that might help us debug this:
    rcu_scheduler_active = 1, debug_locks = 0
    3 locks held by systemd/1:
    #0: (rtnl_mutex){+.+.+.}, at: [] rtnetlink_rcv+0x1f/0x40
    #1: (rcu_read_lock_bh){......}, at: [] ipv6_add_addr+0x62/0x540
    #2: (addrconf_hash_lock){+...+.}, at: [] ipv6_add_addr+0x184/0x540
    stack backtrace:
    CPU: 0 PID: 1 Comm: systemd Not tainted 4.1.0-rc7-next-20150612 #1
    Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.20 04/17/2014
    Call Trace:
    dump_stack+0x4c/0x6e
    lockdep_rcu_suspicious+0xe7/0x120
    ___might_sleep+0x1d5/0x1f0
    __might_sleep+0x4d/0x90
    kmem_cache_alloc+0x47/0x250
    create_object+0x39/0x2e0
    kmemleak_alloc_percpu+0x61/0xe0
    pcpu_alloc+0x370/0x630

    Additional backtrace lines are truncated. In addition, the above splat
    is followed by several "BUG: sleeping function called from invalid
    context at mm/slub.c:1268" outputs. As suggested by Martin KaFai Lau,
    these are the clue to the fix. Routine kmemleak_alloc_percpu() always
    uses GFP_KERNEL for its allocations, whereas it should follow the gfp
    from its callers.

    Reviewed-by: Catalin Marinas
    Reviewed-by: Kamalesh Babulal
    Acked-by: Martin KaFai Lau
    Signed-off-by: Larry Finger
    Cc: Martin KaFai Lau
    Cc: Catalin Marinas
    Cc: Tejun Heo
    Cc: Christoph Lameter
    Cc: [3.18+]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Larry Finger
     

14 Dec, 2014

1 commit

07 Jun, 2014

1 commit

  • ffe2c748e   mm: introduce kmemleak_update_trace() ... Browse Code »

    The memory allocation stack trace is not always useful for debugging a
    memory leak (e.g. radix_tree_preload). This function, when called,
    updates the stack trace for an already allocated object.

    Signed-off-by: Catalin Marinas
    Cc: Johannes Weiner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Catalin Marinas
     

04 Apr, 2014

1 commit

03 Dec, 2011

1 commit

  • f528f0b8e   kmemleak: Handle percpu memory allocation ... Browse Code »

    This patch adds kmemleak callbacks from the percpu allocator, reducing a
    number of false positives caused by kmemleak not scanning such memory
    blocks. The percpu chunks are never reported as leaks because of current
    kmemleak limitations with the __percpu pointer not pointing directly to
    the actual chunks.

    Reported-by: Huajun Li
    Acked-by: Christoph Lameter
    Acked-by: Tejun Heo
    Signed-off-by: Catalin Marinas

    Catalin Marinas
     

28 Oct, 2009

1 commit

27 Aug, 2009

1 commit

08 Jul, 2009

1 commit

  • 53238a60d   kmemleak: Allow partial freeing of memory blocks ... Browse Code »

    Functions like free_bootmem() are allowed to free only part of a memory
    block. This patch adds support for this via the kmemleak_free_part()
    callback which removes the original object and creates one or two
    additional objects as a result of the memory block split.

    Signed-off-by: Catalin Marinas
    Cc: Ingo Molnar
    Acked-by: Pekka Enberg

    Catalin Marinas
     

12 Jun, 2009

1 commit

  • 3c7b4e6b8   kmemleak: Add the base support ... Browse Code »

    This patch adds the base support for the kernel memory leak
    detector. It traces the memory allocation/freeing in a way similar to
    the Boehm's conservative garbage collector, the difference being that
    the unreferenced objects are not freed but only shown in
    /sys/kernel/debug/kmemleak. Enabling this feature introduces an
    overhead to memory allocations.

    Signed-off-by: Catalin Marinas
    Cc: Ingo Molnar
    Acked-by: Pekka Enberg
    Cc: Andrew Morton
    Reviewed-by: Paul E. McKenney

    Catalin Marinas