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 are
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 are
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 mem_cgrou
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()
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 to
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 MAX_RESERVED_REGIONS
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.
Cha
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 here:
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
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
---
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 length
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
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 address
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 --git
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 preemp
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 O4.4
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))
n
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 O4.4
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 to
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 to
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 100
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 O4.4
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 O4.4.
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 O4.4.
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 changed
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 changed
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 1724
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
---
a
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
29 matches
Mail list logo
