[RFC PATCH v2] mm: slub: print kernel addresses in slub debug messages

From: Miles Chen This RFC patch is sent to discuss the printing address with %p issue. Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with %p"), %p gives obfuscated addresses now. When CONFIG_SLUB_DEBUG=y, it is still useful to get real virtual addresses. Possible approaches

[RFC PATCH] mm: slub: print kernel addresses when CONFIG_SLUB_DEBUG=y

From: Miles Chen This RFC patch is sent to discuss the printing address with %p issue. Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with %p"), %p gives obfuscated addresses now. When CONFIG_SLUB_DEBUG=y, it is still useful to get real virtual addresses. Possible approaches

[RFC PATCH] mm: memcontrol: fix use after free in mem_cgroup_iter()

From: Miles Chen This RFC patch is sent to report an use after free in mem_cgroup_iter() after merging commit: be2657752e9e "mm: memcg: fix use after free in mem_cgroup_iter()". I work with android kernel tree (4.9 & 4.14), and the commit: be2657752e9e "mm: memcg: fix use after free in

[PATCH v2] mm/slub: introduce SLAB_WARN_ON_ERROR

From: Miles Chen When debugging slab errors in slub.c, sometimes we have to trigger a panic in order to get the coredump file. Add a debug option SLAB_WARN_ON_ERROR to toggle WARN_ON() when the option is set. Change since v1: 1. Add a special debug option SLAB_WARN_ON_ERROR and toggle WARN_ON()

[PATCH] mm/slub: use WARN_ON() for some slab errors

From: Miles Chen When debugging with slub.c, sometimes we have to trigger a panic in order to get the coredump file. To do that, we have to modify slub.c and rebuild kernel. To make debugging easier, use WARN_ON() for these slab errors so we can dump stack trace by default or set panic_on_warn

[RFC PATCH] of: make MAX_RESERVED_REGIONS configurable

From: Miles Chen When we use more than 32 entries in /resered-memory, there will be an error message: "not enough space all defined regions.". We can increase MAX_RESERVED_REGIONS to fix this. commit 22f8cc6e3373 ("drivers: of: increase MAX_RESERVED_REGIONS to 32") increased

[RFC PATCH] of: make MAX_RESERVED_REGIONS configurable

From: Miles Chen When we use more than 32 entries in /resered-memory, there will be an error message: "not enough space all defined regions.". We can increase MAX_RESERVED_REGIONS to fix this. commit 22f8cc6e3373 ("drivers: of: increase MAX_RESERVED_REGIONS to 32") increased

[PATCH v4] mm/page_owner: clamp read count to PAGE_SIZE

From: Miles Chen The page owner read might allocate a large size of memory with a large read count. Allocation fails can easily occur when doing high order allocations. Clamp buffer size to PAGE_SIZE to avoid arbitrary size allocation and avoid allocation fails due to high order allocation.

[PATCH v4] mm/page_owner: clamp read count to PAGE_SIZE

From: Miles Chen The page owner read might allocate a large size of memory with a large read count. Allocation fails can easily occur when doing high order allocations. Clamp buffer size to PAGE_SIZE to avoid arbitrary size allocation and avoid allocation fails due to high order allocation.

[PATCH v3] mm/page_owner: use kvmalloc instead of kmalloc

From: Miles Chen The kbuf used by page owner is allocated by kmalloc(), which means it can use only normal memory and there might be a "out of memory" issue when we're out of normal memory. To solve this problem, use kvmalloc() to allocate kbuf from normal/highmem. But there is one problem

[PATCH v3] mm/page_owner: use kvmalloc instead of kmalloc

From: Miles Chen The kbuf used by page owner is allocated by kmalloc(), which means it can use only normal memory and there might be a "out of memory" issue when we're out of normal memory. To solve this problem, use kvmalloc() to allocate kbuf from normal/highmem. But there is one problem

[PATCHv2] mm/page_owner: use kvmalloc instead of kmalloc

From: Miles Chen The kbuf used by page owner is allocated by kmalloc(), which means it can use only normal memory and there might be a "out of memory" issue when we're out of normal memory. Use kvmalloc() so we can also allocate kbuf from normal/hihghmem on 32bit kernel. Clamp the kbuf size to

[PATCHv2] mm/page_owner: use kvmalloc instead of kmalloc

From: Miles Chen The kbuf used by page owner is allocated by kmalloc(), which means it can use only normal memory and there might be a "out of memory" issue when we're out of normal memory. Use kvmalloc() so we can also allocate kbuf from normal/hihghmem on 32bit kernel. Clamp the kbuf size to

[PATCH] mm/page_owner: use vmalloc instead of kmalloc

From: Miles Chen The kbuf used by page owner is allocated by kmalloc(), which means it can use only normal memory and there might be a "out of memory" issue when we're out of normal memory. Use vmalloc() so we can also allocate kbuf from highmem on 32bit kernel. Signed-off-by: Miles Chen ---

[PATCH] mm/page_owner: use vmalloc instead of kmalloc

From: Miles Chen The kbuf used by page owner is allocated by kmalloc(), which means it can use only normal memory and there might be a "out of memory" issue when we're out of normal memory. Use vmalloc() so we can also allocate kbuf from highmem on 32bit kernel. Signed-off-by: Miles Chen ---

[PATCH] tty: check name length in tty_find_polling_driver()

From: Miles Chen The issue is found by a fuzzing test. If tty_find_polling_driver() recevies an incorrect input such as ',,' or '0b', the len becomes 0 and strncmp() always return 0. In this case, a null p->ops->poll_init() is called and it causes a kernel panic. Fix this by checking name

[PATCH] tty: check name length in tty_find_polling_driver()

From: Miles Chen The issue is found by a fuzzing test. If tty_find_polling_driver() recevies an incorrect input such as ',,' or '0b', the len becomes 0 and strncmp() always return 0. In this case, a null p->ops->poll_init() is called and it causes a kernel panic. Fix this by checking name

[RFC/PATCH] mm/shmem: add a NULL pointer test to shmem_free_inode

From: Miles Chen We noticed a kernel panic when unmounting tmpfs. It looks like a race condition in the following scenario: shmem_put_super() set sb->s_fs_info to NULL and shmem_evict_inode() tries to access sb->s_fs_info right after the sb->s_fs_info becomes NULL. CPU1

[RFC/PATCH] mm/shmem: add a NULL pointer test to shmem_free_inode

From: Miles Chen We noticed a kernel panic when unmounting tmpfs. It looks like a race condition in the following scenario: shmem_put_super() set sb->s_fs_info to NULL and shmem_evict_inode() tries to access sb->s_fs_info right after the sb->s_fs_info becomes NULL. CPU1

[PATCH] lib/dma-debug.c: fix memory leakage

From: Miles Chen Marty reported a memory leakage introduced by commit 3aaabbf1c39e ("lib/dma-debug.c: fix incorrect pfn calculation"). Fix it by checking the virtual address before allocating the entry. This patch also use virt_addr_valid() instead of virt_to_page() to

[PATCH] lib/dma-debug.c: fix memory leakage

From: Miles Chen Marty reported a memory leakage introduced by commit 3aaabbf1c39e ("lib/dma-debug.c: fix incorrect pfn calculation"). Fix it by checking the virtual address before allocating the entry. This patch also use virt_addr_valid() instead of virt_to_page() to check if a virtual

[PATCH] mm: Remove PG_highmem description

From: Miles Chen The commit cbe37d093707 ("[PATCH] mm: remove PG_highmem") has removed PG_highmem to save a page flag. So the description of PG_highmem is no longer needed, remove it. Signed-off-by: Miles Chen --- include/linux/page-flags.h |

[PATCH] mm: Remove PG_highmem description

From: Miles Chen The commit cbe37d093707 ("[PATCH] mm: remove PG_highmem") has removed PG_highmem to save a page flag. So the description of PG_highmem is no longer needed, remove it. Signed-off-by: Miles Chen --- include/linux/page-flags.h | 5 - 1 file changed, 5 deletions(-) diff

[PATCH] slub: remove obsolete comments of put_cpu_partial()

From: Miles Chen The commit d6e0b7fa1186 ("slub: make dead caches discard free slabs immediately") makes put_cpu_partial() run with preemption disabled and interrupts disabled when calling unfreeze_partials(). The comment: "put_cpu_partial() is done without interrupts

[PATCH] slub: remove obsolete comments of put_cpu_partial()

From: Miles Chen The commit d6e0b7fa1186 ("slub: make dead caches discard free slabs immediately") makes put_cpu_partial() run with preemption disabled and interrupts disabled when calling unfreeze_partials(). The comment: "put_cpu_partial() is done without interrupts disabled and without

[PATCH v5] dma-debug: fix incorrect pfn calculation

From: Miles Chen dma-debug reports the following warning: [name:panic&]WARNING: CPU: 3 PID: 298 at kernel-4.4/lib/dma-debug.c:604 debug _dma_assert_idle+0x1a8/0x230() DMA-API: cpu touching an active dma mapped cacheline [cln=0x0882300] CPU: 3 PID: 298 Comm: vold

[PATCH v5] dma-debug: fix incorrect pfn calculation

From: Miles Chen dma-debug reports the following warning: [name:panic&]WARNING: CPU: 3 PID: 298 at kernel-4.4/lib/dma-debug.c:604 debug _dma_assert_idle+0x1a8/0x230() DMA-API: cpu touching an active dma mapped cacheline [cln=0x0882300] CPU: 3 PID: 298 Comm: vold Tainted: GW O

[PATCH] dma-debug: use virt_addr_valid() to check linear addresses

From: Miles Chen Coverity found that the commit 3aaabbf1c39e ("lib/dma-debug.c: fix incorrect pfn calculation") uses incorrect API to check if a given address is a linear address. The condition should be: (as discussed in Christoph's review) if (!is_vmalloc_addr(virt) &&

[PATCH] dma-debug: use virt_addr_valid() to check linear addresses

From: Miles Chen Coverity found that the commit 3aaabbf1c39e ("lib/dma-debug.c: fix incorrect pfn calculation") uses incorrect API to check if a given address is a linear address. The condition should be: (as discussed in Christoph's review) if (!is_vmalloc_addr(virt) && !virt_addr_valid(virt))

[PATCH v4] dma-debug: fix incorrect pfn calculation

From: Miles Chen dma-debug reports the following warning: [name:panic&]WARNING: CPU: 3 PID: 298 at kernel-4.4/lib/dma-debug.c:604 debug _dma_assert_idle+0x1a8/0x230() DMA-API: cpu touching an active dma mapped cacheline [cln=0x0882300] CPU: 3 PID: 298 Comm: vold

[PATCH v4] dma-debug: fix incorrect pfn calculation

From: Miles Chen dma-debug reports the following warning: [name:panic&]WARNING: CPU: 3 PID: 298 at kernel-4.4/lib/dma-debug.c:604 debug _dma_assert_idle+0x1a8/0x230() DMA-API: cpu touching an active dma mapped cacheline [cln=0x0882300] CPU: 3 PID: 298 Comm: vold Tainted: GW O

[PATCHv2] slub: Fix sysfs duplicate filename creation when slub_debug=O

From: Miles Chen When slub_debug=O is set. It is possible to clear debug flags for an "unmergeable" slab cache in kmem_cache_open(). It makes the "unmergeable" cache became "mergeable" in sysfs_slab_add(). These caches will generate their "unique IDs" by

[PATCHv2] slub: Fix sysfs duplicate filename creation when slub_debug=O

From: Miles Chen When slub_debug=O is set. It is possible to clear debug flags for an "unmergeable" slab cache in kmem_cache_open(). It makes the "unmergeable" cache became "mergeable" in sysfs_slab_add(). These caches will generate their "unique IDs" by create_unique_id(), but it is possible

[PATCH] slub: Fix sysfs duplicate filename creation when slub_debug=O

From: Miles Chen When slub_debug=O is set. It is possible to clear debug flags for an "unmergeable" slab cache in kmem_cache_open(). It makes the "unmergeable" cache became "mergeable" in sysfs_slab_add(). These caches will generate their "unique IDs" by

[PATCH] slub: Fix sysfs duplicate filename creation when slub_debug=O

From: Miles Chen When slub_debug=O is set. It is possible to clear debug flags for an "unmergeable" slab cache in kmem_cache_open(). It makes the "unmergeable" cache became "mergeable" in sysfs_slab_add(). These caches will generate their "unique IDs" by create_unique_id(), but it is possible

[PATCH] mm/slob: remove an unnecessary check for __GFP_ZERO

From: Miles Chen Current flow guarantees a valid pointer when handling the __GFP_ZERO case. So remove the unnecessary NULL pointer check. Signed-off-by: Miles Chen --- mm/slob.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] mm/slob: remove an unnecessary check for __GFP_ZERO

From: Miles Chen Current flow guarantees a valid pointer when handling the __GFP_ZERO case. So remove the unnecessary NULL pointer check. Signed-off-by: Miles Chen --- mm/slob.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slob.c b/mm/slob.c index a8bd6fa..a72649c

[PATCH v3] dma-debug: fix incorrect pfn calculation

From: Miles Chen dma-debug reports the following warning: [name:panic&]WARNING: CPU: 3 PID: 298 at kernel-4.4/lib/dma-debug.c:604 debug _dma_assert_idle+0x1a8/0x230() DMA-API: cpu touching an active dma mapped cacheline [cln=0x0882300] CPU: 3 PID: 298 Comm: vold

[PATCH v3] dma-debug: fix incorrect pfn calculation

From: Miles Chen dma-debug reports the following warning: [name:panic&]WARNING: CPU: 3 PID: 298 at kernel-4.4/lib/dma-debug.c:604 debug _dma_assert_idle+0x1a8/0x230() DMA-API: cpu touching an active dma mapped cacheline [cln=0x0882300] CPU: 3 PID: 298 Comm: vold Tainted: GW O

[PATCH v2] dma-debug: fix incorrect pfn calculation

From: Miles Chen dma-debug report the following warning: [name:panic&]WARNING: CPU: 3 PID: 298 at kernel-4.4/lib/dma-debug.c:604 debug _dma_assert_idle+0x1a8/0x230() DMA-API: cpu touching an active dma mapped cacheline [cln=0x0882300] CPU: 3 PID: 298 Comm: vold

[PATCH v2] dma-debug: fix incorrect pfn calculation

From: Miles Chen dma-debug report the following warning: [name:panic&]WARNING: CPU: 3 PID: 298 at kernel-4.4/lib/dma-debug.c:604 debug _dma_assert_idle+0x1a8/0x230() DMA-API: cpu touching an active dma mapped cacheline [cln=0x0882300] CPU: 3 PID: 298 Comm: vold Tainted: GW O

[PATCH] dma-debug: fix incorrect pfn calculation

From: Miles Chen dma-debug report the following warning: [name:panic&]WARNING: CPU: 3 PID: 298 at kernel-4.4/lib/dma-debug.c:604 debug _dma_assert_idle+0x1a8/0x230() DMA-API: cpu touching an active dma mapped cacheline [cln=0x0882300] CPU: 3 PID: 298 Comm: vold

[PATCH] dma-debug: fix incorrect pfn calculation

From: Miles Chen dma-debug report the following warning: [name:panic&]WARNING: CPU: 3 PID: 298 at kernel-4.4/lib/dma-debug.c:604 debug _dma_assert_idle+0x1a8/0x230() DMA-API: cpu touching an active dma mapped cacheline [cln=0x0882300] CPU: 3 PID: 298 Comm: vold Tainted: GW O

[PATCH v2] checkpatch: update $logFunctions

From: Miles Chen Currently checkpatch.pl does not recognize printk_deferred* functions as log functions and complains about the line length of printk_deferred* functoins. Add printk_deferred* to logFunctions to fix it. Signed-off-by: Miles Chen

[PATCH v2] checkpatch: update $logFunctions

From: Miles Chen Currently checkpatch.pl does not recognize printk_deferred* functions as log functions and complains about the line length of printk_deferred* functoins. Add printk_deferred* to logFunctions to fix it. Signed-off-by: Miles Chen --- scripts/checkpatch.pl | 2 +- 1 file

[PATCH] checkpatch: update $logFunctions

From: Miles Chen Currently checkpatch.pl does not recognize printk_deferred* functions as log functions and complains about the line length of printk_deferred* functoins. Add printk_deferred* to logFunctions to fix it. Signed-off-by: Miles Chen

[PATCH] checkpatch: update $logFunctions

From: Miles Chen Currently checkpatch.pl does not recognize printk_deferred* functions as log functions and complains about the line length of printk_deferred* functoins. Add printk_deferred* to logFunctions to fix it. Signed-off-by: Miles Chen --- scripts/checkpatch.pl | 2 +- 1 file

[PATCH] arm64/mm: use phys_addr_t

From: Miles Chen Use phys_addr_t instead of unsigned long for the return value of __pa(), make code easy to understand. Signed-off-by: Miles Chen --- arch/arm64/mm/mmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH] arm64/mm: use phys_addr_t

From: Miles Chen Use phys_addr_t instead of unsigned long for the return value of __pa(), make code easy to understand. Signed-off-by: Miles Chen --- arch/arm64/mm/mmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index

[PATCH] arm64/mm: remove unnecessary boundary check

From: Miles Chen Remove the unnecessary boundary check since there is a huge gap between user and kernel address that they would never overlap. (arm64 does not have enough levels of page tables to cover 64-bit virtual address) See Documentation/arm64/memory.txt

[PATCH] arm64/mm: remove unnecessary boundary check

From: Miles Chen Remove the unnecessary boundary check since there is a huge gap between user and kernel address that they would never overlap. (arm64 does not have enough levels of page tables to cover 64-bit virtual address) See Documentation/arm64/memory.txt Signed-off-by: Miles Chen ---

[PATCH] arm64/mm: fix virtual address boundary check

From: Miles Chen The MODULES_VADDR is not the lowest possible kernel virtual address. TASK_SIZE_64 may be larger than MODULES_VADDR, FIXADDR_TOP, and PCI_IO_START. Fix this by comparing TASK_SIZE_64 (highest user virtual address) with VA_START (lowest kernel virtual

[PATCH] arm64/mm: fix virtual address boundary check

From: Miles Chen The MODULES_VADDR is not the lowest possible kernel virtual address. TASK_SIZE_64 may be larger than MODULES_VADDR, FIXADDR_TOP, and PCI_IO_START. Fix this by comparing TASK_SIZE_64 (highest user virtual address) with VA_START (lowest kernel virtual address). #define VA_BITS