perusing some timer-related kernel stuff and i ran across this in include/linux/hardirq.h: /* * Are we running in atomic context? WARNING: this macro cannot * always detect atomic context; in particular, it cannot know about * held spinlocks in non-preemptible kernels. Thus it should not be * used in the general case to determine whether sleeping is possible. * Do not use in_atomic() in driver code. */ #define in_atomic() ((preempt_count() & ~PREEMPT_ACTIVE) != PREEMPT_INATOMIC_BASE) but a quick check shows a sprinkling of in_atomic() checks in the drivers/ directory. is that admonition overly strict? or what? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
On Sun, May 15, 2011 at 03:22:10PM -0400, Robert P. J. Day wrote:
perusing some timer-related kernel stuff and i ran across this in include/linux/hardirq.h:
/* * Are we running in atomic context? WARNING: this macro cannot * always detect atomic context; in particular, it cannot know about * held spinlocks in non-preemptible kernels. Thus it should not be * used in the general case to determine whether sleeping is possible. * Do not use in_atomic() in driver code. */ #define in_atomic() ((preempt_count() & ~PREEMPT_ACTIVE) != PREEMPT_INATOMIC_BASE)
but a quick check shows a sprinkling of in_atomic() checks in the drivers/ directory. is that admonition overly strict? or what?
No, it's right, using it is wrong, but unfortunatly, it sometimes is the best that we have to use. Fixing this in the drivers would be great to do, feel free to add it to the kernel janitor's TODO list. greg k-h
participants (2)
-
Greg KH -
Robert P. J. Day