login
Login / Register
Header Space

 
 

Home » Mailing list archives » linux-kernel » 2008 » March » 21

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

Score:
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
[view in full thread]
From: Tetsuo Handa <penguin-kernel@...>
To: <akpm@...>
Cc: <linux-kernel@...>
Subject: Re: use of preempt_count instead of in_atomic() at leds-gpio.c
Date: Friday, March 21, 2008 - 11: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 Holschuh..., (Sun Mar 16, 2:43 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, David Brownell, (Sun Mar 16, 3:46 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Andrew Morton, (Tue Mar 18, 3:14 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes Holschuh..., (Thu Mar 20, 6:56 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Andrew Morton, (Thu Mar 20, 7:47 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Richard Purdie, (Thu Mar 20, 8:56 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes Holschuh..., (Thu Mar 20, 10:10 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes Holschuh..., (Thu Mar 20, 8:36 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Andrew Morton, (Thu Mar 20, 9:08 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, David Brownell, (Fri Mar 21, 1:04 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Stefan Richter, (Fri Mar 21, 5:21 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes Holschuh..., (Fri Mar 21, 8:37 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Stefan Richter, (Fri Mar 21, 9:16 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Stefan Richter, (Sat Mar 22, 7:29 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Stefan Richter, (Fri Mar 21, 5:27 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Alan Stern, (Thu Mar 20, 9:31 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Michael Buesch, (Thu Mar 20, 9:36 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Andrew Morton, (Thu Mar 20, 10:27 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Heiko Carstens, (Fri Mar 21, 9:47 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Greg KH, (Fri Mar 21, 12:54 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Andrew Morton, (Fri Mar 21, 3:59 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Michael Buesch, (Fri Mar 21, 4:16 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Michael Buesch, (Fri Mar 21, 4:20 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Alan Stern, (Thu Mar 20, 11:07 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Andrew Morton, (Thu Mar 20, 11:17 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Tetsuo Handa, (Fri Mar 21, 11:11 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Stefan Richter, (Fri Mar 21, 12:54 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Stefan Richter, (Fri Mar 21, 1:02 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Tetsuo Handa, (Sun Mar 23, 1:53 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Jean Delvare, (Fri Mar 21, 5:53 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Andrew Morton, (Fri Mar 21, 1:37 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Alan Stern, (Fri Mar 21, 2:05 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio..., Jonathan Corbet, (Mon Mar 24, 3:34 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Andrew Morton, (Mon Mar 24, 3:42 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio..., Jonathan Corbet, (Mon Mar 24, 3:53 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Junio C Hamano, (Tue Mar 25, 4:52 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio..., Jonathan Corbet, (Tue Mar 25, 9:44 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, David Brownell, (Tue Mar 25, 7:20 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Alan Stern, (Wed Mar 26, 10:28 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Henrique de Moraes Holschuh..., (Wed Mar 26, 12:17 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, David Brownell, (Thu Mar 27, 2:51 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Richard Purdie, (Wed Mar 26, 12:46 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Jean Delvare, (Tue Mar 25, 6:39 am)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, David Brownell, (Tue Mar 18, 3:06 pm)
Re: use of preempt_count instead of in_atomic() at leds-gpio.c, Andrew Morton, (Tue Mar 18, 4:07 pm)

Mail archive search
Enter your search terms.
Optionally limit your search to a specific mailing list.
advanced
Colocation donated by:
Who's online
There are currently 2 users and 791 guests online.

Online users

Syndicate
Syndicate content
© 2007 KernelTrap.  |  Powered by Drupal.  |  Legal statement.
speck-geostationary