Re: use of preempt_count instead of in_atomic() at leds-gpio.c

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Tetsuo Handa
Date: Friday, March 21, 2008 - 8:11 am

Hello.


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.

Regards.
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Sun Mar 16, 11:43 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Thu Mar 20, 3:56 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Thu Mar 20, 5:36 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Thu Mar 20, 7:10 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Fri Mar 21, 5:37 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Tetsuo Handa, (Fri Mar 21, 8:11 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes H ..., (Wed Mar 26, 9:17 am)