diff mbox

[v9,1/6] arm64: Add macros to manage processor debug state

Message ID 1390908022-10287-2-git-send-email-vijay.kilari@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Vijay Kilari Jan. 28, 2014, 11:20 a.m. UTC 
From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>

Add macros to enable and disable to manage PSTATE.D
for debugging. The macros local_dbg_save and local_dbg_restore
are moved to irqflags.h file

KGDB boot tests fail because of PSTATE.D is masked.
unmask it for debugging support

Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
---
 arch/arm64/include/asm/debug-monitors.h |   17 -----------------
 arch/arm64/include/asm/irqflags.h       |   23 +++++++++++++++++++++++
 arch/arm64/kernel/debug-monitors.c      |    1 +
 3 files changed, 24 insertions(+), 17 deletions(-)

Comments

Will Deacon Jan. 29, 2014, 10:55 a.m. UTC | #1 
On Tue, Jan 28, 2014 at 11:20:17AM +0000, vijay.kilari@gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
> 
> Add macros to enable and disable to manage PSTATE.D
> for debugging. The macros local_dbg_save and local_dbg_restore
> are moved to irqflags.h file
> 
> KGDB boot tests fail because of PSTATE.D is masked.
> unmask it for debugging support
> 
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>

Acked-by: Will Deacon <will.deacon@arm.com>

Cheers,

Will
Vijay Kilari Feb. 17, 2014, 12:21 p.m. UTC | #2 
Hi Catalin,

   If it is ok, can you please merge these patches

Regards
Vijay

On Wed, Jan 29, 2014 at 4:25 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Jan 28, 2014 at 11:20:17AM +0000, vijay.kilari@gmail.com wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>>
>> Add macros to enable and disable to manage PSTATE.D
>> for debugging. The macros local_dbg_save and local_dbg_restore
>> are moved to irqflags.h file
>>
>> KGDB boot tests fail because of PSTATE.D is masked.
>> unmask it for debugging support
>>
>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>
> Acked-by: Will Deacon <will.deacon@arm.com>
>
> Cheers,
>
> Will
Catalin Marinas Feb. 17, 2014, 1:01 p.m. UTC | #3 
On Mon, Feb 17, 2014 at 12:21:45PM +0000, Vijay Kilari wrote:
>    If it is ok, can you please merge these patches

I was about to merge them but I wanted to try first. Enabling kgd tests
at boot time, I get plenty of failures as below. Have you successfully
run the kgdb tests?

kgdbts:RUN singlestep [800/1000]
kgdbts: ERROR PUT: end of test buffer on 'singlestep_breakpoint_test' line 0 expected S0* got $T05thread:01;#07
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1 at /work/Linux/linux-2.6-aarch64/drivers/misc/kgdbts.c:815 run_simple_test+0x28c/0x2d8()
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W    3.14.0-rc3+ #300
Call trace:
[<ffffffc000087dbc>] dump_backtrace+0x0/0x12c
[<ffffffc000087efc>] show_stack+0x14/0x1c
[<ffffffc00044582c>] dump_stack+0x78/0xc4
[<ffffffc00009552c>] warn_slowpath_common+0x88/0xac
[<ffffffc000095618>] warn_slowpath_null+0x18/0x20
[<ffffffc0002f5cb0>] run_simple_test+0x28c/0x2d8
[<ffffffc0002f5268>] kgdbts_put_char+0x24/0x2c
[<ffffffc0000fcdf8>] put_packet+0xa0/0x118
[<ffffffc0000fe0e0>] gdb_serial_stub+0xb4c/0xd20
[<ffffffc0000fc434>] kgdb_cpu_enter+0x3bc/0x5f4
[<ffffffc0000fc934>] kgdb_handle_exception+0x18c/0x1f0
[<ffffffc000090d50>] kgdb_compiled_brk_fn+0x2c/0x38
[<ffffffc000082158>] brk_handler+0x8c/0xc4
[<ffffffc0000811ec>] do_debug_exception+0x40/0xac
Exception stack(0xffffffc876cbbb80 to 0xffffffc876cbbca0)
bb80: 006a0000 ffffffc0 000003e8 00000000 76cbbd40 ffffffc8 000fb9b8 ffffffc0
bba0: 000002c0 00000000 000d18cc ffffffc0 76cbbc10 ffffffc8 000d1c40 ffffffc0
bbc0: 00641000 ffffffc0 00000001 00000000 00610d40 ffffffc0 00000006 00000000
bbe0: 00000240 00000000 00000020 00000000 00000000 00000000 00000000 00000000
bc00: 76cbbc10 ffffffc8 00000021 00000000 76cbbcb0 ffffffc8 0044337c ffffffc0
bc20: 00648e58 ffffffc0 00000001 00000000 00000000 00000000 00648e60 ffffffc0
bc40: 000070e1 00000000 00000006 00000000 00000030 00000000 006431b0 ffffffc0
bc60: 000070e0 00000000 00000006 00000000 0000006c 00000000 00007005 00000000
bc80: 00000040 00000000 00003648 00000000 00000000 00000000 00000006 00000000
[<ffffffc000083cb4>] el1_dbg+0x18/0x68
[<ffffffc0005d010c>] init_kgdbts+0x24/0x2c
[<ffffffc000081430>] do_one_initcall+0xdc/0x124
[<ffffffc0005b8930>] kernel_init_freeable+0x138/0x1d8
[<ffffffc000440850>] kernel_init+0x10/0xd4
Vijay Kilari Feb. 18, 2014, 11:29 a.m. UTC | #4 
On Mon, Feb 17, 2014 at 6:31 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Mon, Feb 17, 2014 at 12:21:45PM +0000, Vijay Kilari wrote:
>>    If it is ok, can you please merge these patches
>
> I was about to merge them but I wanted to try first. Enabling kgd tests
> at boot time, I get plenty of failures as below. Have you successfully
> run the kgdb tests?
>

  I re-tested v9 version patches with our internal arm64 simulator and
I don't see these warnings. Also I tested with 3.13 kernel from linaro with v8
foundation model and no errors are seen (logs below).

kgdb: Registered I/O driver kgdbts.
kgdbts:RUN plant and detach test
kgdbts:RUN sw breakpoint test
kgdbts:RUN bad memory access test
kgdbts:RUN singlestep test 1000 iterations
kgdbts:RUN singlestep [0/1000]
kgdbts:RUN singlestep [100/1000]
kgdbts:RUN singlestep [200/1000]
kgdbts:RUN singlestep [300/1000]
kgdbts:RUN singlestep [400/1000]
kgdbts:RUN singlestep [500/1000]
kgdbts:RUN singlestep [600/1000]
kgdbts:RUN singlestep [700/1000]
kgdbts:RUN singlestep [800/1000]
kgdbts:RUN singlestep [900/1000]
kgdbts:RUN do_fork for 100 breakpoints
smc91x 1a000000.ethernet (unregistered net_device): smc91x: IOADDR
ffffff800006a000 doesn't match configuration (300).
.....
EXT4-fs (vda2): re-mounted. Opts: (null)
random: dd urandom read with 13 bits of entropy available
kgdb: Unregistered I/O driver kgdbts, debugger disabled.
smc91x 1a000000.ethernet eth0: link up, 10Mbps, half-duplex, lpa 0x0000
rpcbind: cannot create socket for udp6
rpcbind: cannot create socket for tcp6

Last login: Wed Feb  5 09:32:00 UTC 2014 on tty1
root@genericarmv8:~# uname -a
Linux genericarmv8 3.13.0+ #2 SMP PREEMPT Tue Feb 18 15:53:10 IST 2014
aarch64 GNU/Linux
root@genericarmv8:~#

NOTE: Please check if you have applied all the latest version patches

> kgdbts:RUN singlestep [800/1000]
> kgdbts: ERROR PUT: end of test buffer on 'singlestep_breakpoint_test' line 0 expected S0* got $T05thread:01;#07
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 1 at /work/Linux/linux-2.6-aarch64/drivers/misc/kgdbts.c:815 run_simple_test+0x28c/0x2d8()
> Modules linked in:
> CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W    3.14.0-rc3+ #300
> Call trace:
> [<ffffffc000087dbc>] dump_backtrace+0x0/0x12c
> [<ffffffc000087efc>] show_stack+0x14/0x1c
> [<ffffffc00044582c>] dump_stack+0x78/0xc4
> [<ffffffc00009552c>] warn_slowpath_common+0x88/0xac
> [<ffffffc000095618>] warn_slowpath_null+0x18/0x20
> [<ffffffc0002f5cb0>] run_simple_test+0x28c/0x2d8
> [<ffffffc0002f5268>] kgdbts_put_char+0x24/0x2c
> [<ffffffc0000fcdf8>] put_packet+0xa0/0x118
> [<ffffffc0000fe0e0>] gdb_serial_stub+0xb4c/0xd20
> [<ffffffc0000fc434>] kgdb_cpu_enter+0x3bc/0x5f4
> [<ffffffc0000fc934>] kgdb_handle_exception+0x18c/0x1f0
> [<ffffffc000090d50>] kgdb_compiled_brk_fn+0x2c/0x38
> [<ffffffc000082158>] brk_handler+0x8c/0xc4
> [<ffffffc0000811ec>] do_debug_exception+0x40/0xac
> Exception stack(0xffffffc876cbbb80 to 0xffffffc876cbbca0)
> bb80: 006a0000 ffffffc0 000003e8 00000000 76cbbd40 ffffffc8 000fb9b8 ffffffc0
> bba0: 000002c0 00000000 000d18cc ffffffc0 76cbbc10 ffffffc8 000d1c40 ffffffc0
> bbc0: 00641000 ffffffc0 00000001 00000000 00610d40 ffffffc0 00000006 00000000
> bbe0: 00000240 00000000 00000020 00000000 00000000 00000000 00000000 00000000
> bc00: 76cbbc10 ffffffc8 00000021 00000000 76cbbcb0 ffffffc8 0044337c ffffffc0
> bc20: 00648e58 ffffffc0 00000001 00000000 00000000 00000000 00648e60 ffffffc0
> bc40: 000070e1 00000000 00000006 00000000 00000030 00000000 006431b0 ffffffc0
> bc60: 000070e0 00000000 00000006 00000000 0000006c 00000000 00007005 00000000
> bc80: 00000040 00000000 00003648 00000000 00000000 00000000 00000006 00000000
> [<ffffffc000083cb4>] el1_dbg+0x18/0x68
> [<ffffffc0005d010c>] init_kgdbts+0x24/0x2c
> [<ffffffc000081430>] do_one_initcall+0xdc/0x124
> [<ffffffc0005b8930>] kernel_init_freeable+0x138/0x1d8
> [<ffffffc000440850>] kernel_init+0x10/0xd4
>
> --
> Catalin
Catalin Marinas Feb. 18, 2014, 12:02 p.m. UTC | #5 
On Tue, Feb 18, 2014 at 11:29:40AM +0000, Vijay Kilari wrote:
> On Mon, Feb 17, 2014 at 6:31 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Mon, Feb 17, 2014 at 12:21:45PM +0000, Vijay Kilari wrote:
> >>    If it is ok, can you please merge these patches
> >
> > I was about to merge them but I wanted to try first. Enabling kgd tests
> > at boot time, I get plenty of failures as below. Have you successfully
> > run the kgdb tests?
> 
>   I re-tested v9 version patches with our internal arm64 simulator and
> I don't see these warnings. Also I tested with 3.13 kernel from linaro with v8
> foundation model and no errors are seen (logs below).

It's good to know. Could you please rebase against 3.14-rc3 and rerun
the tests? If they work, please send me your .config file that you used
with the foundation model.

(and since you rebase on 3.14-rc3, you could repost a v10 with all the
acks in place so that it's easier for me to merge)

Thanks.
Vijay Kilari Feb. 19, 2014, 4:44 a.m. UTC | #6 
On Tue, Feb 18, 2014 at 5:32 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Tue, Feb 18, 2014 at 11:29:40AM +0000, Vijay Kilari wrote:
>> On Mon, Feb 17, 2014 at 6:31 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>> > On Mon, Feb 17, 2014 at 12:21:45PM +0000, Vijay Kilari wrote:
>> >>    If it is ok, can you please merge these patches
>> >
>> > I was about to merge them but I wanted to try first. Enabling kgd tests
>> > at boot time, I get plenty of failures as below. Have you successfully
>> > run the kgdb tests?
>>
>>   I re-tested v9 version patches with our internal arm64 simulator and
>> I don't see these warnings. Also I tested with 3.13 kernel from linaro with v8
>> foundation model and no errors are seen (logs below).
>
> It's good to know. Could you please rebase against 3.14-rc3 and rerun
> the tests? If they work, please send me your .config file that you used
> with the foundation model.
>
> (and since you rebase on 3.14-rc3, you could repost a v10 with all the
> acks in place so that it's easier for me to merge)
>

 Reposted v10 version of patches which is rebased on 3.14-rc3 kernel.
Test results are as follows on v8 foundation model.

 vda: vda1 vda2
kgdb: Registered I/O driver kgdbts.
kgdbts:RUN plant and detach test
kgdbts:RUN sw breakpoint test
kgdbts:RUN bad memory access test
kgdbts:RUN singlestep test 1000 iterations
kgdbts:RUN singlestep [0/1000]
kgdbts:RUN singlestep [100/1000]
kgdbts:RUN singlestep [200/1000]
kgdbts:RUN singlestep [300/1000]
kgdbts:RUN singlestep [400/1000]
kgdbts:RUN singlestep [500/1000]
kgdbts:RUN singlestep [600/1000]
kgdbts:RUN singlestep [700/1000]
kgdbts:RUN singlestep [800/1000]
kgdbts:RUN singlestep [900/1000]
kgdbts:RUN do_fork for 100 breakpoints
smc91x: not found (-19).
mousedev: PS/2 mouse device common for all mice
TCP: cubic registered
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
EXT4-fs (vda2): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) on device 254:2.
Freeing unused kernel memory: 256K (ffffffc0005d1000 - ffffffc000611000)
udevd[470]: starting version 182
EXT4-fs (vda2): re-mounted. Opts: data=ordered
random: dd urandom read with 11 bits of entropy available
rpcbind: cannot create socket for udp6
rpcbind: cannot create socket for tcp6
rpcbind: cannot get uid of '': Success
kgdb: Unregistered I/O driver kgdbts, debugger disabled.

Last login: Mon Jan 27 08:00:01 UTC 2014 on tty1
root@genericarmv8:~# uname -a
Linux genericarmv8 3.14.0-rc3+ #3 SMP PREEMPT Wed Feb 19 09:06:22 IST
2014 aarch64 GNU/Linux
root@genericarmv8:~#

.config is attached (renamed as config)

> Thanks.
>
> --
> Catalin
Catalin Marinas Feb. 19, 2014, 11:31 a.m. UTC | #7 
On Wed, Feb 19, 2014 at 04:44:05AM +0000, Vijay Kilari wrote:
> On Tue, Feb 18, 2014 at 5:32 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Tue, Feb 18, 2014 at 11:29:40AM +0000, Vijay Kilari wrote:
> >> On Mon, Feb 17, 2014 at 6:31 PM, Catalin Marinas
> >> <catalin.marinas@arm.com> wrote:
> >> > On Mon, Feb 17, 2014 at 12:21:45PM +0000, Vijay Kilari wrote:
> >> >>    If it is ok, can you please merge these patches
> >> >
> >> > I was about to merge them but I wanted to try first. Enabling kgd tests
> >> > at boot time, I get plenty of failures as below. Have you successfully
> >> > run the kgdb tests?
> >>
> >>   I re-tested v9 version patches with our internal arm64 simulator and
> >> I don't see these warnings. Also I tested with 3.13 kernel from linaro with v8
> >> foundation model and no errors are seen (logs below).
> >
> > It's good to know. Could you please rebase against 3.14-rc3 and rerun
> > the tests? If they work, please send me your .config file that you used
> > with the foundation model.
> >
> > (and since you rebase on 3.14-rc3, you could repost a v10 with all the
> > acks in place so that it's easier for me to merge)
> 
>  Reposted v10 version of patches which is rebased on 3.14-rc3 kernel.
> Test results are as follows on v8 foundation model.
> 
>  vda: vda1 vda2
> kgdb: Registered I/O driver kgdbts.
> kgdbts:RUN plant and detach test
> kgdbts:RUN sw breakpoint test
> kgdbts:RUN bad memory access test
> kgdbts:RUN singlestep test 1000 iterations
> kgdbts:RUN singlestep [0/1000]
> kgdbts:RUN singlestep [100/1000]
> kgdbts:RUN singlestep [200/1000]
> kgdbts:RUN singlestep [300/1000]
> kgdbts:RUN singlestep [400/1000]
> kgdbts:RUN singlestep [500/1000]
> kgdbts:RUN singlestep [600/1000]
> kgdbts:RUN singlestep [700/1000]
> kgdbts:RUN singlestep [800/1000]
> kgdbts:RUN singlestep [900/1000]
> kgdbts:RUN do_fork for 100 breakpoints

OK, I eventually managed to reproduce this. But by running with two
CPUs, I get (during the do_fork() tests):

BUG: scheduling while atomic: kworker/u8:0/6/0x00000002
Modules linked in:
CPU: 1 PID: 6 Comm: kworker/u8:0 Not tainted 3.14.0-rc3+ #306
Workqueue: khelper __call_usermodehelper
Call trace:
[<ffffffc000087dbc>] dump_backtrace+0x0/0x12c
[<ffffffc000087efc>] show_stack+0x14/0x1c
[<ffffffc00043c224>] dump_stack+0x78/0xc4
[<ffffffc000439b48>] __schedule_bug+0x40/0x54
[<ffffffc00043d67c>] __schedule+0x514/0x604
[<ffffffc00043d794>] schedule+0x28/0x78
[<ffffffc00043cc90>] schedule_timeout+0x170/0x1bc
[<ffffffc00043e16c>] wait_for_common+0xc0/0x14c
[<ffffffc00043e280>] wait_for_completion_killable+0x14/0x28
[<ffffffc0000942f8>] do_fork+0x158/0x2a8
[<ffffffc000094478>] kernel_thread+0x30/0x38
[<ffffffc0000a842c>] __call_usermodehelper+0x34/0xa8
[<ffffffc0000ab300>] process_one_work+0x118/0x354
[<ffffffc0000abfcc>] worker_thread+0x13c/0x3c0
[<ffffffc0000b1e84>] kthread+0xd4/0xe8


It gets much worse if I run with two CPUs and CONFIG_KGDB_KDB enabled
(but fine with a single CPU).

So no need to post another series for now but please check the multi-CPU
case as well and send a separate fix. I'll dig a bit on my side as well.
Catalin Marinas Feb. 19, 2014, 4:03 p.m. UTC | #8 
On Wed, Feb 19, 2014 at 11:31:57AM +0000, Catalin Marinas wrote:
> On Wed, Feb 19, 2014 at 04:44:05AM +0000, Vijay Kilari wrote:
> >  Reposted v10 version of patches which is rebased on 3.14-rc3 kernel.
> > Test results are as follows on v8 foundation model.
> > 
> >  vda: vda1 vda2
> > kgdb: Registered I/O driver kgdbts.
> > kgdbts:RUN plant and detach test
> > kgdbts:RUN sw breakpoint test
> > kgdbts:RUN bad memory access test
> > kgdbts:RUN singlestep test 1000 iterations
> > kgdbts:RUN singlestep [0/1000]
> > kgdbts:RUN singlestep [100/1000]
> > kgdbts:RUN singlestep [200/1000]
> > kgdbts:RUN singlestep [300/1000]
> > kgdbts:RUN singlestep [400/1000]
> > kgdbts:RUN singlestep [500/1000]
> > kgdbts:RUN singlestep [600/1000]
> > kgdbts:RUN singlestep [700/1000]
> > kgdbts:RUN singlestep [800/1000]
> > kgdbts:RUN singlestep [900/1000]
> > kgdbts:RUN do_fork for 100 breakpoints
> 
> OK, I eventually managed to reproduce this. But by running with two
> CPUs, I get (during the do_fork() tests):
> 
> BUG: scheduling while atomic: kworker/u8:0/6/0x00000002
> Modules linked in:
> CPU: 1 PID: 6 Comm: kworker/u8:0 Not tainted 3.14.0-rc3+ #306
> Workqueue: khelper __call_usermodehelper
> Call trace:
> [<ffffffc000087dbc>] dump_backtrace+0x0/0x12c
> [<ffffffc000087efc>] show_stack+0x14/0x1c
> [<ffffffc00043c224>] dump_stack+0x78/0xc4
> [<ffffffc000439b48>] __schedule_bug+0x40/0x54
> [<ffffffc00043d67c>] __schedule+0x514/0x604
> [<ffffffc00043d794>] schedule+0x28/0x78
> [<ffffffc00043cc90>] schedule_timeout+0x170/0x1bc
> [<ffffffc00043e16c>] wait_for_common+0xc0/0x14c
> [<ffffffc00043e280>] wait_for_completion_killable+0x14/0x28
> [<ffffffc0000942f8>] do_fork+0x158/0x2a8
> [<ffffffc000094478>] kernel_thread+0x30/0x38
> [<ffffffc0000a842c>] __call_usermodehelper+0x34/0xa8
> [<ffffffc0000ab300>] process_one_work+0x118/0x354
> [<ffffffc0000abfcc>] worker_thread+0x13c/0x3c0
> [<ffffffc0000b1e84>] kthread+0xd4/0xe8
> 
> 
> It gets much worse if I run with two CPUs and CONFIG_KGDB_KDB enabled
> (but fine with a single CPU).
> 
> So no need to post another series for now but please check the multi-CPU
> case as well and send a separate fix. I'll dig a bit on my side as well.

So far I'm done with the investigation. It looks to me like one of the
kgdb tests, kgdb core or the arm64 back-end (or maybe more than one) is
not SMP safe. The errors either appear or disappear based on the printks
I put through the kgdb test or other config options which I enable.

Could you please look into making the kgdb back-end SMP-safe?

Thanks.
Will Deacon Feb. 19, 2014, 4:12 p.m. UTC | #9 
On Wed, Feb 19, 2014 at 04:03:59PM +0000, Catalin Marinas wrote:
> On Wed, Feb 19, 2014 at 11:31:57AM +0000, Catalin Marinas wrote:
> > BUG: scheduling while atomic: kworker/u8:0/6/0x00000002
> > Modules linked in:
> > CPU: 1 PID: 6 Comm: kworker/u8:0 Not tainted 3.14.0-rc3+ #306
> > Workqueue: khelper __call_usermodehelper
> > Call trace:
> > [<ffffffc000087dbc>] dump_backtrace+0x0/0x12c
> > [<ffffffc000087efc>] show_stack+0x14/0x1c
> > [<ffffffc00043c224>] dump_stack+0x78/0xc4
> > [<ffffffc000439b48>] __schedule_bug+0x40/0x54
> > [<ffffffc00043d67c>] __schedule+0x514/0x604
> > [<ffffffc00043d794>] schedule+0x28/0x78
> > [<ffffffc00043cc90>] schedule_timeout+0x170/0x1bc
> > [<ffffffc00043e16c>] wait_for_common+0xc0/0x14c
> > [<ffffffc00043e280>] wait_for_completion_killable+0x14/0x28
> > [<ffffffc0000942f8>] do_fork+0x158/0x2a8
> > [<ffffffc000094478>] kernel_thread+0x30/0x38
> > [<ffffffc0000a842c>] __call_usermodehelper+0x34/0xa8
> > [<ffffffc0000ab300>] process_one_work+0x118/0x354
> > [<ffffffc0000abfcc>] worker_thread+0x13c/0x3c0
> > [<ffffffc0000b1e84>] kthread+0xd4/0xe8
> > 
> > 
> > It gets much worse if I run with two CPUs and CONFIG_KGDB_KDB enabled
> > (but fine with a single CPU).
> > 
> > So no need to post another series for now but please check the multi-CPU
> > case as well and send a separate fix. I'll dig a bit on my side as well.
> 
> So far I'm done with the investigation. It looks to me like one of the
> kgdb tests, kgdb core or the arm64 back-end (or maybe more than one) is
> not SMP safe. The errors either appear or disappear based on the printks
> I put through the kgdb test or other config options which I enable.
> 
> Could you please look into making the kgdb back-end SMP-safe?

There are certainly potential SMP problems in the back-end, which I asked
about in the initial series:

  http://lkml.kernel.org/r/CALicx6v1eGHRwWPrjzihzBZxCu8t1vpMoq-YfutSm4mRmP6gEQ@mail.gmail.com

The reply from Vijay suggested that everything is confined to a single CPU.

Will
diff mbox

Patch

diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
index 6231479..ee9f28e 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -43,23 +43,6 @@  enum debug_el {
 #ifndef __ASSEMBLY__
 struct task_struct;
 
-#define local_dbg_save(flags)							\
-	do {									\
-		typecheck(unsigned long, flags);				\
-		asm volatile(							\
-		"mrs	%0, daif			// local_dbg_save\n"	\
-		"msr	daifset, #8"						\
-		: "=r" (flags) : : "memory");					\
-	} while (0)
-
-#define local_dbg_restore(flags)						\
-	do {									\
-		typecheck(unsigned long, flags);				\
-		asm volatile(							\
-		"msr	daif, %0			// local_dbg_restore\n"	\
-		: : "r" (flags) : "memory");					\
-	} while (0)
-
 #define DBG_ARCH_ID_RESERVED	0	/* In case of ptrace ABI updates. */
 
 #define DBG_HOOK_HANDLED	0
diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
index b2fcfbc..11cc941 100644
--- a/arch/arm64/include/asm/irqflags.h
+++ b/arch/arm64/include/asm/irqflags.h
@@ -90,5 +90,28 @@  static inline int arch_irqs_disabled_flags(unsigned long flags)
 	return flags & PSR_I_BIT;
 }
 
+/*
+ * save and restore debug state
+ */
+#define local_dbg_save(flags)						\
+	do {								\
+		typecheck(unsigned long, flags);			\
+		asm volatile(						\
+		"mrs    %0, daif		// local_dbg_save\n"	\
+		"msr    daifset, #8"					\
+		: "=r" (flags) : : "memory");				\
+	} while (0)
+
+#define local_dbg_restore(flags)					\
+	do {								\
+		typecheck(unsigned long, flags);			\
+		asm volatile(						\
+		"msr    daif, %0		// local_dbg_restore\n"	\
+		: : "r" (flags) : "memory");				\
+	} while (0)
+
+#define local_dbg_enable()	asm("msr	daifclr, #8" : : : "memory")
+#define local_dbg_disable()	asm("msr	daifset, #8" : : : "memory")
+
 #endif
 #endif
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index 23586bd..a86e5b1 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -138,6 +138,7 @@  static void clear_os_lock(void *unused)
 {
 	asm volatile("msr oslar_el1, %0" : : "r" (0));
 	isb();
+	local_dbg_enable();
 }
 
 static int os_lock_notify(struct notifier_block *self,