Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3

[Ingo Molnar]

* Adam Heath <doogie@xxxxxxxxxx> wrote:

> On Fri, 15 Oct 2004, Ingo Molnar wrote:
> 
> >
> > i have released the -U3 PREEMPT_REALTIME patch:
> >
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3
> 
> scheduling while atomic: postmaster/0x04000002/3175
> caller is cond_resched+0x53/0x70
>  [<c01069f7>] dump_stack+0x17/0x20
>  [<c027b457>] schedule+0x517/0x550
>  [<c027b9c3>] cond_resched+0x53/0x70
>  [<c012cdc7>] _mutex_lock+0x17/0x40
>  [<c012ce18>] _mutex_lock_irqsave+0x8/0x10
>  [<c01b21ae>] avc_has_perm_noaudit+0x2e/0x180
>  [<c01b2335>] avc_has_perm+0x35/0x68
>  [<c01b79ca>] ipc_has_perm+0x6a/0x80
>  [<c01ab716>] semctl_main+0xa6/0x410
>  [<c01abcad>] sys_semctl+0xad/0xb0
>  [<c010bafd>] sys_ipc+0xad/0x250
>  [<c0105bff>] syscall_call+0x7/0xb

thanks - that's the IPC code that is not converted over from RCU yet.

a suggestion for future testing: please enable PREEMPT_TIMING for the
next kernels you build, it will print such entries at the end of
stacktraces:

 preempt count: 2
 entry 1: cpu_idle+0x38/0x90 / (start_kernel+0x1ac/0x1f0)
 entry 2: _spin_lock+0x22/0x80 / (timer_interrupt+0x1b/0x130)

while in this particular IPC case it's immediately visible that it's the
IPC RCU use that is the root of the problem, the preemption trace
printout can be very helpful in other cases to quickly identify where
the preemptible section was started. E.g. the networking code sometimes
has very deep nesting and non-obvious locking. Thanks,

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/