Messages in this thread | | | Date | Fri, 12 Feb 2016 00:02:17 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [RFC][PATCH v3 4/4] printk: set may_schedule for some of console_trylock callers |
| |
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
| |