Re: [PATCH 2.6.12.5 1/2] lib: allow idr to be used in irq context

[Luben Tuikov <luben_tuikov@adaptec.com>]

On 08/21/05 23:52, Andrew Morton wrote:
> James Bottomley <James.Bottomley@SteelEye.com> wrote:
> 
>>Since you won't post the usage code, just answer this: how does what
>> you're doing with idr differ from its originally designed consumer: the
>> posix timers which also do the idr_remove() in IRQ context?
> 
> 
> erp.  posix_timers has its own irq-safe lock, so we're doing extra,
> unneeded locking in that code path.
> 
> I think providing locking inside idr.c was always a mistake - generally we
> rely on caller-provided locking for such things.

Ahhh, *THANK YOU* Andrew for your common sense!

Yes, James is unaware that 3 out of the 4 major entrances into IDR
_must_ be synchronized with respect to each other, depending
on your context (irq or not) *and* that that synchronization is
external.  If *one* of those 3 is done in IRQ context, then
all three should be, since they should be synchnornized wrt
each other.

Only idr_pre_get() should not be called from IRQ context.

*BUT* since idr_pre_get() and those other 3 may end up
in the same _internally_ locked region, _that_ internally
locked region should have the lowest common denominator lock,
_because_ of the other 3 which have to be syncrhonised wrt each other.

It is _this_ reason that the internal locking of IDR should use
use the lowest common denominator because of the context of
those other 3 which the _caller_ is responsible for synchronizing
depending on the caller's context.

Now James can we move on, please.

Andrew, please integrate this patch.

Thanks,
	Luben