![]() | ||||||||||
Messages in this thread |
On Sun, 16 Mar 2008 11:46:23 -0800 David Brownell <david-b@pacbell.net> wrote: > On Sunday 16 March 2008, Henrique de Moraes Holschuh wrote: > > Is the use of "if (preempt_count())" to know when to defer led gpio work to > > a workqueue needed? __Shouldn't "if (in_atomic())" be enough? > > At this point, I don't know of any such reason. > > I remember hunting for the right heuristic, and settling on > that one for reasons that I can't recall now. They may even > be no longer applicable. Both are incorrect. When CONFIG_PREEMPT=n we have no support for determining whether schedule() may be called. The calling code has to sort out its stuff on its own. <greps for preempt_count> The LEDs code seems to be the sole offender. print_vma_addr() might be wrong too, but Ingo did it, and perhaps he knows that all code paths which call print_vma_addr() from deadlockable contexts have already called inc_preempt_count(). But is that true for all architectures? <greps for in_atomic> omigawd, what have we done, and how can we fix it? :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2008-03-18 07:17 [W:0.330 / U:0.280 seconds] ©2003-2008 Jasper Spaans | ||||||||||