[PATCH v2] mm/hotplug: fix an imbalance with DEBUG_PAGEALLOC

8a7dd0] [c03e52f0] ksys_write+0x70/0x120 [c005bf8a7e20] [c000b000] system_call+0x5c/0x70 Instruction dump: 7fbd5278 7fbd4a78 3e42ffeb 7bbd0640 3a523ac8 7e439378 487a2881 6000 e95505f0 7e6aa0ae 6a690080 7929c9c2 <0b09> 7f4aa1ae 7e439378 487a28dd Signed-off-by: Qian Ca

[PATCH v2] x86/mm: fix "old_pte" set but not used

t not used [-Wunused-but-set-variable] Signed-off-by: Qian Cai --- v2: improve the commit message. arch/x86/mm/pageattr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c index 14e6119838a6..4c570612e24e 100644 --- a/arch/x86

[PATCH v2] memcg: fix a bad line

The commit 230671533d64 ("mm: memory.low hierarchical behavior") missed an asterisk in one of the comments. mm/memcontrol.c:5774: warning: bad line:| 0, otherwise. Acked-by: Souptick Joarder Signed-off-by: Qian Cai --- v2: improve the commit message. mm/memcon

[PATCH v2] powerpc/mm: fix "section_base" set but not used

:16: error: variable 'section_base' set but not used [-Werror=unused-but-set-variable] Signed-off-by: Qian Cai --- v2: improve the commit message. arch/powerpc/mm/init_64.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c index a5091c034747..a4

[PATCH] mm/hugepages: fix "orig_pud" set but not used

g_pud' set but not used [-Wunused-but-set-variable] pud_t orig_pud; ^~~~ Signed-off-by: Qian Cai --- include/asm-generic/pgtable.h | 8 mm/huge_memory.c | 4 +--- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/include/asm-generic/pgtable.h b/include/a

[PATCH] x86/mm: fix "cpu" set but not used

'cpu' set but not used [-Wunused-but-set-variable] unsigned int cpu; ^~~ Signed-off-by: Qian Cai --- arch/x86/mm/tlb.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index 999d6d8f0bef..bc4bc7b2f075 100644 --- a/arch/x86/mm/tlb.c +++ b/a

[PATCH] x86/mm: fix "prev_pud" set but not used

v_pud' set but not used [-Wunused-but-set-variable] pud_t *prev_pud = NULL; ^~~~ Signed-off-by: Qian Cai --- arch/x86/mm/dump_pagetables.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c index e3cdc85ce5b6..ee8f8ab46941 100644

[PATCH] mm/sparse: fix a bad comparison

nd) { ^~~ Fixes: c4e1be9ec113 ("mm, sparsemem: break out of loops early") Signed-off-by: Qian Cai --- mm/sparse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/sparse.c b/mm/sparse.c index 7ea5dc6c6b19..77a0554fa5bd 100644 --- a/mm/sparse.c +++

[PATCH] powerpc: fix "sz" set but not used

arch/powerpc/mm/hugetlbpage-hash64.c: In function '__hash_page_huge': arch/powerpc/mm/hugetlbpage-hash64.c:29:28: warning: variable 'sz' set but not used [-Wunused-but-set-variable] Signed-off-by: Qian Cai --- arch/powerpc/mm/hugetlbpage-hash64.c | 3 +-- 1 file changed, 1 insertion(+), 2

[PATCH] x86: fix "old_pte" set but not used

arch/x86/mm/pageattr.c: In function '__should_split_large_page': arch/x86/mm/pageattr.c:741:17: warning: variable 'old_pte' set but not used [-Wunused-but-set-variable] Signed-off-by: Qian Cai --- arch/x86/mm/pageattr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH] powerpc: fix "section_base" set but not used

arch/powerpc/mm/init_64.c: In function 'vmemmap_free': arch/powerpc/mm/init_64.c:277:16: error: variable 'section_base' set but not used [-Werror=unused-but-set-variable] Signed-off-by: Qian Cai --- arch/powerpc/mm/init_64.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/mm

[PATCH] memcg: fix a bad line

Miss a star. Signed-off-by: Qian Cai --- mm/memcontrol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index af7f18b32389..d4b96dc4bd8a 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -5747,7 +5747,7 @@ struct cgroup_subsys

Re: [PATCH] tmpfs: fix uninitialized return value in shmem_link

On Wed, 2019-02-27 at 09:09 -0500, Qian Cai wrote: > On Mon, 2019-02-25 at 16:07 -0800, Linus Torvalds wrote: > > On Mon, Feb 25, 2019 at 4:03 PM Qian Cai wrote: > > > > > > > > Of course, that's just gcc. I have no idea what llvm ends up doing. > > >

[PATCH v3] mm/page_ext: fix an imbalance with kmemleak

anic - not syncing: Fatal exception ]--- Signed-off-by: Qian Cai --- v3: place kmemleak_free() before free_pages_exact() to avoid a small window where the address has been freed but kmemleak not informed pointed out by Catalin. v2: move kmemleak_free() into free_page_ext() as there

[PATCH v2] mm/page_ext: fix an imbalance with kmemleak

anic - not syncing: Fatal exception ]--- Signed-off-by: Qian Cai --- v2: move kmemleak_free() into free_page_ext() as there is no need to call kmemleak_free() in the vfree() case. mm/page_ext.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/page_ext.c b/mm/page_ext.c index 8c78b8d4

[PATCH] mm/page_ext: fix an imbalance with kmemleak

anic - not syncing: Fatal exception ]--- Signed-off-by: Qian Cai --- mm/page_ext.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/page_ext.c b/mm/page_ext.c index 8c78b8d45117..b68f2a58ea3b 100644 --- a/mm/page_ext.c +++ b/mm/page_ext.c @@ -288,6 +288,7 @@ static void __free_page_ext

Re: [PATCH] tmpfs: fix uninitialized return value in shmem_link

On Mon, 2019-02-25 at 16:07 -0800, Linus Torvalds wrote: > On Mon, Feb 25, 2019 at 4:03 PM Qian Cai wrote: > > > > > > Of course, that's just gcc. I have no idea what llvm ends up doing. > > > > Clang 7.0: > > > > # clang  -O2 -S -Wall /tmp/test.c

Re: [PATCH] mm/hotplug: fix an imbalance with DEBUG_PAGEALLOC

On Tue, 2019-02-26 at 20:40 +0100, Michal Hocko wrote: > It seems you have missed the point of my question. It simply doesn't > make much sense to have offline memory mapped. That memory is not > accessible in general. So mapping it at the offline time is dubious at > best. Well,

Re: [PATCH] mm/hotplug: fix an imbalance with DEBUG_PAGEALLOC

On Tue, 2019-02-26 at 19:20 +0100, Michal Hocko wrote: > Btw. what happens if the offlined pfn range is removed completely? Is > the range still mapped? What kind of consequences does this have? Well, the pages are still marked as reserved as well, so it is up to the physically memory hotplug

Re: [PATCH] mm/hotplug: fix an imbalance with DEBUG_PAGEALLOC

On Tue, 2019-02-26 at 15:23 +0100, Michal Hocko wrote: > On Tue 26-02-19 09:16:30, Qian Cai wrote: > > > > > > On 2/26/19 7:35 AM, Michal Hocko wrote: > > > On Mon 25-02-19 14:17:10, Qian Cai wrote: > > > > When onlining memory pages, it calls kernel_unm

Re: [PATCH] mm/hotplug: fix an imbalance with DEBUG_PAGEALLOC

On 2/26/19 7:35 AM, Michal Hocko wrote: > On Mon 25-02-19 14:17:10, Qian Cai wrote: >> When onlining memory pages, it calls kernel_unmap_linear_page(), >> However, it does not call kernel_map_linear_page() while offlining >> memory pages. As the result, it triggers a panic

Re: [PATCH] mm/hotplug: fix an imbalance with DEBUG_PAGEALLOC

On 2/26/19 7:13 AM, Souptick Joarder wrote: > On Tue, Feb 26, 2019 at 12:47 AM Qian Cai wrote: >> >> When onlining memory pages, it calls kernel_unmap_linear_page(), >> However, it does not call kernel_map_linear_page() while offlining >> memory pages. As the result

Re: [PATCH] tmpfs: fix uninitialized return value in shmem_link

On 2/25/19 6:58 PM, Linus Torvalds wrote: > On Mon, Feb 25, 2019 at 2:34 PM Linus Torvalds > wrote: >> >> On Mon, Feb 25, 2019 at 12:34 PM Hugh Dickins wrote: >>> >>> Seems like a gcc bug? But I don't have a decent recent gcc to hand >>> to submit a proper report, hope someone else can shed

[PATCH] mm/hotplug: fix an imbalance with DEBUG_PAGEALLOC

e95505f0 7e6aa0ae 6a690080 7929c9c2 <0b09> 7f4aa1ae 7e439378 487a28dd Signed-off-by: Qian Cai --- mm/page_alloc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 10d0f2ed9f69..025fc93d1518 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -

Re: [PATCH] [v2] kasan: turn off asan-stack for clang-8 and earlier

et, the option remains invisible, so allmodconfig and randconfig builds > (which are normally done with a forced CONFIG_COMPILE_TEST) will still result > in a mostly clean build. > > Cc: Andrey Ryabinin > Cc: Dmitry Vyukov > Cc: Nick Desaulniers > Cc: Mark Brown > Cc: Qian C

Re: [PATCH -next] mm/debug: use lx% for atomic64_read() on ppc64le

Please ignore this patch. On 2/20/19 8:08 PM, Qian Cai wrote: > atomic64_read() on ppc64le returns "long int" while "long long" seems on > all other arches, so deal the special case for ppc64le. > > In file included from ./include/linux/printk.h:7, >

[PATCH -next] mm/debug: add a cast to u64 for atomic64_read()

lx stack_vm %lx\n" ~~~^ %lx Fixes: 70f8a3ca68d3 ("mm: make mm->pinned_vm an atomic64 counter") Signed-off-by: Qian Cai --- mm/debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/debug.c b/mm/debug.c index c0b31b6c3877..45d9e

[PATCH -next] mm/debug: use lx% for atomic64_read() on ppc64le

d3 ("mm: make mm->pinned_vm an atomic64 counter") Signed-off-by: Qian Cai --- mm/debug.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/mm/debug.c b/mm/debug.c index c0b31b6c3877..e4ec3d68833e 100644 --- a/mm/debug.c +++ b/mm/debug.c @@ -137,7 +137,12 @

Re: [PATCH 1/4] kasan: prevent tracing of tags.c

On 2/20/19 7:45 AM, Andrey Konovalov wrote: > Similarly to 0d0c8de8 ("kasan: mark file common so ftrace doesn't trace > it") add the -pg flag to mm/kasan/tags.c to prevent conflicts with > tracing. > > Reported-by: Qian Cai > Signed-off-by: Andrey Konovalov Tested-by: Qian Cai

[PATCH] slub: fix a crash with SLUB_DEBUG + KASAN_SW_TAGS

failed to stop secondary CPUs 1-7,32,40,127 [18870.259942] Kernel Offset: disabled [18870.263434] CPU features: 0x002,2c18 [18870.267358] Memory Limit: none [18870.270725] ---[ end Kernel panic - not syncing: Fatal exception ]--- Signed-off-by: Qian Cai --- mm/slub.c | 2 +- 1 file changed

Re: [PATCH] kasan: turn off asan-stack for clang-8 and earlier

On 2/19/19 7:33 PM, Kostya Serebryany wrote: >>> Well, I am using clang 8.0 on arm64 and running the kernel just fine for a >>> few >>> weeks now and never trigger a single stack overflow (THREAD_SHIFT = 15) >>> because >>> I never use any of those drivers you mentioned above. I don't think

Re: [PATCH] kasan: turn off asan-stack for clang-8 and earlier

On Tue, 2019-02-19 at 22:49 +0100, Arnd Bergmann wrote: > Building an arm64 allmodconfig kernel with clang results in over 140 warnings > about overly large stack frames, the worst ones being: > > drivers/gpu/drm/panel/panel-sitronix-st7789v.c:196:12: error: stack frame size > of 20224 bytes in

Re: [PATCH] trace: skip hwasan

On 2/18/19 10:25 AM, Andrey Konovalov wrote: > On Sun, Feb 17, 2019 at 5:34 AM Qian Cai wrote: >> >> Enabling function tracer with CONFIG_KASAN_SW_TAGS=y (hwasan) tracer >> causes the whole system frozen on ThunderX2 systems with 256 CPUs, >> because there is a burst

Re: [PATCH] trace: skip hwasan

On 2/17/19 2:30 AM, Dmitry Vyukov wrote: > On Sun, Feb 17, 2019 at 5:34 AM Qian Cai wrote: >> >> Enabling function tracer with CONFIG_KASAN_SW_TAGS=y (hwasan) tracer >> causes the whole system frozen on ThunderX2 systems with 256 CPUs, >> because there is a burst

[PATCH] trace: skip hwasan

the CPUs. Signed-off-by: Qian Cai --- kernel/trace/Makefile | 5 + 1 file changed, 5 insertions(+) diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile index c2b2148bb1d2..fdd547a68385 100644 --- a/kernel/trace/Makefile +++ b/kernel/trace/Makefile @@ -28,6 +28,11 @@ ifdef

[PATCH] arm64/mm: skip hwasan callbacks for pgtable walker

+0x90/0xfc [ 76.675894] mark_rodata_ro+0x38/0x44 [ 76.679557] kernel_init+0x48/0x180 [ 76.683045] ret_from_fork+0x10/0x18 Signed-off-by: Qian Cai --- arch/arm64/mm/Makefile | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile index

Re: [PATCH] kasan, slub: fix more conflicts with CONFIG_SLAB_FREELIST_HARDENED

t_freepointer() with an untagged pointer, which causes the >> freepointer to be restored incorrectly. >> >> Add kasan_reset_tag to freelist_ptr(). Also add a detailed comment. >> >> Signed-off-by: Andrey Konovalov > > Reported-by: Qian Cai Tested-by: Qian Cai

Re: [PATCH] slub: untag object before slab end

On Wed, 2019-02-13 at 11:31 +0100, Andrey Konovalov wrote: > On Wed, Feb 13, 2019 at 3:06 AM Qian Cai wrote: > > > > get_freepointer() could return NULL if there is no more free objects in > > the slab. However, it could return a tagged pointer (like > > 0x22000

Re: [PATCH v2 3/5] kmemleak: account for tagged pointers when calculating pointer range

tagged pointers this range will get bigger than it needs to be. > This patch makes kmemleak untag pointers before saving them to min_addr > and max_addr and when performing a lookup. > > Signed-off-by: Andrey Konovalov Tested-by: Qian Cai

Re: [PATCH 5/5] kasan, slub: fix conflicts with CONFIG_SLAB_FREELIST_HARDENED

On 2/12/19 11:07 AM, Qian Cai wrote: > https://git.sr.ht/~cai/linux-debug/tree/master/dmesg > FYI, I just send a patch to take care of this. https://marc.info/?l=linux-mm=155002356527913=2

[PATCH] slub: untag object before slab end

[ 36.247555] kernel_init+0x18/0x2a4 [ 36.251083] ret_from_fork+0x10/0x18 Signed-off-by: Qian Cai --- Depends on slub-fix-slab_consistency_checks-kasan_sw_tags.patch. mm/slub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slub.c b/mm/slub.c index 4a61959e1887..2fd1cf39914c

Re: [PATCH 5/5] kasan, slub: fix conflicts with CONFIG_SLAB_FREELIST_HARDENED

On 2/12/19 9:42 AM, Andrey Konovalov wrote: > On Tue, Feb 12, 2019 at 2:43 PM Qian Cai wrote: >> >> >> >> On 2/12/19 8:26 AM, Andrey Konovalov wrote: >>> Hm, did you apply all 6 patches (the one that you sent and these five) >> Yes. > > I'm

Re: [PATCH 5/5] kasan, slub: fix conflicts with CONFIG_SLAB_FREELIST_HARDENED

On 2/12/19 8:26 AM, Andrey Konovalov wrote: > Hm, did you apply all 6 patches (the one that you sent and these five) Yes.

Re: [PATCH 5/5] kasan, slub: fix conflicts with CONFIG_SLAB_FREELIST_HARDENED

rst argument untagged. This patch changes the code to properly > propagate tags throughout the loop. > > Reported-by: Qian Cai > Signed-off-by: Andrey Konovalov > --- > mm/slub.c | 20 +++- > 1 file changed, 7 insertions(+), 13 deletions(-) > > dif

[PATCH] slub: remove an unused addr argument

"addr" function argument is not used in alloc_consistency_checks() at all, so remove it. Fixes: becfda68abca ("slub: convert SLAB_DEBUG_FREE to SLAB_CONSISTENCY_CHECKS") Signed-off-by: Qian Cai --- mm/slub.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --

[PATCH] slub: fix SLAB_CONSISTENCY_CHECKS + KASAN_SW_TAGS

-off-by: Qian Cai --- mm/slub.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/slub.c b/mm/slub.c index 1e3d0ec4e200..075ebc529788 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -507,6 +507,7 @@ static inline int check_valid_pointer(struct kmem_cache *s, return 1; base

[PATCH -next] x86_64: tidy up KASAN_EXTRA

The commit 585a4c1f9978 ("kasan: remove use after scope bugs detection.") removed KASAN_EXTRA, so tidy up leftovers. Signed-off-by: Qian Cai --- arch/x86/include/asm/page_64_types.h | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x

[PATCH -next] mm/compaction: no stuck in __reset_isolation_pfn()

what pageblocks to clear skip hints") Signed-off-by: Qian Cai --- mm/compaction.c | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/mm/compaction.c b/mm/compaction.c index 03804ab412f3..1cc871da3fda 100644 --- a/mm/compaction.c +++ b/mm/compaction.

Re: mm: race in put_and_wait_on_page_locked()

>> Cai, can you please check if you can reproduce this issue in your >> environment with 5.0-rc5? > > Yes, please do - practical confirmation more convincing than my certainty. Indeed, I am no longer be able to reproduce this anymore.

Re: mm: race in put_and_wait_on_page_locked()

On 2/4/19 3:42 PM, Hugh Dickins wrote: > On Mon, 4 Feb 2019, Artem Savkov wrote: > >> Hi Hugh, >> >> Your recent patch 9a1ea439b16b "mm: put_and_wait_on_page_locked() while >> page is migrated" seems to have introduced a race into page migration >> process. I have a host that eagerly

[PATCH -next] hugetlbfs: a terminator for hugetlb_param_specs[]

91.681740] el0_svc+0x8/0xc Fixes: 2284cf59cbce ("hugetlbfs: Convert to fs_context") Signed-off-by: Qian Cai --- fs/hugetlbfs/inode.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index abf0c2eb834e..4f352743930f 100644 --- a/fs/hugetlb

[PATCH -next] efi/arm64: return zero from ptdump_init()

f non-void function [-Wreturn-type] Fixes: e2a2e56e4082 ("arm64: dump: no need to check return value of debugfs_create functions") Signed-off-by: Qian Cai --- drivers/firmware/efi/arm-runtime.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/firmwar

[tip:efi/urgent] efi/arm64: Fix debugfs crash by adding a terminator for ptdump marker

Commit-ID: 74c953ca5f6b4d5f1daa1ef34f4317e15c1a2987 Gitweb: https://git.kernel.org/tip/74c953ca5f6b4d5f1daa1ef34f4317e15c1a2987 Author: Qian Cai AuthorDate: Sat, 2 Feb 2019 10:50:17 +0100 Committer: Ingo Molnar CommitDate: Sat, 2 Feb 2019 11:27:29 +0100 efi/arm64: Fix debugfs crash

Re: linux-next: Fixes tags needs some work in the akpm-current tree

On 1/30/19 7:05 PM, Stephen Rothwell wrote: > In commit > > 6e9ed490d190 ("mm/page_owner: fix for deferred struct page init") > > Fixes tag > > Fixes: fe53ca54270 ("mm: use early_pfn_to_nid in page_ext_init") > > has these problem(s): > > - SHA1 should be at least 12 digits long >

[RESEND PATCH] slab: kmemleak no scan alien caches

] ret_from_fork+0x10/0x18 Fixes: 1fe00d50a9e8 (slab: factor out initialization of array cache) Signed-off-by: Qian Cai --- mm/slab.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/mm/slab.c b/mm/slab.c index 78eb8c5bf4e4..0aff454f007b 100644 --- a/mm/slab.c

[PATCH] efi/arm64: add a terminator for ptdump marker

0 00 00 [12126.318140] 2000123f2b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 Fixes: 9d80448ac92b ("efi/arm64: Add debugfs node to dump UEFI runtime page tables") Signed-off-by: Qian Cai --- drivers/firmware/efi/arm-runtime.c | 3 ++- 1 file changed, 2 insertions(+), 1 d

Re: [PATCH] backing-dev: no need to check return value of debugfs_create functions

On 1/22/19 1:33 PM, Greg Kroah-Hartman wrote: > On Tue, Jan 22, 2019 at 06:19:08PM +0100, Sebastian Andrzej Siewior wrote: >> On 2019-01-22 17:25:03 [+0100], Greg Kroah-Hartman wrote: > } > > static void bdi_debug_unregister(struct backing_dev_info *bdi) > { > -

[PATCH v4] mm/hotplug: invalid PFNs from pfn_to_online_page()

secondary CPUs [ 102.431830] Kernel Offset: disabled [ 102.435311] CPU features: 0x002,2c38 [ 102.439223] Memory Limit: none [ 102.442384] ---[ end Kernel panic - not syncing: Fatal exception ]--- Fixes: 9f1eb38e0e11 ("mm, kmemleak: little optimization while scanning") Acked-by: Michal

[PATCH v3] mm/hotplug: invalid PFNs from pfn_to_online_page()

secondary CPUs [ 102.431830] Kernel Offset: disabled [ 102.435311] CPU features: 0x002,2c38 [ 102.439223] Memory Limit: none [ 102.442384] ---[ end Kernel panic - not syncing: Fatal exception ]--- Fixes: 9f1eb38e0e11 ("mm, kmemleak: little optimization while scanning") Acked-by: M

[PATCH v2] mm/hotplug: invalid PFNs from pfn_to_online_page()

secondary CPUs [ 102.431830] Kernel Offset: disabled [ 102.435311] CPU features: 0x002,2c38 [ 102.439223] Memory Limit: none [ 102.442384] ---[ end Kernel panic - not syncing: Fatal exception ]--- Fixes: 2d070eab2e82 ("mm: consider zone which is not fully populated to have holes") S

Re: kmemleak panic

On 1/18/19 12:05 PM, Marc Gonzalez wrote: > On 18/01/2019 17:14, Qian Cai wrote: > >> This looks like something different from the original "invalid PFNs from >> pfn_to_online_page()" issue. What's your .config ? > > Here's my defconfig: > > # CONF

Re: [PATCH v2] rbtree: fix the red root

On 1/16/19 9:37 AM, Esme wrote: > I have been off but back now, I had fetch'd current again and the diagnostics > look a bit different, maybe I just got lucky. Instead of fork'ng the test > case (which is fairly aggressive in any case), interacting from the serial > port with sig-int ^C

Re: kmemleak panic

On 1/18/19 10:36 AM, Marc Gonzalez wrote: > On 18/01/2019 15:34, Catalin Marinas wrote: > >> On Fri, Jan 18, 2019 at 02:36:46PM +0100, Marc Gonzalez wrote: >> >>> Trying to diagnose a separate issue, I enabled a raft of debugging options, >>> including kmemleak. However, it looks like kmemleak

kmemleak scan crash due to invalid PFNs

On an arm64 ThunderX2 server, the first kmemleak scan would crash with CONFIG_DEBUG_VM_PGFLAGS=y due to page_to_nid() found a pfn that is not directly mapped. Hence, the page->flags is not initialized. Reverted 9f1eb38e0e113 (mm, kmemleak: little optimization while scanning) fixed the problem. [

[PATCH] slab: kmemleak no scan alien caches

] ret_from_fork+0x10/0x18 Fixes: 1fe00d50a9e8 (slab: factor out initialization of array cache) Signed-off-by: Qian Cai --- mm/slab.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/mm/slab.c b/mm/slab.c index 78eb8c5bf4e4..0aff454f007b 100644 --- a/mm/slab.c

[PATCH] Revert "mm: use early_pfn_to_nid in page_ext_init"

This means that assumptions behind commit fe53ca54270a ("mm: use early_pfn_to_nid in page_ext_init") are incomplete. Therefore, revert the commit for now. A proper way to move the page_owner initialization to sooner is to hook into memmap initialization. Acked-by: Michal Hocko Sig

Re: [PATCH] kvm: add proper frame pointer logic for vmx

On 1/15/19 12:49 PM, Sean Christopherson wrote: > On Tue, Jan 15, 2019 at 09:48:45AM -0800, Sean Christopherson wrote: >> On Tue, Jan 15, 2019 at 11:43:20AM -0500, Qian Cai wrote: >>> >>> >>> On 1/15/19 2:13 AM, Paolo Bonzini wrote: >>>> Hmm, mayb

Re: [PATCH] kvm: add proper frame pointer logic for vmx

On 1/15/19 11:43 AM, Qian Cai wrote: > > > On 1/15/19 2:13 AM, Paolo Bonzini wrote: >> Hmm, maybe like this: >> >> diff --git a/arch/x86/kvm/vmx/vmenter.S b/arch/x86/kvm/vmx/vmenter.S >> index bcef2c7e9bc4..33122fa9d4bd 100644 >> --- a/arch/x86/kvm/

Re: [PATCH] kvm: add proper frame pointer logic for vmx

On 1/15/19 11:34 AM, Sean Christopherson wrote: > On Tue, Jan 15, 2019 at 08:13:22AM +0100, Paolo Bonzini wrote: >> On 15/01/19 08:04, Qian Cai wrote: >>> >>> >>> On 1/15/19 1:44 AM, Qian Cai wrote: >>>> compilation warning since v5.0-rc1, &g

Re: [PATCH] kvm: add proper frame pointer logic for vmx

On 1/15/19 2:13 AM, Paolo Bonzini wrote: > Hmm, maybe like this: > > diff --git a/arch/x86/kvm/vmx/vmenter.S b/arch/x86/kvm/vmx/vmenter.S > index bcef2c7e9bc4..33122fa9d4bd 100644 > --- a/arch/x86/kvm/vmx/vmenter.S > +++ b/arch/x86/kvm/vmx/vmenter.S > @@ -26,19 +26,17 @@ ENTRY(vmx_vmenter) >

[PATCH] kvm: always inline vmx_vcpu_run()

confuses STACK_FRAME_NON_STANDARD(vmx_vcpu_run). Hence, just inline the whole function to avoid this. Fixes: 453eafbe65f (KVM: VMX: Move VM-Enter + VM-Exit handling to non-inline sub-routines) Signed-off-by: Qian Cai --- arch/x86/kvm/vmx/vmx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion

Re: [PATCH] kvm: add proper frame pointer logic for vmx

On 1/15/19 1:44 AM, Qian Cai wrote: > compilation warning since v5.0-rc1, > > arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_vcpu_run.part.17()+0x3171: > call without frame pointer save/setup > > Fixes: 453eafbe65f (KVM: VMX: Move VM-Enter + VM-Exit handling to > non-inlin

[PATCH] kvm: add proper frame pointer logic for vmx

compilation warning since v5.0-rc1, arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_vcpu_run.part.17()+0x3171: call without frame pointer save/setup Fixes: 453eafbe65f (KVM: VMX: Move VM-Enter + VM-Exit handling to non-inline sub-routines) Signed-off-by: Qian Cai --- arch/x86/kvm/vmx/vmenter.S

Re: [PATCH v2] rbtree: fix the red root

> [ 114.913404] Padding 6913c65d: 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 > [ 114.915437] Padding 2d53f25c: 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 > [ 114.917390] Padding 78f7d621: 00 00 00 00 00 00 00 00 00 00

[PATCH v2] page_poison: play nicely with KASAN

poisoning needs to poison the whole page. Signed-off-by: Qian Cai --- v2: use kasan_disable/enable_current() instead. mm/page_alloc.c | 2 +- mm/page_poison.c | 4 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index d295c9bc01a8..906250a9b89c

Re: [PATCH v2] rbtree: fix the red root

Unfortunately, I could not trigger any of those here both in a bare-metal and virtual machines. All I triggered were hung tasks and soft-lockup due to fork bomb. The only other thing I can think of is to setup kdump to capture a vmcore when either GPF or BUG() happens, and then share the vmcore

Re: [PATCH v2] rbtree: fix the red root

On 1/14/19 1:23 AM, Esme wrote: > I did not yet verify the previous branches but did tune out kmemleak > (CONFIG_DEBUG_MEMLEAK no longer set) as it seemed a bit obtrusive in this > matter, this is what I see now (note redzone?). > /Esme > > 114.826116] >

Re: [PATCH v2] rbtree: fix the red root

On 1/13/19 9:20 PM, David Lechner wrote: > On 1/11/19 8:58 PM, Michel Lespinasse wrote: >> On Fri, Jan 11, 2019 at 3:47 PM David Lechner wrote: >>> >>> On 1/11/19 2:58 PM, Qian Cai wrote: >>>> A GPF was reported, >>>> >>>> kas

Re: [PATCH v2] rbtree: fix the red root

On 1/11/19 6:16 PM, Matthew Wilcox wrote: > On Fri, Jan 11, 2019 at 03:58:43PM -0500, Qian Cai wrote: >> diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c >> index b7055b2a07d3..afad0213a117 100644 >> --- a/lib/rbtree_test.c >> +++ b/lib/rbtree_test.c >> @@ -3

[PATCH v2] rbtree: fix the red root

in rb_insert_color() only when necessary) Reported-by: Esme Tested-by: Joey Pabalinas Signed-off-by: Qian Cai --- v2: add a regression test. lib/rbtree.c | 7 +++ lib/rbtree_test.c | 11 +++ 2 files changed, 18 insertions(+) diff --git a/lib/rbtree.c b/lib/rbtree.c index

Re: [PATCH] rbtree: fix the red root

On Fri, 2019-01-11 at 09:31 -0800, Matthew Wilcox wrote: > On Fri, Jan 11, 2019 at 11:51:45AM -0500, Qian Cai wrote: > > Reported-by: Esme > > Signed-off-by: Qian Cai > > What change introduced this bug?  We need a Fixes: line so the stable > people know how far to back

[PATCH] rbtree: fix the red root

*/ if(rb_is_black(parent)) break; Hence, it violates the rule #1 and need a fix up. Reported-by: Esme Signed-off-by: Qian Cai --- lib/rbtree.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/lib/rbtree.c b/lib/rbtree.c index d3ff682fd4b8..acc969ad8de9 100644 --- a/lib/rbtree.c ++

Re: kernel BUG at kernel/sched/core.c:3490!

On Fri, 2019-01-11 at 16:07 +0530, Kohli, Gaurav wrote: > > On 1/7/2019 11:26 PM, Oleg Nesterov wrote: > > pr_crit("XXX: %ld %d\n", current->state, current->on_rq); > > Can we also add flags, this may help to know the path of problem: > >   pr_crit("XXX: %ld %d 0x%x\n", current->state,

Re: PROBLEM: syzkaller found / pool corruption-overwrite / page in user-area or NULL

On 1/10/19 10:15 PM, Esme wrote: >>> [ 75.793150] RIP: 0010:rb_insert_color+0x189/0x1480 >> >> What's in that line? Try, >> >> $ ./scripts/faddr2line vmlinux rb_insert_color+0x189/0x1480 > > rb_insert_color+0x189/0x1480: > __rb_insert at /home/files/git/linux/lib/rbtree.c:131 > (inlined by)

Re: PROBLEM: syzkaller found / pool corruption-overwrite / page in user-area or NULL

On 1/10/19 5:58 PM, Esme wrote: > The console debug/stacks/info from just now. The previous config, current > kernel from github. > -- > Esme > > [ 75.783231] kasan: CONFIG_KASAN_INLINE enabled > [ 75.785870] kasan: GPF could be caused by NULL-ptr deref or user memory > access > [

Re: PROBLEM: syzkaller found / pool corruption-overwrite / page in user-area or NULL

On Thu, 2019-01-10 at 21:35 +, Esme wrote: > The repro.report is from a different test system, I pulled the attached config > from proc (attached); > So, if the report is not right one. Where is the right crash stack trace then that using the exact same config.?

Re: PROBLEM: syzkaller found / pool corruption-overwrite / page in user-area or NULL

On Thu, 2019-01-10 at 20:47 +, Esme wrote: > Sure thing; > > cmdline; > qemu-system-x86_64 -kernel linux//arch/x86/boot/bzImage -append console=ttyS0 > root=/dev/sda debug earlyprintk=serial slub_debug=QUZ -hda stretch.img -net > user,hostfwd=tcp::10021-:22 -net nic -enable-kvm -nographic -m

Re: PROBLEM: syzkaller found / pool corruption-overwrite / page in user-area or NULL

On Thu, 2019-01-10 at 11:58 -0800, James Bottomley wrote: > On Thu, 2019-01-10 at 19:12 +, Esme wrote: > > Sorry for the resend some mail servers rejected the mime type. > > > > Hi, I've been getting more into Kernel stuff lately and forged ahead > > with some syzkaller bug finding.  I played

Re: PROBLEM: syzkaller found / pool corruption-overwrite / page in user-area or NULL

On Thu, 2019-01-10 at 11:58 -0800, James Bottomley wrote: > On Thu, 2019-01-10 at 19:12 +, Esme wrote: > > Sorry for the resend some mail servers rejected the mime type. > > > > Hi, I've been getting more into Kernel stuff lately and forged ahead > > with some syzkaller bug finding.  I played

Re: [RESEND PATCH] x86_64: increase stack size for KASAN_EXTRA

On 1/9/19 5:02 PM, Andrew Morton wrote: >> --- a/arch/x86/include/asm/page_64_types.h >> +++ b/arch/x86/include/asm/page_64_types.h >> @@ -7,7 +7,11 @@ >> #endif >> >> #ifdef CONFIG_KASAN >> +#ifdef CONFIG_KASAN_EXTRA >> +#define KASAN_STACK_ORDER 2 >> +#else >> #define KASAN_STACK_ORDER 1

[RESEND PATCH] x86_64: increase stack size for KASAN_EXTRA

fault. Hence, the stack usage with KASAN_EXTRA can be revisited again in 2020 when GCC 9 is everywhere. Until then, this patch will help users avoid stack overrun. This has already been fixed for arm64 for the same reason via 6e8830674ea (arm64: kasan: Increase stack size for KASAN_EXTRA). Signed-off-by: Q

Re: [PATCH] xfs: silence lockdep false positives when freezing

On Thu, 2019-01-10 at 08:01 +1100, Dave Chinner wrote: > On Wed, Jan 09, 2019 at 03:53:29PM -0500, Qian Cai wrote: > > Easy to reproduce: > > > > 1. run LTP oom02 workload to let kswapd acquire this locking order: > >    fs_reclaim -> sb_internal. > >

[PATCH] xfs: silence lockdep false positives when freezing

do_syscall_64+0x18f/0xd23 entry_SYSCALL_64_after_hwframe+0x49/0xbe Signed-off-by: Qian Cai --- fs/xfs/libxfs/xfs_sb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/xfs/libxfs/xfs_sb.c b/fs/xfs/libxfs/xfs_sb.c index b5a82acd7dfe..ec83cb8289fa 100644 --- a/fs/xfs/libxfs/xfs_sb.c +++

Re: lockdep warning while reading sysfs

> You stripped out the stack trace at the bottom that shows the inversion > :/ > Sorry, I thought it is the same as in #0, but here it is the whole thing. WARNING: possible circular locking dependency detected 5.0.0-rc1+ #60 Not tainted --

lockdep warning while reading sysfs

LTP: starting read_all_sys (read_all -d /sys -q -r 10 -e /sys/power/wakeup_count) Suppose this simply by reading files in /sys/kernel/slab/* would trigger this. Basically, it acquired kn->count#69 in kernfs_seq_start(): mutex_lock(>mutex); if (!kernfs_get_active(of->kn)) in

Re: [PATCH v3] mm/page_owner: fix for deferred struct page init

On 1/8/19 5:02 PM, Andrew Morton wrote: > > It's unclear (to me) where we stand with this patch. Shold we proceed > with v3 for now, or is something else planned? I don't have anything else plan for this right now. Michal particular don't like that 4-line ifdef which supposes to avoid an

Re: [PATCH v3] mm/page_owner: fix for deferred struct page init

On Tue, 2019-01-08 at 09:20 +0100, Michal Hocko wrote: > On Mon 07-01-19 20:53:08, Qian Cai wrote: > > > > > > On 1/7/19 1:43 PM, Michal Hocko wrote: > > > On Fri 04-01-19 15:18:08, Qian Cai wrote: > > > [...] > > > > Though, I can't

Re: [PATCH v2] kmemleak: survive in a low-memory situation

On 1/7/19 9:06 PM, Qian Cai wrote: > > > On 1/7/19 5:43 AM, Catalin Marinas wrote: >> On Thu, Jan 03, 2019 at 06:07:35PM +0100, Michal Hocko wrote: >>>>> On Wed 02-01-19 13:06:19, Qian Cai wrote: >>>>> [...] >>>>>> diff

Re: [PATCH v2] kmemleak: survive in a low-memory situation

On 1/7/19 5:43 AM, Catalin Marinas wrote: > On Thu, Jan 03, 2019 at 06:07:35PM +0100, Michal Hocko wrote: >>>> On Wed 02-01-19 13:06:19, Qian Cai wrote: >>>> [...] >>>>> diff --git a/mm/kmemleak.c b/mm/kmemleak.c >>>>> index f9

Re: [PATCH v3] mm/page_owner: fix for deferred struct page init

On 1/7/19 1:43 PM, Michal Hocko wrote: > On Fri 04-01-19 15:18:08, Qian Cai wrote: > [...] >> Though, I can't see any really benefit of this approach apart from "beautify" > > This is not about beautifying! This is about making the code long term > maintainable

<    5   6   7   8   9   10   11   12   13   >