Re: ODEBUG: Out of memory. ODEBUG disabled

2018-11-09 Thread Qian Cai
> Sent: Friday, November 09, 2018 at 5:08 PM > From: "Waiman Long" > To: "Qian Cai" , "Yang Shi" > Cc: "open list" , "Thomas Gleixner" > , "Arnd Bergmann" , "Joel Fernandes > (Google)" , "Zhong Jiang&

WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c

2018-11-08 Thread Qian Cai
Just booting up the latest git master (b00d209) on an aarch64 server and saw this. Not sure about the third warning (at kernel/cpu.c:315 lockdep_assert_cpus_held+0x50/0x60) relates to irqchip or not, but appended it to here anyway just in case. [0.00] WARNING: CPU: 0 PID: 0 at

ODEBUG: Out of memory. ODEBUG disabled

2018-11-09 Thread Qian Cai
It is a bit annoying on this aarch64 server with 64 CPUs that is booting the latest mainline (3541833fd1f2) causes object debugging always running out of memory. I have to boot the kernel with only 16 CPUs instead (nr_cpus=16) to make it work. Is it expected that object debugging is not going to

Re: ODEBUG: Out of memory. ODEBUG disabled

2018-11-09 Thread Qian Cai
> On Nov 9, 2018, at 4:42 PM, Yang Shi wrote: > > > > On 11/9/18 1:36 PM, Qian Cai wrote: >> It is a bit annoying on this aarch64 server with 64 CPUs that is >> booting the latest mainline (3541833fd1f2) causes object debugging >> always running out of

kmemleak: Early log buffer exceeded (525980) during boot

2018-11-08 Thread Qian Cai
The maximum value for DEBUG_KMEMLEAK_EARLY_LOG_SIZE is only 4, so it disables kmemleak every time on this aarch64 server running the latest mainline (b00d209). # echo scan > /sys/kernel/debug/kmemleak  -bash: echo: write error: Device or resource busy Any idea on how to enable kmemleak

Re: kmemleak: Early log buffer exceeded (525980) during boot

2018-11-10 Thread Qian Cai
> On Nov 8, 2018, at 4:23 PM, Qian Cai wrote: > > The maximum value for DEBUG_KMEMLEAK_EARLY_LOG_SIZE is only 4, so it > disables kmemleak every time on this aarch64 server running the latest > mainline > (b00d209). > > # echo scan > /sys/kernel/debug/kme

Re: ODEBUG: Out of memory. ODEBUG disabled

2018-11-10 Thread Qian Cai
On 11/10/18 at 8:59 AM, Waiman Long wrote: > On 11/09/2018 08:45 PM, Qian Cai wrote: > >> Sent: Friday, November 09, 2018 at 5:08 PM > >> From: "Waiman Long" > >> To: "Qian Cai" , "Yang Shi" > >> Cc: "open list&qu

Re: kmemleak: Early log buffer exceeded (525980) during boot

2018-11-10 Thread Qian Cai
On 11/10/18 at 11:59 AM, Catalin Marinas wrote: > On Sat, Nov 10, 2018 at 10:08:10AM -0500, Qian Cai wrote: > > On Nov 8, 2018, at 4:23 PM, Qian Cai wrote: > > > The maximum value for DEBUG_KMEMLEAK_EARLY_LOG_SIZE is only 4, so it > > > disables kmemleak every

crashkernel=512M is no longer working on this aarch64 server

2018-11-10 Thread Qian Cai
It was broken somewhere between b00d209241ff and 3541833fd1f2. [0.00] cannot allocate crashkernel (size:0x2000) Where a good one looks like this, [0.00] crashkernel reserved: 0x0860 - 0x2860 (512 MB) Some commits look more suspicious than others.

Re: crashkernel=512M is no longer working on this aarch64 server

2018-11-11 Thread Qian Cai
> On Nov 11, 2018, at 6:35 AM, Martin Schwidefsky > wrote: > > On Sat, 10 Nov 2018 23:41:34 -0500 > Qian Cai wrote: > >> It was broken somewhere between b00d209241ff and 3541833fd1f2. >> >> [0.00] cannot allocate crashkernel (size:0x2000

Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150

2018-11-12 Thread Qian Cai
> On Nov 12, 2018, at 7:41 PM, Paul Moore wrote: > > On Mon, Nov 12, 2018 at 2:39 PM Qian Cai wrote: >> >> Running the trinity fuzzer on the latest mainline (rc2) generates this, >> >> [15029.879626] BUG: KASAN: slab-out-of-bounds in >&g

Re: ODEBUG: Out of memory. ODEBUG disabled

2018-11-12 Thread Qian Cai
> On Nov 10, 2018, at 9:11 AM, Qian Cai wrote: > > On 11/10/18 at 8:59 AM, Waiman Long wrote: > >> On 11/09/2018 08:45 PM, Qian Cai wrote: >>>> Sent: Friday, November 09, 2018 at 5:08 PM >>>> From: "Waiman Long" >>>> To:

Kernel panic - not syncing: corrupted stack end detected inside scheduler

2018-11-12 Thread Qian Cai
Running LTP oom01 [1] test triggered kernel panic on an aarch64 server with the latest mainline (rc2). [1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/oom/oom01.c [ 3433.338741] Kernel panic - not syncing: corrupted stack end detected inside scheduler [

Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150

2018-11-12 Thread Qian Cai
> On Nov 12, 2018, at 10:09 PM, Paul Moore wrote: > > On Mon, Nov 12, 2018 at 7:59 PM Qian Cai wrote: >>> On Nov 12, 2018, at 7:41 PM, Paul Moore wrote: >>> On Mon, Nov 12, 2018 at 2:39 PM Qian Cai wrote: >>>> >>>> Running the tr

Re: [PATCH] efi: permit calling efi_mem_reserve_persistent from atomic context

2018-11-11 Thread Qian Cai
> On Nov 9, 2018, at 9:45 PM, Qian Cai wrote: > > > On 11/8/18 at 1:05 PM, Ard Biesheuvel wrote: > >> Currently, efi_mem_reserve_persistent() may not be called from atomic >> context, since both the kmalloc() call and the memremap() call may >> sleep.

Re: crashkernel=512M is no longer working on this aarch64 server

2018-11-12 Thread Qian Cai
On 11/12/18 at 1:01 AM, Martin Schwidefsky wrote: > On Sun, 11 Nov 2018 08:36:09 -0500 > Qian Cai wrote: > > > > On Nov 11, 2018, at 6:35 AM, Martin Schwidefsky > > > wrote: > > > > > > On Sat, 10 Nov 2018 23:41:34 -0500 > > > Qian Cai

kernel BUG at include/linux/mm.h:519!

2018-11-13 Thread Qian Cai
Running the trinity fuzzer with a non-root user on an aarch64 server with the latest mainline (rc2) triggered this, [ 2058.662628] page:7fe022fe7d80 count:0 mapcount:0 mapping:808ea6153160 index:0x5a [ 2058.670842] flags: 0x9f04(uptodate) [ 2058.675448] raw: 9f04

WARNING: CPU: 26 PID: 64391 at lib/vsprintf.c:2193 set_precision+0x84/0x90

2018-11-13 Thread Qian Cai
Running the trinity fuzzer with a non-root user on an aarch64 server with the latest mainline (rc2) generated this. Is it just a false alarm to ignore? [  807.847370] precision 65525 too large [  807.847449] WARNING: CPU: 26 PID: 64391 at lib/vsprintf.c:2193 set_precision+0x84/0x90 [  807.860161]

WARNING: CPU: 31 PID: 15473 at lib/iov_iter.c:1109 iov_iter_pipe+0xe0/0xe8

2018-11-13 Thread Qian Cai
Running the trinity fuzzer with a non-root user on an aarch64 server with the latest mainline (rc2) generated this, [  378.743211] WARNING: CPU: 31 PID: 15473 at lib/iov_iter.c:1109 iov_iter_pipe+0xe0/0xe8 [  378.751590] Modules linked in: bridge 8021q garp mrp stp llc dlci tcp_diag inet_diag

Re: BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150

2018-11-13 Thread Qian Cai
On 11/13/18 at 8:33 AM, Paul Moore wrote: > On Mon, Nov 12, 2018 at 10:11 PM Qian Cai wrote: > > > On Nov 12, 2018, at 10:09 PM, Paul Moore wrote: > > > > > > On Mon, Nov 12, 2018 at 7:59 PM Qian Cai wrote: > > >>> On Nov 12, 2018, at 7:41 PM, Pa

Kernel panic - not syncing: corrupted stack end detected inside scheduler

2018-11-13 Thread Qian Cai
Running a runc testsuite [1] on an aarch64 server with the latest mainline (rc2) triggered this, [1] https://fedorapeople.org/cgit/caiqian/public_git/runctst.git/tree/runctst.py = # python runctst.py ... - start: runc ocf poststart load container root: container "root" does not

Re: ODEBUG: Out of memory. ODEBUG disabled

2018-11-13 Thread Qian Cai
> On Nov 12, 2018, at 11:33 PM, Qian Cai wrote: > > > >> On Nov 10, 2018, at 9:11 AM, Qian Cai wrote: >> >> On 11/10/18 at 8:59 AM, Waiman Long wrote: >> >>> On 11/09/2018 08:45 PM, Qian Cai wrote: >>>>> Sent: F

Re: kmemleak: Early log buffer exceeded (525980) during boot

2018-11-13 Thread Qian Cai
> On Nov 10, 2018, at 12:42 PM, Qian Cai wrote: > > > On 11/10/18 at 11:59 AM, Catalin Marinas wrote: > >> On Sat, Nov 10, 2018 at 10:08:10AM -0500, Qian Cai wrote: >>> On Nov 8, 2018, at 4:23 PM, Qian Cai wrote: >>>> The maximum value for DEBUG

WARNING: possible circular locking dependency detected

2018-11-13 Thread Qian Cai
Compiling kernel on an aarch64 server with the latest mainline (rc2) generated this, [ 910.263839] WARNING: possible circular locking dependency detected [ 910.263841] 4.20.0-rc2+ #4 Tainted: GWL [ 910.263843] -- [

BUG: KASAN: slab-out-of-bounds in try_to_unmap_one+0x1c4/0x1af0

2018-11-13 Thread Qian Cai
Compiling kernel on an aarch64 server with the latest mainline (rc2) triggered this, [ 1463.931841] BUG: KASAN: slab-out-of-bounds in try_to_unmap_one+0x1c4/0x1af0 [ 1463.938969] Write of size 32 at addr 80897ce87b58 by task kworker/u513:0/5209 [ 1463.946678] [ 1463.948656] CPU: 38 PID:

Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c

2018-11-09 Thread Qian Cai
> On Nov 9, 2018, at 8:50 AM, Marc Zyngier wrote: > > On 09/11/18 12:28, Qian Cai wrote: >> >> On 11/9/18 at 7:08 AM, Marc Zyngier wrote: >> >>> [+Ard] >>> >>> On 08/11/18 20:59, Qian Cai wrote: >>>> Just booting up

Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c

2018-11-09 Thread Qian Cai
On 11/9/18 at 7:08 AM, Marc Zyngier wrote: > [+Ard] > > On 08/11/18 20:59, Qian Cai wrote: > > Just booting up the latest git master (b00d209) on an aarch64 server and saw > > this. Not sure about the third warning (at kernel/cpu.c:315 > > lockdep_assert_cpus_held+0x

BUG: sleeping function called from invalid context at mm/slab.h:421

2018-11-08 Thread Qian Cai
Just booting up the latest git master (b00d209) on an aarch64 server and saw this. Nov 8 11:06:36 huawei-t2280-03 kernel: BUG: sleeping function called from invalid context at mm/slab.h:421 Nov 8 11:06:36 huawei-t2280-03 kernel: in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1

Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c

2018-11-09 Thread Qian Cai
> On Nov 9, 2018, at 10:38 AM, Marc Zyngier wrote: > > On 09/11/18 15:28, Qian Cai wrote: >> >> >>> On Nov 9, 2018, at 8:50 AM, Marc Zyngier wrote: >>> >>> On 09/11/18 12:28, Qian Cai wrote: >>>> >>>> On 11/9/18 at

Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c

2018-11-09 Thread Qian Cai
> On Nov 9, 2018, at 12:41 PM, Marc Zyngier wrote: > > On 09/11/18 17:28, Sudeep Holla wrote: >> On Fri, Nov 9, 2018 at 4:10 PM Marc Zyngier wrote: >>> >> [...] >> >>> >>> See bb42ca474010 and d003d029cea8 for details. >>> >>> Now, activating this workaround leads to lockdep being really

BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150

2018-11-12 Thread Qian Cai
Running the trinity fuzzer on the latest mainline (rc2) generates this, [15029.879626] BUG: KASAN: slab-out-of-bounds in selinux_sctp_bind_connect+0x60/0x150 [15029.887275] Read of size 2 at addr 801ec53c5080 by task trinity-main/18081 [15029.887294] [15029.887304] CPU: 28 PID: 18081 Comm:

Re: WARNING: CPU: 26 PID: 64391 at lib/vsprintf.c:2193 set_precision+0x84/0x90

2018-11-14 Thread Qian Cai
On Tue, 2018-11-13 at 14:23 -0500, Steven Rostedt wrote: > On Tue, 13 Nov 2018 13:58:18 -0500 > Qian Cai wrote: > > > > Care to print the len and name parameters before this line?   > > > > len = 60612; name = > > How big are pages on arm64? Because we sho

Re: WARNING: CPU: 26 PID: 64391 at lib/vsprintf.c:2193 set_precision+0x84/0x90

2018-11-13 Thread Qian Cai
On Tue, 2018-11-13 at 19:29 +0200, Andy Shevchenko wrote: > On Tue, Nov 13, 2018 at 11:55:32AM -0500, Qian Cai wrote: > > +Cc Rasmus > > > Running the trinity fuzzer with a non-root user on an aarch64 server with > > the > > latest mainline (rc2) generated

Re: [PATCH] selinux: check length properly in SCTP bind hook

2018-11-13 Thread Qian Cai
already checked in the > callees. > > Reported-by: Qian Cai > Fixes: d452930fd3b9 ("selinux: Add SCTP support") > Cc: # 4.17+ > Cc: Richard Haines > Signed-off-by: Ondrej Mosnacek Tested-by: Qian Cai > --- > Hi, > > On Mon, Nov 12, 2018 at 8:39 PM Qia

[PATCH] debugobjects: add a new Kconfig for POOL_SIZE

2018-11-18 Thread Qian Cai
"ODEBUG: Out of memory. ODEBUG disabled". Hence, add a new Kconfig option so users could adjust ODEBUG_POOL_SIZE accordingly if either timer or workqueue objects are selected. Signed-off-by: Qian Cai --- lib/Kconfig.debug | 12 lib/debugobjects.c | 7 ++- 2 files c

Re: [PATCH] debugobjects: add a new Kconfig for POOL_SIZE

2018-11-18 Thread Qian Cai
> On Nov 18, 2018, at 1:21 PM, Thomas Gleixner wrote: > > Qian, > > On Sun, 18 Nov 2018, Qian Cai wrote: > >> The current value of ODEBUG_POOL_SIZE is not big enough for large memory >> systems with timer or/and workqueue objects because during the earl

[PATCH v2] debugobjects: add a new Kconfig for POOL_SIZE

2018-11-18 Thread Qian Cai
As the results, systems have 60+ CPUs with both timer and workqueue objects enabled could trigger "ODEBUG: Out of memory. ODEBUG disabled". Hence, add a new Kconfig option so users could adjust ODEBUG_POOL_SIZE accordingly if either timer or workqueue objects are selected. Signed-off-by

[PATCH] dma-debug: hns_enet_drv could use more DMA entries

2018-11-29 Thread Qian Cai
(i = 0; i < handle->q_num; i++) [2] for (i = 0; i < ring->desc_num; i++) On this Huawei TaiShan 2280 aarch64 server, it has reached the limit already, 4 (ports) x 16 (handles) x 1024 (rings) = 65536 Signed-off-by: Qian Cai --- kernel/dma/debug.c | 5 + 1 file changed, 5 ins

Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c

2018-12-01 Thread Qian Cai
On 11/12/18 3:39 AM, Marc Zyngier wrote: > On Fri, 09 Nov 2018 18:41:03 +, > Qian Cai wrote: >> >> >> >>> On Nov 9, 2018, at 12:41 PM, Marc Zyngier wrote: >>> >>> On 09/11/18 17:28, Sudeep Holla wrote: >

[PATCH] checkstack.pl: fix for aarch64

2018-12-07 Thread Qian Cai
There is actually a space after "sp," like this, 280813c8: a9bb7bfdstp x29, x30, [sp, #-80]! Signed-off-by: Qian Cai --- scripts/checkstack.pl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/checkstack.pl b/scripts/checkstac

Re: [PATCH] checkstack.pl: fix for aarch64

2018-12-07 Thread Qian Cai
On Fri, 2018-12-07 at 12:24 -0800, Andrew Morton wrote: > On Fri,  7 Dec 2018 14:58:43 -0500 Qian Cai wrote: > > > There is actually a space after "sp," like this, > > > > 280813c8:   a9bb7bfdstp x29, x30, [sp, #-80]! > > &g

[PATCH] arm64: increase stack size for KASAN_EXTRA

2018-12-07 Thread Qian Cai
u.org/bugzilla/show_bug.cgi?id=81715#c23 Signed-off-by: Qian Cai --- arch/arm64/include/asm/memory.h | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h index b96442960aea..56562ff01076 100644 --- a/arch/ar

[PATCH] checkstack.pl: dynamic stack growth for aarch64

2018-12-07 Thread Qian Cai
) 0x2862e0d0 do_direct_IO [vmlinux]: Dynamic (0xb70) 0x28cc0aa0 md_do_sync [vmlinux]:Dynamic (0xb90) Signed-off-by: Qian Cai --- scripts/checkstack.pl | 2 ++ 1 file changed, 2 insertions(+) diff --git a/scripts/checkstack.pl b/scripts/checkstack.pl index

Re: [PATCH] clocksource/arm_arch_timer: fix a lockdep warning

2018-12-03 Thread Qian Cai
On Mon, 2018-12-03 at 15:07 -0500, Waiman Long wrote: > On 12/03/2018 02:33 PM, Qian Cai wrote: > > Booting this Huawei TaiShan 2280 arm64 server generated this lockdep > > warning. > > > > [0.00]  lockdep_assert_cpus_held+0x50/0x60 > > [0.00]  

[PATCH] clocksource/arm_arch_timer: fix a lockdep warning

2018-12-03 Thread Qian Cai
Signed-off-by: Qian Cai --- drivers/clocksource/arm_arch_timer.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index 9a7d4dc..5c9acbd 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/c

[RESEND PATCH] drivers/base: kmemleak ignore a known leak

2018-12-06 Thread Qian Cai
.dma_mask = kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL); Since this leak has been existed for more than 8-year now and it does not reference other part of the memory, let kmemleak ignore it, so users don't need to waste time reporting this in the future. Signed-off-by: Qian Cai ---

[PATCH] drivers/base: kmemleak ignore a known leak

2018-11-29 Thread Qian Cai
.dma_mask = kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL); Since this leak has been existed for more than 8-year now and it does not reference other part of the memory, let kmemleak ignore it, so users don't need to waste time reporting this in the future. Signed-off-by: Qian Cai ---

[PATCH v2] clocksource/arm_arch_timer: fix a lockdep warning

2018-12-03 Thread Qian Cai
ence, deal with them differently. Fixes: 450f9689f294 (clocksource/arm_arch_timer: Use static_branch_enable_cpuslocked()) Signed-off-by: Qian Cai --- Changes since v1: * Fixed the root cause instead of a workaround. drivers/clocksource/arm_arch_timer.c | 15 +-- 1 file

Re: [PATCH] debugobjects: call debug_objects_mem_init eariler

2018-11-23 Thread Qian Cai
> On Nov 23, 2018, at 4:46 PM, Thomas Gleixner wrote: > > On Thu, 22 Nov 2018, Waiman Long wrote: >> On 11/22/2018 11:31 PM, Qian Cai wrote: >>> The current value of the early boot static pool size, 1024 is not big >>> enough for systems with large number of

Re: [PATCH v4] debugobjects: scale the static pool size

2018-11-23 Thread Qian Cai
> On Nov 22, 2018, at 4:56 PM, Thomas Gleixner wrote: > > On Tue, 20 Nov 2018, Qian Cai wrote: > > Looking deeper at that. > >> diff --git a/lib/debugobjects.c b/lib/debugobjects.c >> index 70935ed91125..140571aa483c 100644 >> --- a/lib/debugobjects.c >

[PATCH v2] debugobjects: scale the static pool size

2018-11-20 Thread Qian Cai
abled". Hence, fixed it by computing it according to CONFIG_NR_CPUS and CONFIG_DEBUG_OBJECTS_* options. Signed-off-by: Qian Cai --- Changes since v1: * Removed the CONFIG_NR_CPUS check since it is always defined. * Introduced a minimal default pool size to start with. Otherwise, the pool size wo

[PATCH v4] debugobjects: scale the static pool size

2018-11-20 Thread Qian Cai
abled". Hence, fixed it by computing it according to CONFIG_NR_CPUS and CONFIG_DEBUG_OBJECTS_* options. Signed-off-by: Qian Cai --- Changes since v3: * style fixes Changes since v2: * Made the calculation easier to read suggested by long...@redhat.com. Changes since v1: * Removed the CONFIG_NR_

[PATCH v3] debugobjects: scale the static pool size

2018-11-20 Thread Qian Cai
abled". Hence, fixed it by computing it according to CONFIG_NR_CPUS and CONFIG_DEBUG_OBJECTS_* options. Signed-off-by: Qian Cai --- Changes since v2: * Made the calculation easier to read suggested by long...@redhat.com. Changes since v1: * Removed the CONFIG_NR_CPUS check since it is alwa

Re: [PATCH v3] debugobjects: scale the static pool size

2018-11-20 Thread Qian Cai
On 11/20/18 at 6:38 PM, Waiman Long wrote: > On 11/20/2018 06:28 PM, Qian Cai wrote: > > The current value of the early boot static pool size is not big enough > > for systems with large number of CPUs with timer or/and workqueue > > objects selected. As the results,

[PATCH] debugobjects: scale the static pool size

2018-11-19 Thread Qian Cai
abled". Hence, fixed it by computing it according to CONFIG_NR_CPUS and CONFIG_DEBUG_OBJECTS_* options. Signed-off-by: Qian Cai --- lib/debugobjects.c | 53 +- 1 file changed, 52 insertions(+), 1 deletion(-) diff --git a/lib/debugobjects.c b/lib/debu

Re: [PATCH v4] debugobjects: scale the static pool size

2018-11-25 Thread Qian Cai
On 11/25/18 8:31 PM, Waiman Long wrote: On 11/25/2018 03:42 PM, Qian Cai wrote: On 11/23/18 10:01 PM, Qian Cai wrote: On Nov 22, 2018, at 4:56 PM, Thomas Gleixner wrote: On Tue, 20 Nov 2018, Qian Cai wrote: Looking deeper at that. diff --git a/lib/debugobjects.c b/lib

[PATCH v3] debugobjects: call debug_objects_mem_init eariler

2018-11-26 Thread Qian Cai
ater than today." Suggested-by: Thomas Gleixner Signed-off-by: Qian Cai --- Changes since v2: * Restored an accidentally deleted comment. since v1: * Added some comments about interrupts. init/main.c| 2 +- lib/debugobjects.c | 8 +++- 2 files changed, 4 insertions(+), 6 deletions(-

Re: [PATCH v4] debugobjects: scale the static pool size

2018-11-26 Thread Qian Cai
On 11/25/18 11:52 PM, Qian Cai wrote: On 11/25/18 8:31 PM, Waiman Long wrote: On 11/25/2018 03:42 PM, Qian Cai wrote: On 11/23/18 10:01 PM, Qian Cai wrote: On Nov 22, 2018, at 4:56 PM, Thomas Gleixner wrote: On Tue, 20 Nov 2018, Qian Cai wrote: Looking deeper at that. diff

[PATCH v2] debugobjects: call debug_objects_mem_init eariler

2018-11-26 Thread Qian Cai
ater than today." Suggested-by: Thomas Gleixner Signed-off-by: Qian Cai --- Changes since v1: * Added some comments about interrupts. init/main.c| 2 +- lib/debugobjects.c | 9 +++-- 2 files changed, 4 insertions(+), 7 deletions(-) diff --git a/init/main.c b/init/main.c index ee1471

Re: kmemleak: Early log buffer exceeded (525980) during boot

2018-11-27 Thread Qian Cai
On 11/10/18 11:59 AM, Catalin Marinas wrote: > On Sat, Nov 10, 2018 at 10:08:10AM -0500, Qian Cai wrote: >> On Nov 8, 2018, at 4:23 PM, Qian Cai wrote: >>> The maximum value for DEBUG_KMEMLEAK_EARLY_LOG_SIZE is only 4, so it >>> disables kmemleak every time on

[PATCH] debugobjects: call debug_objects_mem_init eariler

2018-11-22 Thread Qian Cai
rwards, when calling debug_objects_mem_init(), interrupts have already been disabled and lockdep_init() will only be called later, so no need to worry about interrupts in debug_objects_replace_static_objects(). Suggested-by: Thomas Gleixner Signed-off-by: Qian Cai --- init/main.c| 3 ++- li

Re: [PATCH] debugobjects: scale the static pool size

2018-11-20 Thread Qian Cai
> On Nov 20, 2018, at 8:50 AM, Waiman Long wrote: > > On 11/20/2018 01:42 AM, Qian Cai wrote: >> The current value of the early boot static pool size is not big enough >> for systems with large number of CPUs with timer or/and workqueue >> objects selected. As t

[PATCH] debugobjects: avoid recursive calls with kmemleak

2018-11-26 Thread Qian Cai
fill_pool kmemleak_ignore make_black_object ... Hence, adding SLAB_NOLEAKTRACE to kmem_cache_create() to not register a newly allocated debug objects at all. Suggested-by: Catalin Marinas Signed-off-by: Qian Cai --- lib

[PATCH] mm/memblock: skip kmemleak for kasan_init()

2018-11-28 Thread Qian Cai
*pmdp))) \ while (ptep++, addr = next, addr != end && pte_none(READ_ONCE(*ptep))) Signed-off-by: Qian Cai --- mm/memblock.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/memblock.c b/mm/memblock.c index 9a2d5ae..fd78e39 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -1412,6 +

[PATCH v2] mm/memblock: skip kmemleak for kasan_init()

2018-11-28 Thread Qian Cai
5] while (ptep++, addr = next, addr != end && pte_none(READ_ONCE(*ptep))) Signed-off-by: Qian Cai --- Changes since v1: * only skip memblock_alloc_internal() calls came from kasan_int(). arch/arm64/mm/kasan_init.c | 2 +- include/linux/memblock.h | 1 + mm/memblock.c | 1

Re: [PATCH] debugobjects: add a new Kconfig for POOL_SIZE

2018-11-19 Thread Qian Cai
On Mon, 2018-11-19 at 17:25 +0100, Thomas Gleixner wrote: > On Mon, 19 Nov 2018, Waiman Long wrote: > > On 11/19/2018 10:17 AM, Qian Cai wrote: > > > Right, I can remember that now . However, if I understand correctly, since > > > the > > > early static poo

Re: [PATCH v4] debugobjects: scale the static pool size

2018-11-25 Thread Qian Cai
On 11/23/18 10:01 PM, Qian Cai wrote: On Nov 22, 2018, at 4:56 PM, Thomas Gleixner wrote: On Tue, 20 Nov 2018, Qian Cai wrote: Looking deeper at that. diff --git a/lib/debugobjects.c b/lib/debugobjects.c index 70935ed91125..140571aa483c 100644 --- a/lib/debugobjects.c +++ b/lib

Re: [PATCH v4] debugobjects: scale the static pool size

2018-11-25 Thread Qian Cai
On 11/22/18 4:56 PM, Thomas Gleixner wrote: On Tue, 20 Nov 2018, Qian Cai wrote: Looking deeper at that. diff --git a/lib/debugobjects.c b/lib/debugobjects.c index 70935ed91125..140571aa483c 100644 --- a/lib/debugobjects.c +++ b/lib/debugobjects.c @@ -23,9 +23,81 @@ #define

Re: [PATCH] debugobjects: add a new Kconfig for POOL_SIZE

2018-11-19 Thread Qian Cai
On 11/19/18 at 3:09 AM, Thomas Gleixner wrote: > Qian, > > On Sun, 18 Nov 2018, Qian Cai wrote: > > > On Nov 18, 2018, at 1:21 PM, Thomas Gleixner wrote: > > > On Sun, 18 Nov 2018, Qian Cai wrote: > > >> As the results, systems have 60+ CPUs with both tim

Re: [PATCH] debugobjects: add a new Kconfig for POOL_SIZE

2018-11-19 Thread Qian Cai
On Mon, 2018-11-19 at 09:51 -0500, Waiman Long wrote: > On 11/19/2018 08:27 AM, Qian Cai wrote: > > On 11/19/18 at 3:09 AM, Thomas Gleixner wrote: > > > > > Qian, > > > > > > On Sun, 18 Nov 2018, Qian Cai wrote: > > > > > On N