Afterwards, 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 ++
> 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
> 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
>
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
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
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
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
way later 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 e
way later 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 deleti
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
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
> 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
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
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
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, syste
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_
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
*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 +
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
gt;dev.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
(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 inser
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
"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
> 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 early
&
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
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
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
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 pool si
> 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.
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
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:
> 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
> 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 trinity
> 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:
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
[ 3433.3476
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, Paul
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 af_k
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 de
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]
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 thi
27;len') is 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,
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 exist
> 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: Friday, Nove
> 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_KM
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] --
[ 910.263844]
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: 520
gt;dev.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
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
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]!
> >
>
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
)
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
red the out-of-bound access.
Fixes: 51087a8617fe (megaraid_sas : Extended VD support)
Signed-off-by: Qian Cai
---
drivers/scsi/megaraid/megaraid_sas_fp.c | 2 +-
drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/
e to "rsv" will only
reference to other physical addresses,
rsv->next = efi_memreserve_root->next;
efi_memreserve_root->next = __pa(rsv);
Signed-off-by: Qian Cai
---
drivers/firmware/efi/efi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/firmware/efi/efi.c
On Thu, 2018-12-06 at 19:01 +0100, Ard Biesheuvel wrote:
> On Thu, 6 Dec 2018 at 19:00, Catalin Marinas wrote:
> >
> > On Thu, Dec 06, 2018 at 11:16:33AM -0500, Qian Cai wrote:
> > > unreferenced object 0x8096c1acf580 (size 128):
> > > comm "swapp
red the out-of-bound accesses.
Fixes: 51087a8617fe (megaraid_sas : Extended VD support)
Signed-off-by: Qian Cai
---
v2: fix the right place in megaraid_sas_fusion.c.
drivers/scsi/megaraid/megaraid_sas_fp.c | 2 +-
drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +-
2 files changed, 2 insert
On 12/7/18 at 6:28 AM, Ard Biesheuvel wrote:
> On Thu, 6 Dec 2018 at 19:05, Qian Cai wrote:
> >
> > On Thu, 2018-12-06 at 19:01 +0100, Ard Biesheuvel wrote:
> > > On Thu, 6 Dec 2018 at 19:00, Catalin Marinas
> > > wrote:
> > > >
> > >
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:
>
ned-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
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]
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
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
> 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
> 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
> 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
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 w
> 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 memo
> 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&
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
> 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
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
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.
> 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
On 12/11/18 6:06 PM, Arnd Bergmann wrote:
>> I am thinking about something it is probably best just waiting for those
>> major
>> distors to complete upgrading to GCC9 or back-porting those stack reduction
>> patches first. Then, it is good time to tie up loose ends for those default
>> stack s
uninitialized junk which just happened to look valid) from the first
kernel before turning the MMU on in the second kernel which caused this
instruction hung,
msr sctlr_el1, x0
Signed-off-by: Qian Cai
---
arch/arm64/kernel/head.S | 4
1 file changed, 4 insertions(+)
diff --git a/arch
ixes: 51087a8617fe (megaraid_sas : Extended VD support)
Signed-off-by: Qian Cai
---
drivers/scsi/megaraid/megaraid_sas_fp.c | 2 +-
drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c
b/drivers
On Thu, 2018-12-13 at 11:10 +0530, Bhupesh Sharma wrote:
> Hi Qian Cai,
>
> On Thu, Dec 13, 2018 at 10:53 AM Qian Cai wrote:
> >
> > On this HPE Apollo 70 arm64 server with 256 CPUs, triggering a crash
> > dump just hung. It has 4 threads on each core. Each 2-core
On Thu, 2018-12-13 at 10:44 +, James Morse wrote:
> The kernel should already handle this, as we don't trust the bootloader to
> clean
> up either.
>
> In arch/arm64/mm/proc.S::__cpu_setup()
> > /*
> > * __cpu_setup
> > *
> > * Initialise the processor for turning the MMU on. Return in x0
rning the
MMU on, just re-arrage the part a bit like the one in __primary_switch()
within CONFIG_RANDOMIZE_BASE path, so it does not depends on other
instructions in between that could pollute the TLB, and it no longer
trigger "Synchronous Exception" as well.
Signed-off-by: Qian Cai
d propose a more sophisticated solution later, but this is
> the best I can do for now.
>
> Link: https://lkml.org/lkml/2017/12/25/211
> Reported-by: Paul Gortmaker
> Reported-by: Bernd Edlinger
> Reported-by: Qian Cai
> Cc: Josh Poimboeuf
> Signed-off-by: Masahiro Ya
page_to_nid
PF_POISONED_CHECK <--- panic here.
This because all allocated pages are not initialized until later.
init_pages_in_zone
__set_page_owner_handle
Fixes: f165b378bbd (mm: uninitialized struct page poisoning
sanity checking)
Signed-off-by: Qian Cai
---
incl
On 12/19/18 5:20 AM, Michal Hocko wrote:
> On Tue 18-12-18 20:57:32, Qian Cai wrote:
> [...]
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 5411de93a363..f083f366ea90 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -98
ound early allocated 7545357 pages
Node 1, zone Normal: page owner found early allocated 8331279 pages
Finally, rename get_entry() to get_ext_entry(), so it can be exported
without a naming collision.
Signed-off-by: Qian Cai
---
include/linux/page_ext.h | 6 ++
mm/page_ext.c
On 12/14/18 12:01 AM, Bhupesh Sharma wrote:
> Not sure why I can't reproduce on my HPE Apollo machine, so a couple
> of questions:
> 1. How many CPUs do you enable in the kdump kernel - do you pass
> 'nr_cpus=1' to the kdump kernel to limit the maximum number of cores
> to 1 in the kdump kernel?
Y
On 12/10/18 4:31 PM, Thomas Gleixner wrote:
> On Mon, 10 Dec 2018, Peter Zijlstra wrote:
>> On Mon, Dec 10, 2018 at 08:52:28AM -0500, Qian Cai wrote:
>>> Booting this Huawei TaiShan 2280 arm64 server generated this lockdep
>>> warning.
>>>
>>> [
On 12/14/18 2:23 AM, Ard Biesheuvel wrote:
> On Fri, 14 Dec 2018 at 05:08, Qian Cai wrote:
>> Also tried to move the local TLB flush part around a bit inside
>> __cpu_setup(), although it did complete kdump some times, it did trigger
>> "Synchronous Exception" in
This bug can be reproduced this way on x86_64.
* make sure none of libelf-dev, libelf-devel or elfutils-libelf-devel installed.
# make distclean
* generate a default .config where CONFIG_UNWINDER_ORC is enabled by default.
# make menuconfig (exit -> save)
# grep CONFIG_UNWINDER_ORC .config
CONF
for CONFIG_UNWINDER_ORC=y, please install
libelf-dev, libelf-devel or elfutils-libelf-devel
# grep CONFIG_UNWINDER_ORC include/config/auto.conf
CONFIG_UNWINDER_ORC=y
Fixes: 3dd40cb320f (objtool: Upgrade libelf-devel warning to error for
CONFIG_ORC_UNWINDER)
Signed-off-by: Qian Cai
---
Makefile
On Mon, 2018-12-17 at 11:03 -0600, Josh Poimboeuf wrote:
> On Mon, Dec 17, 2018 at 11:17:28AM -0500, Qian Cai wrote:
> > Since ifdef will be evaluated immediately in the first phrase of the
> > Makefile read-in, there is no guarantee that the value for
> > CONFIG_ORC_UNWIND
On Mon, 2018-12-17 at 11:49 -0600, Josh Poimboeuf wrote:
> On Mon, Dec 17, 2018 at 12:13:59PM -0500, Qian Cai wrote:
> > On Mon, 2018-12-17 at 11:03 -0600, Josh Poimboeuf wrote:
> > > On Mon, Dec 17, 2018 at 11:17:28AM -0500, Qian Cai wrote:
> > > > Since ifdef will b
timer: Use
static_branch_enable_cpuslocked())
Signed-off-by: Qian Cai
---
v2: fix the root cause instead of a workaround.
drivers/clocksource/arm_arch_timer.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c
b/drivers/c
On 12/10/18 9:07 AM, Peter Zijlstra wrote:
> On Mon, Dec 10, 2018 at 08:52:28AM -0500, Qian Cai wrote:
>> Booting this Huawei TaiShan 2280 arm64 server generated this lockdep
>> warning.
>>
>> [0.00] lockdep_assert_cpus_held+0x50/0x60
>> [0.00]
| 7 -
> kernel/dma/debug.c | 217 ++
> 5 files changed, 109 insertions(+), 163 deletions(-)
>
Tested-by: Qian Cai
On Tue, 2018-12-11 at 13:42 +0100, Arnd Bergmann wrote:
> On Fri, Dec 7, 2018 at 11:35 PM Qian Cai wrote:
> >
> > If the kernel is configured with KASAN_EXTRA, the stack size is
> > increasted significantly due to enable this option will set
> > -fstack-reuse to "
On Tue, 2018-12-11 at 22:43 +0100, Arnd Bergmann wrote:
> On Tue, Dec 11, 2018 at 6:18 PM Qian Cai wrote:
> >
> > On Tue, 2018-12-11 at 13:42 +0100, Arnd Bergmann wrote:
> > > On Fri, Dec 7, 2018 at 11:35 PM Qian Cai wrote:
> > > >
> > > > I
On Tue, 2018-12-11 at 22:56 +0100, Arnd Bergmann wrote:
> On Tue, Dec 11, 2018 at 10:52 PM Qian Cai wrote:
> > On Tue, 2018-12-11 at 22:43 +0100, Arnd Bergmann wrote:
> > > On Tue, Dec 11, 2018 at 6:18 PM Qian Cai wrote:
> > I am not too keen to do the version-check consi
On Tue, 2018-12-11 at 23:12 +0100, Arnd Bergmann wrote:
> On Tue, Dec 11, 2018 at 10:59 PM Qian Cai wrote:
> >
> > On Tue, 2018-12-11 at 22:56 +0100, Arnd Bergmann wrote:
> > > On Tue, Dec 11, 2018 at 10:52 PM Qian Cai wrote:
> > > > On Tue, 2018-12-11
kernel() and no real benefit to call it so early, just move it
after page_alloc_init_late() to ensure that there is no deferred pages
need to de dealt with.
Suggested-by: Michal Hocko
Signed-off-by: Qian Cai
---
v2: postpone init_page_ext() to after page_alloc_init_late().
init/main.c | 2 +
d compromise between catching good and bad
call sites (See the v1 patch [1]) in case of DEFERRED_STRUCT_PAGE_INIT.
[1] https://lore.kernel.org/lkml/20181220060303.38686-1-...@lca.pw/
Fixes: fe53ca54270 (mm: use early_pfn_to_nid in page_ext_init)
Suggested-by: Michal Hocko
Signed-off-by: Qian Cai
On Thu, 2018-12-20 at 14:00 -0700, William Kucharski wrote:
> > On Dec 20, 2018, at 1:31 PM, Qian Cai wrote:
> >
> > diff --git a/mm/page_ext.c b/mm/page_ext.c
> > index ae44f7adbe07..d76fd51e312a 100644
> > --- a/mm/page_ext.c
> > +++ b/mm/page_ext.c
On 1/4/19 10:32 AM, Michal Hocko wrote:
> On Fri 04-01-19 10:25:12, Qian Cai wrote:
>> On 1/4/19 10:17 AM, Michal Hocko wrote:
>>> On Fri 04-01-19 10:01:40, Qian Cai wrote:
>>>> On 1/4/19 8:09 AM, Michal Hocko wrote:
>>>>>> Here
1 - 100 of 1130 matches
Mail list logo
