Query about might_sleep()

Query about might_sleep()

[doug lkml]

Hi,

   I am relatively new to RT. I have a query w.r.t might_sleep. I
might be asking on the wrong mailing list(perhaps I should try kernel
newbies).

   AFAIU, might_sleep() in a function means, the function can sleep.
If this function is called in atomic/interrupt context the kernel
throws out
 BUG: sleeping function called from invalid context at kernel/rtmu
tex.c. Am I correct so far?

   I was browsing the source, in rtmutex.c, in function rt_spin_lock(), which
calls rt_spin_lock_fastlock, there's a might_sleep() that's getting
called. I understand this is possible as spin_locks in PREEMPT_RT are
mutexes. But there could be a condition where this could be called
from some code holding spin_lock right?

for example

 __might_sleep
 rt_spin_lock
some_fucnction() --> which has a
local_irq_save(flags)/local_irq_irqrestore(flags).

This could be a potential bug right?

- Doug

Re: Query about might_sleep()

[Steven Rostedt]

On Wed, 26 Feb 2014 12:25:53 +0530
doug lkml <doug.lkml@gmail.com> wrote:

> for example
> 
>  __might_sleep
>  rt_spin_lock
> some_fucnction() --> which has a
> local_irq_save(flags)/local_irq_irqrestore(flags).
> 
> This could be a potential bug right?

Not that I see.

In -rt, we convert all spin_locks() into rt_mutex() which means they
might sleep on contention. We do not convert raw_spin_locks(), they
stay the same both in mainline and -rt.

The following is OK:

  rt_mutex()
    __might_sleep()
    some_function()
      local_irq_save()
      local_irq_restore()

Indention show what calls what.

But if you have:

  local_irq_save()
  some_function();
    rt_mutex();
  local_irq_restore();

Now the above *is* a bug.

Is that what you are asking?

-- Steve

Re: Query about might_sleep()

[doug lkml]

Steven,

> In -rt, we convert all spin_locks() into rt_mutex() which means they
> might sleep on contention. We do not convert raw_spin_locks(), they
> stay the same both in mainline and -rt.
>
> The following is OK:
>
>   rt_mutex()
>     __might_sleep()
>     some_function()
>       local_irq_save()
>       local_irq_restore()
>
> Indention show what calls what.
>
> But if you have:
>
>   local_irq_save()
>   some_function();
>     rt_mutex();
>   local_irq_restore();
>
> Now the above *is* a bug.
>
> Is that what you are asking?
>

I think I quoted my example incorrectly.

I put it across as a stack trace, rather than the way you've put it across.
Here's what I had in mind,

local_irq_save();
  some_function();
      rt_spin_lock() --> this calls __might_sleep
local_irq_restore(); --> In this case there's a bug right?


- Doug

Re: Query about might_sleep()

[Steven Rostedt]

On Thu, 27 Feb 2014 09:07:39 +0530
doug lkml <doug.lkml@gmail.com> wrote:

> I put it across as a stack trace, rather than the way you've put it across.
> Here's what I had in mind,
> 
> local_irq_save();
>   some_function();
>       rt_spin_lock() --> this calls __might_sleep
> local_irq_restore(); --> In this case there's a bug right?

Yes, that's a bug. And that's why you'll see a lot of updates in the
-rt patch with things like: local_irq_save_nort(). And this is also the
cause of some of the #ifdef CONFIG_PREEMPT_RT_FULL. And what makes this
change so challenging ;-)

-- Steve

Re: Query about might_sleep()

[doug lkml]

>>
>> local_irq_save();
>>   some_function();
>>       rt_spin_lock() --> this calls __might_sleep
>> local_irq_restore(); --> In this case there's a bug right?
>
> Yes, that's a bug. And that's why you'll see a lot of updates in the
> -rt patch with things like: local_irq_save_nort(). And this is also the
> cause of some of the #ifdef CONFIG_PREEMPT_RT_FULL. And what makes this
> change so challenging ;-)

That clarifies my question. Thanks.