* [Xenomai] am335x xenomai
@ 2018-09-07 15:54 Michael Nazzareno Trimarchi
2019-12-09 23:42 ` Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai) Richard Weinberger
0 siblings, 1 reply; 12+ messages in thread
From: Michael Nazzareno Trimarchi @ 2018-09-07 15:54 UTC (permalink / raw)
To: xenomai
Hi all
I have this:
0.451161]
[ 0.451180] =================================
[ 0.451188] [ INFO: inconsistent lock state ]
[ 0.451201] 4.1.6-ipipe #1 Not tainted
[ 0.451208] ---------------------------------
[ 0.451217] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[ 0.451228] irq/156-44e0b00/21 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 0.451238] (std_spinlock_raw(&rq->lock)){?.-...}, at:
[<c063a23c>] __schedule+0xc0/0x9a0
[ 0.451285] {IN-HARDIRQ-W} state was registered at:
[ 0.451294] [<c063fca4>] _raw_spin_lock+0x34/0x44
[ 0.451314] [<c006b85c>] scheduler_tick+0x2c/0xb4
[ 0.451337] [<c00acf54>] update_process_times+0x58/0x64
[ 0.451363] [<c00bc0b8>] tick_periodic+0x38/0xf8
[ 0.451377] [<c00bc34c>] tick_handle_periodic+0x1c/0x7c
[ 0.451390] [<c0027b14>] omap2_gp_timer_interrupt+0x38/0x48
[ 0.451409] [<c009ace4>] handle_irq_event_percpu+0x74/0x2b4
[ 0.451426] [<c009af60>] handle_irq_event+0x3c/0x5c
[ 0.451438] [<c009e368>] handle_level_irq+0xa0/0x118
[ 0.451455] [<c009a328>] generic_handle_irq+0x28/0x3c
[ 0.451467] [<c009a628>] __handle_domain_irq+0x74/0xfc
[ 0.451479] [<c00e3384>] __ipipe_do_sync_stage+0x2cc/0x314
[ 0.451504] [<c0009408>] __ipipe_grab_irq+0x5c/0x7c
[ 0.451518] [<c0009704>] omap_intc_handle_irq+0xb8/0xc8
[ 0.451530] [<dfdff480>] 0xdfdff480
[ 0.451543] [<c0640a64>] __irq_svc+0x44/0x70
[ 0.451559] [<c000a3bc>] calibrate_delay+0x390/0x594
[ 0.451572] [<c000a3bc>] calibrate_delay+0x390/0x594
[ 0.451584] [<c08c7be4>] start_kernel+0x320/0x3e8
[ 0.451605] [<8000807c>] 0x8000807c
[ 0.451617] irq event stamp: 40
[ 0.451625] hardirqs last enabled at (39): [<c063ffec>]
_raw_spin_unlock_irqrestore+0x68/0x70
[ 0.451640] hardirqs last disabled at (40): [<c063fe14>]
_raw_spin_lock_irq+0x18/0x4c
[ 0.451653] softirqs last enabled at (0): [<c0040f88>]
copy_process.part.7+0x3d8/0x170c
[ 0.451678] softirqs last disabled at (0): [< (null)>] (null)
[ 0.451689]
[ 0.451689] other info that might help us debug this:
[ 0.451699] Possible unsafe locking scenario:
[ 0.451699]
[ 0.451707] CPU0
[ 0.451713] ----
[ 0.451720] lock(std_spinlock_raw(&rq->lock));
[ 0.451733] <Interrupt>
[ 0.451739] lock(std_spinlock_raw(&rq->lock));
[ 0.451752]
[ 0.451752] *** DEADLOCK ***
[ 0.451752]
[ 0.451764] 1 lock held by irq/156-44e0b00/21:
[ 0.451771] #0: (std_spinlock_raw(&rq->lock)){?.-...}, at:
[<c063a23c>] __schedule+0xc0/0x9a0
[ 0.451799]
[ 0.451799] stack backtrace:
[ 0.451814] CPU: 0 PID: 21 Comm: irq/156-44e0b00 Not tainted 4.1.6-ipipe #1
[ 0.451822] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 0.451849] [<c0017410>] (unwind_backtrace) from [<c00136e4>]
(show_stack+0x10/0x14)
[ 0.451864] [<c00136e4>] (show_stack) from [<c0638938>]
(dump_stack+0x80/0xc8)
[ 0.451883] [<c0638938>] (dump_stack) from [<c008c568>]
(print_usage_bug+0x1d8/0x2cc)
[ 0.451897] [<c008c568>] (print_usage_bug) from [<c008cbdc>]
(mark_lock+0x580/0x6c8)
[ 0.451910] [<c008cbdc>] (mark_lock) from [<c008cd8c>]
(mark_held_locks+0x68/0x98)
[ 0.451924] [<c008cd8c>] (mark_held_locks) from [<c008ce28>]
(trace_hardirqs_on_caller+0x6c/0x1f4)
[ 0.451939] [<c008ce28>] (trace_hardirqs_on_caller) from
[<c0640a94>] (__ipipe_fast_svc_irq_exit+0x4/0x18)
[ 0.451957] [<c0640a94>] (__ipipe_fast_svc_irq_exit) from
[<c007354c>] (set_next_entity+0x444/0x53c)
[ 0.451973] [<c007354c>] (set_next_entity) from [<c007b6b0>]
(pick_next_task_fair+0x70/0x66c)
[ 0.451988] [<c007b6b0>] (pick_next_task_fair) from [<c063a684>]
(__schedule+0x508/0x9a0)
[ 0.452001] [<c063a684>] (__schedule) from [<c063ab5c>] (schedule+0x40/0xa0)
[ 0.452015] [<c063ab5c>] (schedule) from [<c009bcd4>] (irq_thread+0xb8/0x19c)
[ 0.452031] [<c009bcd4>] (irq_thread) from [<c005f788>] (kthread+0xd4/0xf0)
[ 0.452050] [<c005f788>] (kthread) from [<c000fa54>]
(ret_from_fork+0x18/0x24)
Is ipipe compatible with lockdep?
[ 0.000000] Linux version 4.1.6-ipipe (michael@panicking) (gcc
version 5.5.0 (Buildroot 2018.08-rc3-00031-g2a424a7) ) #1 SMP PREEMPT
Fri Sep 7 15:26:52 CEST 2018
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
Michael
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
^ permalink raw reply [flat|nested] 12+ messages in thread
* Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
2018-09-07 15:54 [Xenomai] am335x xenomai Michael Nazzareno Trimarchi
@ 2019-12-09 23:42 ` Richard Weinberger
2019-12-10 8:13 ` Jan Kiszka
0 siblings, 1 reply; 12+ messages in thread
From: Richard Weinberger @ 2019-12-09 23:42 UTC (permalink / raw)
To: Michael Nazzareno Trimarchi; +Cc: xenomai
On Fri, Sep 7, 2018 at 5:54 PM Michael Nazzareno Trimarchi
<michael@amarulasolutions.com> wrote:
>
> Hi all
>
> I have this:
>
> 0.451161]
> [ 0.451180] =================================
> [ 0.451188] [ INFO: inconsistent lock state ]
> [ 0.451201] 4.1.6-ipipe #1 Not tainted
> [ 0.451208] ---------------------------------
> [ 0.451217] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> [ 0.451228] irq/156-44e0b00/21 [HC0[0]:SC0[0]:HE1:SE1] takes:
> [ 0.451238] (std_spinlock_raw(&rq->lock)){?.-...}, at:
> [<c063a23c>] __schedule+0xc0/0x9a0
> [ 0.451285] {IN-HARDIRQ-W} state was registered at:
> [ 0.451294] [<c063fca4>] _raw_spin_lock+0x34/0x44
> [ 0.451314] [<c006b85c>] scheduler_tick+0x2c/0xb4
> [ 0.451337] [<c00acf54>] update_process_times+0x58/0x64
> [ 0.451363] [<c00bc0b8>] tick_periodic+0x38/0xf8
> [ 0.451377] [<c00bc34c>] tick_handle_periodic+0x1c/0x7c
> [ 0.451390] [<c0027b14>] omap2_gp_timer_interrupt+0x38/0x48
> [ 0.451409] [<c009ace4>] handle_irq_event_percpu+0x74/0x2b4
> [ 0.451426] [<c009af60>] handle_irq_event+0x3c/0x5c
> [ 0.451438] [<c009e368>] handle_level_irq+0xa0/0x118
> [ 0.451455] [<c009a328>] generic_handle_irq+0x28/0x3c
> [ 0.451467] [<c009a628>] __handle_domain_irq+0x74/0xfc
> [ 0.451479] [<c00e3384>] __ipipe_do_sync_stage+0x2cc/0x314
> [ 0.451504] [<c0009408>] __ipipe_grab_irq+0x5c/0x7c
> [ 0.451518] [<c0009704>] omap_intc_handle_irq+0xb8/0xc8
> [ 0.451530] [<dfdff480>] 0xdfdff480
> [ 0.451543] [<c0640a64>] __irq_svc+0x44/0x70
> [ 0.451559] [<c000a3bc>] calibrate_delay+0x390/0x594
> [ 0.451572] [<c000a3bc>] calibrate_delay+0x390/0x594
> [ 0.451584] [<c08c7be4>] start_kernel+0x320/0x3e8
> [ 0.451605] [<8000807c>] 0x8000807c
> [ 0.451617] irq event stamp: 40
> [ 0.451625] hardirqs last enabled at (39): [<c063ffec>]
> _raw_spin_unlock_irqrestore+0x68/0x70
> [ 0.451640] hardirqs last disabled at (40): [<c063fe14>]
> _raw_spin_lock_irq+0x18/0x4c
> [ 0.451653] softirqs last enabled at (0): [<c0040f88>]
> copy_process.part.7+0x3d8/0x170c
> [ 0.451678] softirqs last disabled at (0): [< (null)>] (null)
> [ 0.451689]
> [ 0.451689] other info that might help us debug this:
> [ 0.451699] Possible unsafe locking scenario:
> [ 0.451699]
> [ 0.451707] CPU0
> [ 0.451713] ----
> [ 0.451720] lock(std_spinlock_raw(&rq->lock));
> [ 0.451733] <Interrupt>
> [ 0.451739] lock(std_spinlock_raw(&rq->lock));
> [ 0.451752]
> [ 0.451752] *** DEADLOCK ***
> [ 0.451752]
> [ 0.451764] 1 lock held by irq/156-44e0b00/21:
> [ 0.451771] #0: (std_spinlock_raw(&rq->lock)){?.-...}, at:
> [<c063a23c>] __schedule+0xc0/0x9a0
> [ 0.451799]
> [ 0.451799] stack backtrace:
> [ 0.451814] CPU: 0 PID: 21 Comm: irq/156-44e0b00 Not tainted 4.1.6-ipipe #1
> [ 0.451822] Hardware name: Generic AM33XX (Flattened Device Tree)
> [ 0.451849] [<c0017410>] (unwind_backtrace) from [<c00136e4>]
> (show_stack+0x10/0x14)
> [ 0.451864] [<c00136e4>] (show_stack) from [<c0638938>]
> (dump_stack+0x80/0xc8)
> [ 0.451883] [<c0638938>] (dump_stack) from [<c008c568>]
> (print_usage_bug+0x1d8/0x2cc)
> [ 0.451897] [<c008c568>] (print_usage_bug) from [<c008cbdc>]
> (mark_lock+0x580/0x6c8)
> [ 0.451910] [<c008cbdc>] (mark_lock) from [<c008cd8c>]
> (mark_held_locks+0x68/0x98)
> [ 0.451924] [<c008cd8c>] (mark_held_locks) from [<c008ce28>]
> (trace_hardirqs_on_caller+0x6c/0x1f4)
> [ 0.451939] [<c008ce28>] (trace_hardirqs_on_caller) from
> [<c0640a94>] (__ipipe_fast_svc_irq_exit+0x4/0x18)
> [ 0.451957] [<c0640a94>] (__ipipe_fast_svc_irq_exit) from
> [<c007354c>] (set_next_entity+0x444/0x53c)
> [ 0.451973] [<c007354c>] (set_next_entity) from [<c007b6b0>]
> (pick_next_task_fair+0x70/0x66c)
> [ 0.451988] [<c007b6b0>] (pick_next_task_fair) from [<c063a684>]
> (__schedule+0x508/0x9a0)
> [ 0.452001] [<c063a684>] (__schedule) from [<c063ab5c>] (schedule+0x40/0xa0)
> [ 0.452015] [<c063ab5c>] (schedule) from [<c009bcd4>] (irq_thread+0xb8/0x19c)
> [ 0.452031] [<c009bcd4>] (irq_thread) from [<c005f788>] (kthread+0xd4/0xf0)
> [ 0.452050] [<c005f788>] (kthread) from [<c000fa54>]
> (ret_from_fork+0x18/0x24)
>
> Is ipipe compatible with lockdep?
>
> [ 0.000000] Linux version 4.1.6-ipipe (michael@panicking) (gcc
> version 5.5.0 (Buildroot 2018.08-rc3-00031-g2a424a7) ) #1 SMP PREEMPT
> Fri Sep 7 15:26:52 CEST 2018
> [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
Sorry for unearthing this old mail but I'm facing the same issue.
I'm on ipipe-core-4.14.110-arm-7 plus xenomai 3.0.9.
As soon I enable lockdep it complains when a kprobe to Linux's sched_switch()
is attached. My probe is a no-op btw.
[ 108.147330] ================================
[ 108.147659] WARNING: inconsistent lock state
[ 108.147990] 4.14.111 #1 Tainted: G O
[ 108.148516] --------------------------------
[ 108.148986] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[ 108.149397] init/1 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 108.149740] (std_spinlock_raw(&rq->lock)){?.-.}, at: [<c09c294c>]
__schedule+0x84/0x7dc
[ 108.150366] {IN-HARDIRQ-W} state was registered at:
[ 108.150711] _raw_spin_lock+0x4c/0x84
[ 108.150999] scheduler_tick+0x3c/0xb4
[ 108.151298] update_process_times+0x6c/0x84
[ 108.151613] tick_handle_periodic+0x24/0x98
[ 108.151935] twd_handler+0x38/0x44
[ 108.152301] handle_percpu_devid_irq+0x158/0x30c
[ 108.152654] generic_handle_irq+0x18/0x28
[ 108.153071] __handle_domain_irq+0xb4/0xcc
[ 108.153394] __ipipe_do_sync_stage+0x23c/0x270
[ 108.153728] ipipe_unstall_root+0x38/0x48
[ 108.154042] _raw_spin_lock+0x4c/0x84
[ 108.154333] inode_sb_list_add+0x14/0x48
[ 108.154726] new_inode+0x18/0x20
[ 108.155014] ramfs_get_inode+0x14/0x11c
[ 108.155325] ramfs_fill_super+0xb8/0x134
[ 108.155645] mount_nodev+0x3c/0x84
[ 108.155938] mount_fs+0x10/0x98
[ 108.156204] vfs_kern_mount+0x54/0x128
[ 108.156510] mnt_init+0x11c/0x204
[ 108.156798] vfs_caches_init+0x54/0x70
[ 108.157111] start_kernel+0x330/0x3bc
[ 108.157404] 0x1000807c
[ 108.157754] irq event stamp: 225492
[ 108.158160] hardirqs last enabled at (225491): [<c09c8b9c>]
_raw_spin_unlock_irqrestore+0x50/0x58
[ 108.158837] hardirqs last disabled at (225492): [<c09c2934>]
__schedule+0x6c/0x7dc
[ 108.159311] softirqs last enabled at (224408): [<c010187c>]
__do_softirq+0x164/0x478
[ 108.159799] softirqs last disabled at (224401): [<c0127258>]
irq_exit+0x94/0x118
[ 108.160259]
[ 108.160259] other info that might help us debug this:
[ 108.160901] Possible unsafe locking scenario:
[ 108.160901]
[ 108.161305] CPU0
[ 108.161537] ----
[ 108.161766] lock(std_spinlock_raw(&rq->lock));
[ 108.162179] <Interrupt>
[ 108.162415] lock(std_spinlock_raw(&rq->lock));
[ 108.163066]
[ 108.163066] *** DEADLOCK ***
[ 108.163066]
[ 108.163501] 1 lock held by init/1:
[ 108.163775] #0: (std_spinlock_raw(&rq->lock)){?.-.}, at:
[<c09c294c>] __schedule+0x84/0x7dc
[ 108.164453]
[ 108.164453] stack backtrace:
[ 108.164955] CPU: 1 PID: 1 Comm: init Tainted: G O 4.14.111 #1
[ 108.165453] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 108.165882] I-pipe domain: Linux
[ 108.166153] [<c0110000>] (unwind_backtrace) from [<c010b4f8>]
(show_stack+0x10/0x14)
[ 108.166644] [<c010b4f8>] (show_stack) from [<c09af1e8>]
(dump_stack+0xc0/0xec)
[ 108.167247] [<c09af1e8>] (dump_stack) from [<c0166cd0>]
(print_usage_bug+0x1c4/0x2cc)
[ 108.167926] [<c0166cd0>] (print_usage_bug) from [<c0163964>]
(mark_lock+0x430/0x684)
[ 108.168666] [<c0163964>] (mark_lock) from [<c0163c18>]
(mark_held_locks+0x60/0x6c)
[ 108.169164] [<c0163c18>] (mark_held_locks) from [<c0163db4>]
(trace_hardirqs_on_caller+0x190/0x21c)
[ 108.169712] [<c0163db4>] (trace_hardirqs_on_caller) from
[<c010c214>] (__pabt_svc+0x74/0xa0)
[ 108.170228] [<c010c214>] (__pabt_svc) from [<bf052ec0>]
(sched_switch_probe+0x0/0x4 [myprobe])
[ 108.170781] [<bf052ec0>] (sched_switch_probe [myprobe]) from
[<c09c2ad8>] (__schedule+0x210/0x7dc)
[ 108.171364] [<c09c2ad8>] (__schedule) from [<c09c3148>] (schedule+0xa4/0xdc)
[ 108.171816] [<c09c3148>] (schedule) from [<c09c8388>]
(schedule_hrtimeout_range_clock+0xe4/0x130)
[ 108.172627] [<c09c8388>] (schedule_hrtimeout_range_clock) from
[<c09c83ec>] (schedule_hrtimeout_range+0x18/0x20)
[ 108.173249] [<c09c83ec>] (schedule_hrtimeout_range) from
[<c028ff38>] (poll_schedule_timeout+0x88/0xcc)
[ 108.173828] [<c028ff38>] (poll_schedule_timeout) from [<c0290594>]
(do_select+0x294/0x5b4)
[ 108.174336] [<c0290594>] (do_select) from [<c0291120>]
(core_sys_select+0x2c0/0x47c)
[ 108.174810] [<c0291120>] (core_sys_select) from [<c02913a8>]
(SyS_select+0xcc/0x144)
[ 108.175289] [<c02913a8>] (SyS_select) from [<c0107520>]
(ret_fast_syscall+0x0/0x28)
--
Thanks,
//richard
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
2019-12-09 23:42 ` Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai) Richard Weinberger
@ 2019-12-10 8:13 ` Jan Kiszka
2019-12-10 10:54 ` Richard Weinberger
0 siblings, 1 reply; 12+ messages in thread
From: Jan Kiszka @ 2019-12-10 8:13 UTC (permalink / raw)
To: Richard Weinberger, Michael Nazzareno Trimarchi; +Cc: xenomai
On 10.12.19 00:42, Richard Weinberger via Xenomai wrote:
> On Fri, Sep 7, 2018 at 5:54 PM Michael Nazzareno Trimarchi
> <michael@amarulasolutions.com> wrote:
>>
>> Hi all
>>
>> I have this:
>>
>> 0.451161]
>> [ 0.451180] =================================
>> [ 0.451188] [ INFO: inconsistent lock state ]
>> [ 0.451201] 4.1.6-ipipe #1 Not tainted
>> [ 0.451208] ---------------------------------
>> [ 0.451217] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
>> [ 0.451228] irq/156-44e0b00/21 [HC0[0]:SC0[0]:HE1:SE1] takes:
>> [ 0.451238] (std_spinlock_raw(&rq->lock)){?.-...}, at:
>> [<c063a23c>] __schedule+0xc0/0x9a0
>> [ 0.451285] {IN-HARDIRQ-W} state was registered at:
>> [ 0.451294] [<c063fca4>] _raw_spin_lock+0x34/0x44
>> [ 0.451314] [<c006b85c>] scheduler_tick+0x2c/0xb4
>> [ 0.451337] [<c00acf54>] update_process_times+0x58/0x64
>> [ 0.451363] [<c00bc0b8>] tick_periodic+0x38/0xf8
>> [ 0.451377] [<c00bc34c>] tick_handle_periodic+0x1c/0x7c
>> [ 0.451390] [<c0027b14>] omap2_gp_timer_interrupt+0x38/0x48
>> [ 0.451409] [<c009ace4>] handle_irq_event_percpu+0x74/0x2b4
>> [ 0.451426] [<c009af60>] handle_irq_event+0x3c/0x5c
>> [ 0.451438] [<c009e368>] handle_level_irq+0xa0/0x118
>> [ 0.451455] [<c009a328>] generic_handle_irq+0x28/0x3c
>> [ 0.451467] [<c009a628>] __handle_domain_irq+0x74/0xfc
>> [ 0.451479] [<c00e3384>] __ipipe_do_sync_stage+0x2cc/0x314
>> [ 0.451504] [<c0009408>] __ipipe_grab_irq+0x5c/0x7c
>> [ 0.451518] [<c0009704>] omap_intc_handle_irq+0xb8/0xc8
>> [ 0.451530] [<dfdff480>] 0xdfdff480
>> [ 0.451543] [<c0640a64>] __irq_svc+0x44/0x70
>> [ 0.451559] [<c000a3bc>] calibrate_delay+0x390/0x594
>> [ 0.451572] [<c000a3bc>] calibrate_delay+0x390/0x594
>> [ 0.451584] [<c08c7be4>] start_kernel+0x320/0x3e8
>> [ 0.451605] [<8000807c>] 0x8000807c
>> [ 0.451617] irq event stamp: 40
>> [ 0.451625] hardirqs last enabled at (39): [<c063ffec>]
>> _raw_spin_unlock_irqrestore+0x68/0x70
>> [ 0.451640] hardirqs last disabled at (40): [<c063fe14>]
>> _raw_spin_lock_irq+0x18/0x4c
>> [ 0.451653] softirqs last enabled at (0): [<c0040f88>]
>> copy_process.part.7+0x3d8/0x170c
>> [ 0.451678] softirqs last disabled at (0): [< (null)>] (null)
>> [ 0.451689]
>> [ 0.451689] other info that might help us debug this:
>> [ 0.451699] Possible unsafe locking scenario:
>> [ 0.451699]
>> [ 0.451707] CPU0
>> [ 0.451713] ----
>> [ 0.451720] lock(std_spinlock_raw(&rq->lock));
>> [ 0.451733] <Interrupt>
>> [ 0.451739] lock(std_spinlock_raw(&rq->lock));
>> [ 0.451752]
>> [ 0.451752] *** DEADLOCK ***
>> [ 0.451752]
>> [ 0.451764] 1 lock held by irq/156-44e0b00/21:
>> [ 0.451771] #0: (std_spinlock_raw(&rq->lock)){?.-...}, at:
>> [<c063a23c>] __schedule+0xc0/0x9a0
>> [ 0.451799]
>> [ 0.451799] stack backtrace:
>> [ 0.451814] CPU: 0 PID: 21 Comm: irq/156-44e0b00 Not tainted 4.1.6-ipipe #1
>> [ 0.451822] Hardware name: Generic AM33XX (Flattened Device Tree)
>> [ 0.451849] [<c0017410>] (unwind_backtrace) from [<c00136e4>]
>> (show_stack+0x10/0x14)
>> [ 0.451864] [<c00136e4>] (show_stack) from [<c0638938>]
>> (dump_stack+0x80/0xc8)
>> [ 0.451883] [<c0638938>] (dump_stack) from [<c008c568>]
>> (print_usage_bug+0x1d8/0x2cc)
>> [ 0.451897] [<c008c568>] (print_usage_bug) from [<c008cbdc>]
>> (mark_lock+0x580/0x6c8)
>> [ 0.451910] [<c008cbdc>] (mark_lock) from [<c008cd8c>]
>> (mark_held_locks+0x68/0x98)
>> [ 0.451924] [<c008cd8c>] (mark_held_locks) from [<c008ce28>]
>> (trace_hardirqs_on_caller+0x6c/0x1f4)
>> [ 0.451939] [<c008ce28>] (trace_hardirqs_on_caller) from
>> [<c0640a94>] (__ipipe_fast_svc_irq_exit+0x4/0x18)
>> [ 0.451957] [<c0640a94>] (__ipipe_fast_svc_irq_exit) from
>> [<c007354c>] (set_next_entity+0x444/0x53c)
>> [ 0.451973] [<c007354c>] (set_next_entity) from [<c007b6b0>]
>> (pick_next_task_fair+0x70/0x66c)
>> [ 0.451988] [<c007b6b0>] (pick_next_task_fair) from [<c063a684>]
>> (__schedule+0x508/0x9a0)
>> [ 0.452001] [<c063a684>] (__schedule) from [<c063ab5c>] (schedule+0x40/0xa0)
>> [ 0.452015] [<c063ab5c>] (schedule) from [<c009bcd4>] (irq_thread+0xb8/0x19c)
>> [ 0.452031] [<c009bcd4>] (irq_thread) from [<c005f788>] (kthread+0xd4/0xf0)
>> [ 0.452050] [<c005f788>] (kthread) from [<c000fa54>]
>> (ret_from_fork+0x18/0x24)
>>
>> Is ipipe compatible with lockdep?
>>
>> [ 0.000000] Linux version 4.1.6-ipipe (michael@panicking) (gcc
>> version 5.5.0 (Buildroot 2018.08-rc3-00031-g2a424a7) ) #1 SMP PREEMPT
>> Fri Sep 7 15:26:52 CEST 2018
>> [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
>> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
>> instruction cache
>
> Sorry for unearthing this old mail but I'm facing the same issue.
> I'm on ipipe-core-4.14.110-arm-7 plus xenomai 3.0.9.
>
> As soon I enable lockdep it complains when a kprobe to Linux's sched_switch()
> is attached. My probe is a no-op btw.
>
> [ 108.147330] ================================
> [ 108.147659] WARNING: inconsistent lock state
> [ 108.147990] 4.14.111 #1 Tainted: G O
> [ 108.148516] --------------------------------
> [ 108.148986] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> [ 108.149397] init/1 [HC0[0]:SC0[0]:HE1:SE1] takes:
> [ 108.149740] (std_spinlock_raw(&rq->lock)){?.-.}, at: [<c09c294c>]
> __schedule+0x84/0x7dc
> [ 108.150366] {IN-HARDIRQ-W} state was registered at:
> [ 108.150711] _raw_spin_lock+0x4c/0x84
> [ 108.150999] scheduler_tick+0x3c/0xb4
> [ 108.151298] update_process_times+0x6c/0x84
> [ 108.151613] tick_handle_periodic+0x24/0x98
> [ 108.151935] twd_handler+0x38/0x44
> [ 108.152301] handle_percpu_devid_irq+0x158/0x30c
> [ 108.152654] generic_handle_irq+0x18/0x28
> [ 108.153071] __handle_domain_irq+0xb4/0xcc
> [ 108.153394] __ipipe_do_sync_stage+0x23c/0x270
> [ 108.153728] ipipe_unstall_root+0x38/0x48
> [ 108.154042] _raw_spin_lock+0x4c/0x84
> [ 108.154333] inode_sb_list_add+0x14/0x48
> [ 108.154726] new_inode+0x18/0x20
> [ 108.155014] ramfs_get_inode+0x14/0x11c
> [ 108.155325] ramfs_fill_super+0xb8/0x134
> [ 108.155645] mount_nodev+0x3c/0x84
> [ 108.155938] mount_fs+0x10/0x98
> [ 108.156204] vfs_kern_mount+0x54/0x128
> [ 108.156510] mnt_init+0x11c/0x204
> [ 108.156798] vfs_caches_init+0x54/0x70
> [ 108.157111] start_kernel+0x330/0x3bc
> [ 108.157404] 0x1000807c
> [ 108.157754] irq event stamp: 225492
> [ 108.158160] hardirqs last enabled at (225491): [<c09c8b9c>]
> _raw_spin_unlock_irqrestore+0x50/0x58
> [ 108.158837] hardirqs last disabled at (225492): [<c09c2934>]
> __schedule+0x6c/0x7dc
> [ 108.159311] softirqs last enabled at (224408): [<c010187c>]
> __do_softirq+0x164/0x478
> [ 108.159799] softirqs last disabled at (224401): [<c0127258>]
> irq_exit+0x94/0x118
> [ 108.160259]
> [ 108.160259] other info that might help us debug this:
> [ 108.160901] Possible unsafe locking scenario:
> [ 108.160901]
> [ 108.161305] CPU0
> [ 108.161537] ----
> [ 108.161766] lock(std_spinlock_raw(&rq->lock));
> [ 108.162179] <Interrupt>
> [ 108.162415] lock(std_spinlock_raw(&rq->lock));
> [ 108.163066]
> [ 108.163066] *** DEADLOCK ***
> [ 108.163066]
> [ 108.163501] 1 lock held by init/1:
> [ 108.163775] #0: (std_spinlock_raw(&rq->lock)){?.-.}, at:
> [<c09c294c>] __schedule+0x84/0x7dc
> [ 108.164453]
> [ 108.164453] stack backtrace:
> [ 108.164955] CPU: 1 PID: 1 Comm: init Tainted: G O 4.14.111 #1
> [ 108.165453] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [ 108.165882] I-pipe domain: Linux
> [ 108.166153] [<c0110000>] (unwind_backtrace) from [<c010b4f8>]
> (show_stack+0x10/0x14)
> [ 108.166644] [<c010b4f8>] (show_stack) from [<c09af1e8>]
> (dump_stack+0xc0/0xec)
> [ 108.167247] [<c09af1e8>] (dump_stack) from [<c0166cd0>]
> (print_usage_bug+0x1c4/0x2cc)
> [ 108.167926] [<c0166cd0>] (print_usage_bug) from [<c0163964>]
> (mark_lock+0x430/0x684)
> [ 108.168666] [<c0163964>] (mark_lock) from [<c0163c18>]
> (mark_held_locks+0x60/0x6c)
> [ 108.169164] [<c0163c18>] (mark_held_locks) from [<c0163db4>]
> (trace_hardirqs_on_caller+0x190/0x21c)
> [ 108.169712] [<c0163db4>] (trace_hardirqs_on_caller) from
> [<c010c214>] (__pabt_svc+0x74/0xa0)
> [ 108.170228] [<c010c214>] (__pabt_svc) from [<bf052ec0>]
> (sched_switch_probe+0x0/0x4 [myprobe])
> [ 108.170781] [<bf052ec0>] (sched_switch_probe [myprobe]) from
> [<c09c2ad8>] (__schedule+0x210/0x7dc)
> [ 108.171364] [<c09c2ad8>] (__schedule) from [<c09c3148>] (schedule+0xa4/0xdc)
> [ 108.171816] [<c09c3148>] (schedule) from [<c09c8388>]
> (schedule_hrtimeout_range_clock+0xe4/0x130)
> [ 108.172627] [<c09c8388>] (schedule_hrtimeout_range_clock) from
> [<c09c83ec>] (schedule_hrtimeout_range+0x18/0x20)
> [ 108.173249] [<c09c83ec>] (schedule_hrtimeout_range) from
> [<c028ff38>] (poll_schedule_timeout+0x88/0xcc)
> [ 108.173828] [<c028ff38>] (poll_schedule_timeout) from [<c0290594>]
> (do_select+0x294/0x5b4)
> [ 108.174336] [<c0290594>] (do_select) from [<c0291120>]
> (core_sys_select+0x2c0/0x47c)
> [ 108.174810] [<c0291120>] (core_sys_select) from [<c02913a8>]
> (SyS_select+0xcc/0x144)
> [ 108.175289] [<c02913a8>] (SyS_select) from [<c0107520>]
> (ret_fast_syscall+0x0/0x28)
>
Do you see the same issue with ipipe-core-4.19.82-arm-6 (and Xenomai 3.1)?
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
2019-12-10 8:13 ` Jan Kiszka
@ 2019-12-10 10:54 ` Richard Weinberger
2019-12-10 13:08 ` Jan Kiszka
0 siblings, 1 reply; 12+ messages in thread
From: Richard Weinberger @ 2019-12-10 10:54 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Richard Weinberger, Michael Nazzareno Trimarchi, xenomai
----- Ursprüngliche Mail -----
> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
> Do you see the same issue with ipipe-core-4.19.82-arm-6 (and Xenomai 3.1)?
Since my board does not boot with 4.19, I cannot tell. Still had no time
to figure what is going on.
Is this a known issue with a fix in newer ipipe releases?
Thanks,
//richard
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
2019-12-10 10:54 ` Richard Weinberger
@ 2019-12-10 13:08 ` Jan Kiszka
2019-12-10 18:03 ` Philippe Gerum
0 siblings, 1 reply; 12+ messages in thread
From: Jan Kiszka @ 2019-12-10 13:08 UTC (permalink / raw)
To: Richard Weinberger, Philippe Gerum
Cc: Richard Weinberger, Michael Nazzareno Trimarchi, xenomai
On 10.12.19 11:54, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
>> Do you see the same issue with ipipe-core-4.19.82-arm-6 (and Xenomai 3.1)?
>
> Since my board does not boot with 4.19, I cannot tell. Still had no time
> to figure what is going on.
>
> Is this a known issue with a fix in newer ipipe releases?
Can't tell for ARM - Philippe?
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
2019-12-10 13:08 ` Jan Kiszka
@ 2019-12-10 18:03 ` Philippe Gerum
2019-12-10 19:31 ` Richard Weinberger
0 siblings, 1 reply; 12+ messages in thread
From: Philippe Gerum @ 2019-12-10 18:03 UTC (permalink / raw)
To: Jan Kiszka, Richard Weinberger
Cc: Richard Weinberger, Michael Nazzareno Trimarchi, xenomai
On 12/10/19 2:08 PM, Jan Kiszka wrote:
> On 10.12.19 11:54, Richard Weinberger wrote:
>> ----- Ursprüngliche Mail -----
>>> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
>>> Do you see the same issue with ipipe-core-4.19.82-arm-6 (and Xenomai 3.1)?
>>
>> Since my board does not boot with 4.19, I cannot tell. Still had no time
>> to figure what is going on.
>>
>> Is this a known issue with a fix in newer ipipe releases?
>
> Can't tell for ARM - Philippe?
>
I-pipe 4.14 was the first version to officially support PROVE_LOCKING
for arm and arm64. I did a quick check with 4.14.110 over i.MX6QP, and
got no issue running switchtest.
On the other hand, kprobe support has not been considered so far (not
even checked here). Since kprobing affects fault and IRQ handling, this
may have something to do with such splat.
--
Philippe.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
2019-12-10 18:03 ` Philippe Gerum
@ 2019-12-10 19:31 ` Richard Weinberger
2019-12-10 19:42 ` Jan Kiszka
0 siblings, 1 reply; 12+ messages in thread
From: Richard Weinberger @ 2019-12-10 19:31 UTC (permalink / raw)
To: Philippe Gerum; +Cc: Jan Kiszka, Michael Nazzareno Trimarchi, xenomai
----- Ursprüngliche Mail -----
> Von: "Philippe Gerum" <rpm@xenomai.org>
> An: "Jan Kiszka" <jan.kiszka@siemens.com>, "richard" <richard@nod.at>
> CC: "Richard Weinberger" <richard.weinberger@gmail.com>, "Michael Nazzareno Trimarchi" <michael@amarulasolutions.com>,
> "xenomai" <xenomai@xenomai.org>
> Gesendet: Dienstag, 10. Dezember 2019 19:03:22
> Betreff: Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
> On 12/10/19 2:08 PM, Jan Kiszka wrote:
>> On 10.12.19 11:54, Richard Weinberger wrote:
>>> ----- Ursprüngliche Mail -----
>>>> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
>>>> Do you see the same issue with ipipe-core-4.19.82-arm-6 (and Xenomai 3.1)?
>>>
>>> Since my board does not boot with 4.19, I cannot tell. Still had no time
>>> to figure what is going on.
>>>
>>> Is this a known issue with a fix in newer ipipe releases?
>>
>> Can't tell for ARM - Philippe?
>>
>
> I-pipe 4.14 was the first version to officially support PROVE_LOCKING
> for arm and arm64. I did a quick check with 4.14.110 over i.MX6QP, and
> got no issue running switchtest.
>
> On the other hand, kprobe support has not been considered so far (not
> even checked here). Since kprobing affects fault and IRQ handling, this
> may have something to do with such splat.
It definitely only triggers when a kprobe is attached.
Just managed to boot ipipe-core-4.19.82-arm-6 plus Xenomai 3.1, here lockdep
does *not* complain.
Since I cannot immediately upgrade to 4.19, is the lockdep warning a false positive?
If kprobes don't work on 4.14 I have kind of a problem...
If you want to try yourself, the following simple module triggers the issue instantly
on 4.14.
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/tracepoint.h>
#include <trace/events/sched.h>
static void sched_switch_probe(void *data, bool preempt,
struct task_struct *prev,
struct task_struct *next)
{
/* nop */
}
static void cobalt_switch_context_probe(void *data, struct xnthread *prev,
struct xnthread *next)
{
/* nop */
}
#define PROBE_TARGET(name) {__stringify(name), name##_probe, NULL, 0}
static struct tp_events {
const char *name;
void (*probe_fn);
struct tracepoint *tp;
int probed;
} tp_events[] = {
PROBE_TARGET(sched_switch),
PROBE_TARGET(cobalt_switch_context),
};
static void tracepoint_add(struct tracepoint *tp, void *priv)
{
int i, err;
for (i = 0; i < ARRAY_SIZE(tp_events); i++) {
if (strcmp(tp->name, tp_events[i].name) == 0) {
err = tracepoint_probe_register(tp, tp_events[i].probe_fn, NULL);
if (err) {
pr_err("Unable to register probe %s: %i\n", tp->name, err);
} else {
tp_events[i].tp = tp;
tp_events[i].probed = 1;
pr_info("Probed %s\n", tp->name);
}
}
}
}
static int __init probemod_init(void)
{
for_each_kernel_tracepoint(tracepoint_add, NULL);
return 0;
}
static void __exit probemod_exit(void)
{
int i;
for (i = 0; i < ARRAY_SIZE(tp_events); i++)
if (tp_events[i].probed)
tracepoint_probe_unregister(tp_events[i].tp, tp_events[i].probe_fn, NULL);
}
module_init(probemod_init);
module_exit(probemod_exit);
MODULE_LICENSE("GPL");
Thanks,
//richard
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
2019-12-10 19:31 ` Richard Weinberger
@ 2019-12-10 19:42 ` Jan Kiszka
2019-12-10 19:52 ` Richard Weinberger
0 siblings, 1 reply; 12+ messages in thread
From: Jan Kiszka @ 2019-12-10 19:42 UTC (permalink / raw)
To: Richard Weinberger, Philippe Gerum; +Cc: Michael Nazzareno Trimarchi, xenomai
On 10.12.19 20:31, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Philippe Gerum" <rpm@xenomai.org>
>> An: "Jan Kiszka" <jan.kiszka@siemens.com>, "richard" <richard@nod.at>
>> CC: "Richard Weinberger" <richard.weinberger@gmail.com>, "Michael Nazzareno Trimarchi" <michael@amarulasolutions.com>,
>> "xenomai" <xenomai@xenomai.org>
>> Gesendet: Dienstag, 10. Dezember 2019 19:03:22
>> Betreff: Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
>
>> On 12/10/19 2:08 PM, Jan Kiszka wrote:
>>> On 10.12.19 11:54, Richard Weinberger wrote:
>>>> ----- Ursprüngliche Mail -----
>>>>> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
>>>>> Do you see the same issue with ipipe-core-4.19.82-arm-6 (and Xenomai 3.1)?
>>>>
>>>> Since my board does not boot with 4.19, I cannot tell. Still had no time
>>>> to figure what is going on.
>>>>
>>>> Is this a known issue with a fix in newer ipipe releases?
>>>
>>> Can't tell for ARM - Philippe?
>>>
>>
>> I-pipe 4.14 was the first version to officially support PROVE_LOCKING
>> for arm and arm64. I did a quick check with 4.14.110 over i.MX6QP, and
>> got no issue running switchtest.
>>
>> On the other hand, kprobe support has not been considered so far (not
>> even checked here). Since kprobing affects fault and IRQ handling, this
>> may have something to do with such splat.
>
> It definitely only triggers when a kprobe is attached.
> Just managed to boot ipipe-core-4.19.82-arm-6 plus Xenomai 3.1, here lockdep
> does *not* complain.
>
> Since I cannot immediately upgrade to 4.19, is the lockdep warning a false positive?
> If kprobes don't work on 4.14 I have kind of a problem...
>
> If you want to try yourself, the following simple module triggers the issue instantly
> on 4.14.
>
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <linux/tracepoint.h>
> #include <trace/events/sched.h>
>
> static void sched_switch_probe(void *data, bool preempt,
> struct task_struct *prev,
> struct task_struct *next)
> {
> /* nop */
> }
>
> static void cobalt_switch_context_probe(void *data, struct xnthread *prev,
> struct xnthread *next)
> {
> /* nop */
> }
>
> #define PROBE_TARGET(name) {__stringify(name), name##_probe, NULL, 0}
> static struct tp_events {
> const char *name;
> void (*probe_fn);
> struct tracepoint *tp;
> int probed;
> } tp_events[] = {
> PROBE_TARGET(sched_switch),
> PROBE_TARGET(cobalt_switch_context),
> };
>
> static void tracepoint_add(struct tracepoint *tp, void *priv)
> {
> int i, err;
>
> for (i = 0; i < ARRAY_SIZE(tp_events); i++) {
> if (strcmp(tp->name, tp_events[i].name) == 0) {
> err = tracepoint_probe_register(tp, tp_events[i].probe_fn, NULL);
> if (err) {
> pr_err("Unable to register probe %s: %i\n", tp->name, err);
> } else {
> tp_events[i].tp = tp;
> tp_events[i].probed = 1;
> pr_info("Probed %s\n", tp->name);
> }
> }
> }
> }
>
> static int __init probemod_init(void)
> {
> for_each_kernel_tracepoint(tracepoint_add, NULL);
>
> return 0;
> }
>
> static void __exit probemod_exit(void)
> {
> int i;
>
> for (i = 0; i < ARRAY_SIZE(tp_events); i++)
> if (tp_events[i].probed)
> tracepoint_probe_unregister(tp_events[i].tp, tp_events[i].probe_fn, NULL);
> }
>
> module_init(probemod_init);
> module_exit(probemod_exit);
> MODULE_LICENSE("GPL");
>
> Thanks,
> //richard
>
That's untested even on x86 - and likely not working, with any kernel.
Do you have a use case for kprobe?
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
2019-12-10 19:42 ` Jan Kiszka
@ 2019-12-10 19:52 ` Richard Weinberger
2019-12-11 7:24 ` Jan Kiszka
0 siblings, 1 reply; 12+ messages in thread
From: Richard Weinberger @ 2019-12-10 19:52 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Philippe Gerum, Michael Nazzareno Trimarchi, xenomai
----- Ursprüngliche Mail -----
> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
> That's untested even on x86 - and likely not working, with any kernel.
>
> Do you have a use case for kprobe?
Yes. On the old kernel we used to have many hooks (function pointers)
within kernel to allow installing notification functions by our modules.
It is basically a hand made tracing/notify framework.
To get rid of the mess we decided to use kprobes instead of our plain
pointers. So far the probes worked nicely and helped us a lot to cleanup
the code base.
If this is not supported, please make ipipe depend on !CONFIG_TRACEPOINTS. :-(
Thanks,
//richard
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
2019-12-10 19:52 ` Richard Weinberger
@ 2019-12-11 7:24 ` Jan Kiszka
2019-12-11 10:17 ` Richard Weinberger
0 siblings, 1 reply; 12+ messages in thread
From: Jan Kiszka @ 2019-12-11 7:24 UTC (permalink / raw)
To: Richard Weinberger; +Cc: Philippe Gerum, Michael Nazzareno Trimarchi, xenomai
On 10.12.19 20:52, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
>> That's untested even on x86 - and likely not working, with any kernel.
>>
>> Do you have a use case for kprobe?
>
> Yes. On the old kernel we used to have many hooks (function pointers)
> within kernel to allow installing notification functions by our modules.
> It is basically a hand made tracing/notify framework.
>
> To get rid of the mess we decided to use kprobes instead of our plain
> pointers. So far the probes worked nicely and helped us a lot to cleanup
> the code base.
>
> If this is not supported, please make ipipe depend on !CONFIG_TRACEPOINTS. :-(
CONFIG_KPROBES. We do support tracing (ftrace, down to functions), and
that is what I would recommend to you.
In general, there are likely more things from the debugging section
unsupported. It's hard to hunt them all down, but CONFIG_KPROBES is
probably worth to add.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
2019-12-11 7:24 ` Jan Kiszka
@ 2019-12-11 10:17 ` Richard Weinberger
2019-12-11 10:45 ` Jan Kiszka
0 siblings, 1 reply; 12+ messages in thread
From: Richard Weinberger @ 2019-12-11 10:17 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Philippe Gerum, Michael Nazzareno Trimarchi, xenomai
----- Ursprüngliche Mail -----
> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
> An: "richard" <richard@nod.at>
> CC: "Philippe Gerum" <rpm@xenomai.org>, "Michael Nazzareno Trimarchi" <michael@amarulasolutions.com>, "xenomai"
> <xenomai@xenomai.org>
> Gesendet: Mittwoch, 11. Dezember 2019 08:24:41
> Betreff: Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
> On 10.12.19 20:52, Richard Weinberger wrote:
>> ----- Ursprüngliche Mail -----
>>> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
>>> That's untested even on x86 - and likely not working, with any kernel.
>>>
>>> Do you have a use case for kprobe?
>>
>> Yes. On the old kernel we used to have many hooks (function pointers)
>> within kernel to allow installing notification functions by our modules.
>> It is basically a hand made tracing/notify framework.
>>
>> To get rid of the mess we decided to use kprobes instead of our plain
>> pointers. So far the probes worked nicely and helped us a lot to cleanup
>> the code base.
>>
>> If this is not supported, please make ipipe depend on !CONFIG_TRACEPOINTS. :-(
>
> CONFIG_KPROBES. We do support tracing (ftrace, down to functions), and
> that is what I would recommend to you.
>
> In general, there are likely more things from the debugging section
> unsupported. It's hard to hunt them all down, but CONFIG_KPROBES is
> probably worth to add.
Let's put it differently. What is missing to have reliable kprobes?
Maybe this is a small and nice project to get a better grip on ipipe
internals.
Thanks,
//richard
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
2019-12-11 10:17 ` Richard Weinberger
@ 2019-12-11 10:45 ` Jan Kiszka
0 siblings, 0 replies; 12+ messages in thread
From: Jan Kiszka @ 2019-12-11 10:45 UTC (permalink / raw)
To: Richard Weinberger; +Cc: Philippe Gerum, Michael Nazzareno Trimarchi, xenomai
On 11.12.19 11:17, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
>> An: "richard" <richard@nod.at>
>> CC: "Philippe Gerum" <rpm@xenomai.org>, "Michael Nazzareno Trimarchi" <michael@amarulasolutions.com>, "xenomai"
>> <xenomai@xenomai.org>
>> Gesendet: Mittwoch, 11. Dezember 2019 08:24:41
>> Betreff: Re: Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai)
>
>> On 10.12.19 20:52, Richard Weinberger wrote:
>>> ----- Ursprüngliche Mail -----
>>>> Von: "Jan Kiszka" <jan.kiszka@siemens.com>
>>>> That's untested even on x86 - and likely not working, with any kernel.
>>>>
>>>> Do you have a use case for kprobe?
>>>
>>> Yes. On the old kernel we used to have many hooks (function pointers)
>>> within kernel to allow installing notification functions by our modules.
>>> It is basically a hand made tracing/notify framework.
>>>
>>> To get rid of the mess we decided to use kprobes instead of our plain
>>> pointers. So far the probes worked nicely and helped us a lot to cleanup
>>> the code base.
>>>
>>> If this is not supported, please make ipipe depend on !CONFIG_TRACEPOINTS. :-(
>>
>> CONFIG_KPROBES. We do support tracing (ftrace, down to functions), and
>> that is what I would recommend to you.
>>
>> In general, there are likely more things from the debugging section
>> unsupported. It's hard to hunt them all down, but CONFIG_KPROBES is
>> probably worth to add.
>
> Let's put it differently. What is missing to have reliable kprobes?
> Maybe this is a small and nice project to get a better grip on ipipe
> internals.
Probably something similar to what we did for enabling kgdb: Analyze to
code path taken on hit, handle it without migrations or worse things -
and then make sure this is continuously tested. Due to missing tests of
kgdb e.g., I would not assume it still works.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-12-11 10:45 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-07 15:54 [Xenomai] am335x xenomai Michael Nazzareno Trimarchi
2019-12-09 23:42 ` Lockdep splat around rq->lock (Was: Re: [Xenomai] am335x xenomai) Richard Weinberger
2019-12-10 8:13 ` Jan Kiszka
2019-12-10 10:54 ` Richard Weinberger
2019-12-10 13:08 ` Jan Kiszka
2019-12-10 18:03 ` Philippe Gerum
2019-12-10 19:31 ` Richard Weinberger
2019-12-10 19:42 ` Jan Kiszka
2019-12-10 19:52 ` Richard Weinberger
2019-12-11 7:24 ` Jan Kiszka
2019-12-11 10:17 ` Richard Weinberger
2019-12-11 10:45 ` Jan Kiszka
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.