![]() | |||||||||||
Messages in this thread |
On Mon, 2005-06-13 at 09:53 +0200, Esben Nielsen wrote: > On Mon, 13 Jun 2005, Sven-Thorsten Dietrich wrote: > > > > > > > Hi Esben, > > > > I just wondered if you are talking about the scenario where an interrupt > > is executing on one processor, and gets preempted. Then some code runs > > on the same CPU, which does local_irq_disable (now preempt_disable), to > > keep that IRQ from running, but the IRQ thread is already started? > > > > In the community kernel, this could never happen, because IRQs can't be > > preempted. But in RT, its possible an IRQ could be preempted, and under > > some circumstance, this sequence could occur. > > > > Is that is what you are talking about? If not, it might be over my head, > > and I am sorry. If so, I think that scenario is covered under SMP. > > > > Sven > > > No, Sven it is not. I am not so worried about that scenario. > I am worried about some coder somewhere still using local_irq_disable() - > there is a lot of code out there doing that. We have not confirmed that > all of it really locks small enough regions to preserver RT preemption. > I for one is doubtfull about the cmos_lock thingy. (Sorry, can't connect > to my machine at home to check where it is, right now.) A very weird setup > with a kind of homebrewn spinlock. > All these cases needs to be reviewed to see if it is valid to use a > global lock type like local_irq_disable() or a local mutex must be used. > The former is only "allowed" if the time being within the locked is > deterministicly only in the order of the time for scheduling. > I wanted to add a extra name to the namespace stating "this usage of > local_irq_disable() have been reviwed wrt. RT_PREEMPT". I am sure there are some issues like you describe out there. I suppose we could examine each local_irq_disable, but I wonder if there is not a better way. I wrote earlier, that we could just keep specific IRQ threads from runnning, rather than disabling preemption overall. This is somewhat orthogonal, but would serve as a filter to break things down into local_irq_disable to keep a specific IRQ from running, and local_irq_disable to suppress all IRQ activity. If we're going to walk trough all these local_irq_disables, we might as well check-off that item as well. What do you think? Sven - 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: 2005-06-13 10:09 [from the cache] ©2003-2008 | |||||||||||