lkml.org 
[lkml]   [2016]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2016-02-11 16:21    [W:0.153 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site