lkml.org 
[lkml]   [2008]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: use of preempt_count instead of in_atomic() at leds-gpio.c
Tetsuo Handa wrote:
> Hello.
>
>>> In short, you are saying that there is _no_ reliable way to determine
>>> am-i-called-from-inside-spinlock.
>> That's correct.
>
> So, it is impossible to know whether I am inside a spinlock or not.
> OK. That's not what I want to do.
>
> I want to make sure that my code (not a device driver) is called only from a context
> where use of down()/mutex_lock()/kmalloc(GFP_KERNEL)/get_user_pages()/kmap() etc. are permitted.
> Is "if (in_atomic()) return;" check a correct method for avoiding deadlocks
> when my code was accidentally called from a context
> where use of down()/mutex_lock()/kmalloc(GFP_KERNEL)/get_user_pages()/kmap() etc. are not permitted?
> I'm assuming that in_atomic() returns nonzero whenever scheduling is not permitted.

You shouldn't sleep while holding a spinlock. As soon as another thread
attempts to take the spinlock, it will be stuck in a busy-wait loop.

So, it's better if you specify that your code either can be called in
atomic context or must not be called in atomic context, and all callers
observe this restriction. Or callers pass a flag to your code which
says whether your code is allowed to sleep or not.
--
Stefan Richter
-=====-==--- --== =-=-=
http://arcgraph.de/sr/


\
 
 \ /
  Last update: 2008-03-21 17:57    [W:0.059 / U:2.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site