Hello Petr,
On (02/11/16 15:41), Petr Mladek wrote:
[..]
> > + console_may_schedule = !oops_in_progress &&
> > + preemptible() &&
> > + !rcu_preempt_depth();
> > return 1;
>
> We discussed this a lot but I am still a bit nervous ;-)
sure, no prob :-)
> Avoid scheduling when oops_in_progress makes sense.
>
> preemptible() takes care of preemption and IRQ contexts.
> The comment above explains that it is safe to use here.
>
> The check for rcu_preempt_depth() makes sense. But is it
> safe, please?
>
> rcu_preempt_depth() returns 0 if CONFIG_PREEMPT_RCU is not
> enabled. It means that you are not able to detect RCU read
> section and it might cause problems.
well, I believe it's ok. __rcu_read_lock() for CONFIG_PREEMPT_RCU
does current->rcu_read_lock_nesting++, so rcu_preempt_depth() works
as expected. otherwise, for !CONFIG_PREEMPT_RCU kernel,
__rcu_read_lock() does
if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
preempt_disable()
- if we run "CONFIG_PREEMPT_RCU" then rcu_preempt_depth()
works here.
- if we run "!CONFIG_PREEMPT_RCU && CONFIG_PREEMPT_COUNT"
then preemptible() works for us
- if we run "!CONFIG_PREEMPT_RCU && !CONFIG_PREEMPT_COUNT"
then preemptible() is always 0.
> I rather add Paul into CC.
thanks.
-ss
