Re: [PATCH] local_irq_disable removal

[Sven-Thorsten Dietrich]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/