linux.git/mm/cma_debug.c, branch v6.6.131

mm/cma_debug: show complete cma name in debugfs directories

2022-09-12T03:25:50+00:00

Currently only 12 characters of the cma name is being used as the debug
directories where as the cma name can be of length CMA_MAX_NAME(=64)
characters.  One side problem with this is having 2 cma's with first
common 12 characters would end up in trying to create directories with
same name and fails with -EEXIST thus can limit cma debug functionality.

The 'cma-' prefix is used initially where cma areas don't have any names
and are represented by simple integer values.  Since now each cma would be
having its own name, drop 'cma-' prefix for the cma debug directories as
they are clearly evident that they are for cma debug through creating them
in /sys/kernel/debug/cma/ path.

Link: https://lkml.kernel.org/r/1660223729-22461-1-git-send-email-quic_charante@quicinc.com
Signed-off-by: Charan Teja Kalla 
Cc: David Hildenbrand 
Cc: Vlastimil Babka 
Cc: Pavan Kondeti 
Cc: Minchan Kim 
Signed-off-by: Andrew Morton

mm/cma_debug.c: align the name buffer length as struct cma

2022-07-30T01:07:16+00:00

Avoids truncating the debugfs output to 16 chars.  Potentially alters
the userspace output, but this is a debugfs interface and there are no
stability guarantees.

Link: https://lkml.kernel.org/r/20220719091554.27864-1-quic_yingangl@quicinc.com
Signed-off-by: Kassey Li 
Cc: Sasha Levin 
Cc: Joonsoo Kim 
Cc: Minchan Kim 
Signed-off-by: Andrew Morton

mm/cma: change cma mutex to irq safe spinlock

2021-05-05T18:27:21+00:00

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

debugfs: make sure we can remove u32_array files cleanly

2020-07-10T20:54:00+00:00

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

mm/cma_debug.c: use DEFINE_DEBUGFS_ATTRIBUTE to define debugfs fops

2019-12-01T20:59:09+00:00

It is more clear to use DEFINE_DEBUGFS_ATTRIBUTE to define debugfs file
operation rather than DEFINE_SIMPLE_ATTRIBUTE.

Link: http://lkml.kernel.org/r/1572348687-9951-1-git-send-email-zhongjiang@huawei.com
Signed-off-by: zhong jiang 
Reviewed-by: Andrew Morton 
Cc: Yue Hu 
Cc: Greg Kroah-Hartman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/cma_debug.c: fix the break condition in cma_maxchunk_get()

2019-05-14T16:47:45+00:00

If not find zero bit in find_next_zero_bit(), it will return the size
parameter passed in, so the start bit should be compared with bitmap_maxno
rather than cma->count.  Although getting maxchunk is working fine due to
zero value of order_per_bit currently, the operation will be stuck if
order_per_bit is set as non-zero.

Link: http://lkml.kernel.org/r/20190319092734.276-1-zbestahu@gmail.com
Signed-off-by: Yue Hu 
Reviewed-by: Andrew Morton 
Cc: Michal Hocko 
Cc: Joe Perches 
Cc: David Rientjes 
Cc: Dmitry Safonov 
Cc: Joonsoo Kim 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/cma_debug.c: remove static scoped cma_debugfs_root

2019-03-06T05:07:20+00:00

Currently cma_debugfs_root is static storage.  That is unnecessary since
it will be only used by next cma_debugfs_add_one().  We can just pass it
to following calling to save thisspace.  Also remove useless idx
parameter.

Link: http://lkml.kernel.org/r/20190221040130.8940-1-zbestahu@gmail.com
Signed-off-by: Yue Hu 
Reviewed-by: Andrew Morton 
Cc: Michal Hocko 
Cc: David Rientjes 
Cc: Joe Perches 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: no need to check return value of debugfs_create functions

2019-03-06T05:07:17+00:00

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.

Link: http://lkml.kernel.org/r/20190122152151.16139-14-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman 
Cc: Michal Hocko 
Cc: Vlastimil Babka 
Cc: David Rientjes 
Cc: Laura Abbott 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/cma: remove unsupported gfp_mask parameter from cma_alloc()

2018-08-17T23:20:32+00:00

cma_alloc() doesn't really support gfp flags other than __GFP_NOWARN, so
convert gfp_mask parameter to boolean no_warn parameter.

This will help to avoid giving false feeling that this function supports
standard gfp flags and callers can pass __GFP_ZERO to get zeroed buffer,
what has already been an issue: see commit dd65a941f6ba ("arm64:
dma-mapping: clear buffers allocated with FORCE_CONTIGUOUS flag").

Link: http://lkml.kernel.org/r/20180709122019eucas1p2340da484acfcc932537e6014f4fd2c29~-sqTPJKij2939229392eucas1p2j@eucas1p2.samsung.com
Signed-off-by: Marek Szyprowski 
Acked-by: Michal Hocko 
Acked-by: Michał Nazarewicz 
Acked-by: Laura Abbott 
Acked-by: Vlastimil Babka 
Reviewed-by: Christoph Hellwig 
Cc: Joonsoo Kim 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: use octal not symbolic permissions

2018-06-14T22:55:25+00:00

mm/*.c files use symbolic and octal styles for permissions.

Using octal and not symbolic permissions is preferred by many as more
readable.

https://lkml.org/lkml/2016/8/2/1945

Prefer the direct use of octal for permissions.

Done using
$ scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace mm/*.c
and some typing.

Before:	 $ git grep -P -w "0[0-7]{3,3}" mm | wc -l
44
After:	 $ git grep -P -w "0[0-7]{3,3}" mm | wc -l
86

Miscellanea:

o Whitespace neatening around these conversions.

Link: http://lkml.kernel.org/r/2e032ef111eebcd4c5952bae86763b541d373469.1522102887.git.joe@perches.com
Signed-off-by: Joe Perches 
Acked-by: David Rientjes 
Acked-by: Michal Hocko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds