On 08/21/05 23:52, Andrew Morton wrote:
> James Bottomley <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
