06 May, 2021

2 commits

  • Since CMA is getting used more widely, it's more important to keep
    monitoring CMA statistics for system health since it's directly related to
    user experience.

    This patch introduces sysfs statistics for CMA, in order to provide some
    basic monitoring of the CMA allocator.

    * the number of CMA page successful allocations
    * the number of CMA page allocation failures

    These two values allow the user to calcuate the allocation
    failure rate for each CMA area.

    e.g.)
    /sys/kernel/mm/cma/WIFI/alloc_pages_[success|fail]
    /sys/kernel/mm/cma/SENSOR/alloc_pages_[success|fail]
    /sys/kernel/mm/cma/BLUETOOTH/alloc_pages_[success|fail]

    The cma_stat was intentionally allocated by dynamic allocation
    to harmonize with kobject lifetime management.
    https://lore.kernel.org/linux-mm/YCOAmXqt6dZkCQYs@kroah.com/

    Link: https://lkml.kernel.org/r/20210324230759.2213957-1-minchan@kernel.org
    Link: https://lore.kernel.org/linux-mm/20210316100433.17665-1-colin.king@canonical.com/
    Signed-off-by: Minchan Kim
    Signed-off-by: Colin Ian King

    Tested-by: Dmitry Osipenko
    Reviewed-by: Dmitry Osipenko
    Reviewed-by: Greg Kroah-Hartman
    Reviewed-by: John Hubbard
    Tested-by: Anders Roxell
    Cc: Suren Baghdasaryan
    Cc: John Dias
    Cc: Matthew Wilcox (Oracle)
    Cc: Colin Ian King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Minchan Kim
     
  • Patch series "make hugetlb put_page safe for all calling contexts", v5.

    This effort is the result a recent bug report [1]. Syzbot found a
    potential deadlock in the hugetlb put_page/free_huge_page_path. WARNING:
    SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected Since the
    free_huge_page_path already has code to 'hand off' page free requests to a
    workqueue, a suggestion was proposed to make the in_irq() detection
    accurate by always enabling PREEMPT_COUNT [2]. The outcome of that
    discussion was that the hugetlb put_page path (free_huge_page) path should
    be properly fixed and safe for all calling contexts.

    [1] https://lore.kernel.org/linux-mm/000000000000f1c03b05bc43aadc@google.com/
    [2] http://lkml.kernel.org/r/20210311021321.127500-1-mike.kravetz@oracle.com

    This patch (of 8):

    cma_release is currently a sleepable operatation because the bitmap
    manipulation is protected by cma->lock mutex. Hugetlb code which relies
    on cma_release for CMA backed (giga) hugetlb pages, however, needs to be
    irq safe.

    The lock doesn't protect any sleepable operation so it can be changed to a
    (irq aware) spin lock. The bitmap processing should be quite fast in
    typical case but if cma sizes grow to TB then we will likely need to
    replace the lock by a more optimized bitmap implementation.

    Link: https://lkml.kernel.org/r/20210409205254.242291-1-mike.kravetz@oracle.com
    Link: https://lkml.kernel.org/r/20210409205254.242291-2-mike.kravetz@oracle.com
    Signed-off-by: Mike Kravetz
    Acked-by: Michal Hocko
    Reviewed-by: David Hildenbrand
    Acked-by: Roman Gushchin
    Cc: Shakeel Butt
    Cc: Oscar Salvador
    Cc: Muchun Song
    Cc: David Rientjes
    Cc: Miaohe Lin
    Cc: Peter Zijlstra
    Cc: Matthew Wilcox
    Cc: HORIGUCHI NAOYA
    Cc: "Aneesh Kumar K . V"
    Cc: Waiman Long
    Cc: Peter Xu
    Cc: Mina Almasry
    Cc: Hillf Danton
    Cc: Joonsoo Kim
    Cc: Barry Song
    Cc: Will Deacon
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Kravetz
     

01 Sep, 2020

1 commit

  • CMA_MAX_NAME should be visible to CMA's users as they might need it to set
    the name of CMA areas and avoid hardcoding the size locally.
    So this patch moves CMA_MAX_NAME from local header file to include/linux
    header file and removes the hardcode in both hugetlb.c and contiguous.c.

    Signed-off-by: Barry Song
    Signed-off-by: Christoph Hellwig

    Barry Song
     

13 Aug, 2020

1 commit

  • Patch series "mm: fix the names of general cma and hugetlb cma", v2.

    The current code of CMA can only work when users pass a const string as
    name parameter. we need to fix the way to handle names in CMA. On the
    other hand, to avoid name conflicts after enabling CMA_DEBUGFS, each
    hugetlb should get a different CMA name.

    This patch (of 2):

    If users give a name saved in stack, the current code will generate magic
    pointer. if users don't give a name(NULL), kasprintf() will always return
    NULL as we are at the early stage. that means cma_init_reserved_mem()
    will return -ENOMEM if users set name parameter as NULL.

    [natechancellor@gmail.com: return cma->name directly in cma_get_name]
    Link: https://github.com/ClangBuiltLinux/linux/issues/1063
    Link: http://lkml.kernel.org/r/20200623015840.621964-1-natechancellor@gmail.com

    Signed-off-by: Barry Song
    Signed-off-by: Nathan Chancellor
    Signed-off-by: Andrew Morton
    Reviewed-by: Mike Kravetz
    Acked-by: Roman Gushchin
    Link: http://lkml.kernel.org/r/20200616223131.33828-2-song.bao.hua@hisilicon.com
    Signed-off-by: Linus Torvalds

    Barry Song
     

11 Jul, 2020

1 commit

  • debugfs_create_u32_array() allocates a small structure to wrap
    the data and size information about the array. If users ever
    try to remove the file this leads to a leak since nothing ever
    frees this wrapper.

    That said there are no upstream users of debugfs_create_u32_array()
    that'd remove a u32 array file (we only have one u32 array user in
    CMA), so there is no real bug here.

    Make callers pass a wrapper they allocated. This way the lifetime
    management of the wrapper is on the caller, and we can avoid the
    potential leak in debugfs.

    CC: Chucheng Luo
    Signed-off-by: Jakub Kicinski
    Reviewed-by: Greg Kroah-Hartman
    Signed-off-by: David S. Miller

    Jakub Kicinski
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

19 Apr, 2017

1 commit


15 Aug, 2015

1 commit

  • cma_bitmap_maxno() was marked as static and not static inline, which can
    cause warnings about this function not being used if this file is included
    in a file that does not call that function, and violates the conventions
    used elsewhere. The two options are to move the function implementation
    back to mm/cma.c or make it inline here, and it's simple enough for the
    latter to make sense.

    Signed-off-by: Gregory Fong
    Cc: Joonsoo Kim
    Cc: Sasha Levin
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Gregory Fong
     

15 Apr, 2015

2 commits

  • Provides a userspace interface to trigger a CMA allocation.

    Usage:

    echo [pages] > alloc

    This would provide testing/fuzzing access to the CMA allocation paths.

    Signed-off-by: Sasha Levin
    Acked-by: Joonsoo Kim
    Cc: Marek Szyprowski
    Cc: Laura Abbott
    Cc: Konrad Rzeszutek Wilk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sasha Levin
     
  • I've noticed that there is no interfaces exposed by CMA which would let me
    fuzz what's going on in there.

    This small patchset exposes some information out to userspace, plus adds
    the ability to trigger allocation and freeing from userspace.

    This patch (of 3):

    Implement a simple debugfs interface to expose information about CMA areas
    in the system.

    Useful for testing/sanity checks for CMA since it was impossible to
    previously retrieve this information in userspace.

    Signed-off-by: Sasha Levin
    Acked-by: Joonsoo Kim
    Cc: Marek Szyprowski
    Cc: Laura Abbott
    Cc: Konrad Rzeszutek Wilk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Sasha Levin