On Mon, 2005-08-22 at 15:09 -0700, Andrew Morton wrote:
> James Bottomley <[EMAIL PROTECTED]> wrote:
> >
> > Of course, if we're going to go to all this trouble, the next question
> > that arises naturally is why not just reuse the radix-tree code to
> > implement idr anyway ... ?
>
> Yes, we co
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-08-21 at 10:27 -0700, Luben Tuikov wrote:
> > Is this the only use _you_ could find for a *radix tree*? ;-)
> > Since of course sd.c uses it just as an enumeration, according to
> > you this must be the only use? :-)
>
> And Dicto Simpl
On Sun, 2005-08-21 at 17:33 -0700, Luben Tuikov wrote:
> No preallocation is done from IRQ context. Do not spread FUD.
> It seems to me that you're unaware how IDR works and unaware how
> the driver works.
Argumentum ad Hominem now ... we'll get them all eventually.
Since you won't post the usag
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
James Bottomley <[EMAIL PROTECTED]> wrote:
>
> Of course, if we're going to go to all this trouble, the next question
> that arises naturally is why not just reuse the radix-tree code to
> implement idr anyway ... ?
Yes, we could probably have gone that way. radix-tree would need some
enhanceme
On Mon, 2005-08-22 at 09:28 -0500, James Bottomley wrote:
> > I think providing locking inside idr.c was always a mistake - generally we
> > rely on caller-provided locking for such things.
>
> Well, the reason is because they wanted lockless pre-alloc. If you do
> it locked, you can't use GFP_KE
On Sun, 2005-08-21 at 20:52 -0700, Andrew Morton wrote:
> erp. posix_timers has its own irq-safe lock, so we're doing extra,
> unneeded locking in that code path.
Possibly, the posix timer code is rather convoluted in this area so I'm
not entirely sure my analysis is correct.
> I think providing
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-08-21 at 08:49 -0700, Luben Tuikov wrote:
> > The caller is the aic94xx SAS LLDD. It uses IDR to generate unique
> > task tag for each SCSI task being submitted. It is then used to lookup
> > the task given the task tag, in effect usin
On 08/22/05 10:28, James Bottomley wrote:
> On Sun, 2005-08-21 at 20:52 -0700, Andrew Morton wrote:
>
>>erp. posix_timers has its own irq-safe lock, so we're doing extra,
>>unneeded locking in that code path.
>
>
> Possibly, the posix timer code is rather convoluted in this area so I'm
> not en
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?
>
On Sun, 2005-08-21 at 10:27 -0700, Luben Tuikov wrote:
> Is this the only use _you_ could find for a *radix tree*? ;-)
> Since of course sd.c uses it just as an enumeration, according to
> you this must be the only use? :-)
And Dicto Simpliciter to you too.
> It was designed as a general purpose
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> On Sun, 2005-08-21 at 08:49 -0700, Luben Tuikov wrote:
> > The caller is the aic94xx SAS LLDD. It uses IDR to generate unique
> > task tag for each SCSI task being submitted. It is then used to lookup
> > the task given the task tag, in effect usin
--- Luben Tuikov <[EMAIL PROTECTED]> wrote:
> --- James Bottomley <[EMAIL PROTECTED]> wrote:
> > However, there is an infrastructure in the block layer called the
> > generic tag infrastructure which was designed precisely for this purpose
> > and which is designed to operate in IRQ context.
>
> J
On Sun, 2005-08-21 at 08:49 -0700, Luben Tuikov wrote:
> The caller is the aic94xx SAS LLDD. It uses IDR to generate unique
> task tag for each SCSI task being submitted. It is then used to lookup
> the task given the task tag, in effect using IDR as a fast lookup table.
>
> Yes, I'm also not aw
--- Andrew Morton <[EMAIL PROTECTED]> wrote:
> Jim Houston <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, 2005-08-16 at 18:03, Luben Tuikov wrote:
> >
> > > If idr_get_new() or idr_remove() is used in IRQ context,
> > > then we may get a lockup when idr_pre_get was called
> > > in process context and
Jim Houston <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2005-08-16 at 18:03, Luben Tuikov wrote:
>
> > If idr_get_new() or idr_remove() is used in IRQ context,
> > then we may get a lockup when idr_pre_get was called
> > in process context and an IRQ interrupted while it held
> > the idp lock.
>
> Hi
On Tue, 2005-08-16 at 18:03, Luben Tuikov wrote:
> If idr_get_new() or idr_remove() is used in IRQ context,
> then we may get a lockup when idr_pre_get was called
> in process context and an IRQ interrupted while it held
> the idp lock.
Hi Everyone,
Luben's changes make sense please merge them.
Hi,
This patch allows idr to be used in irq context.
idr_pre_get() is necessary to be called before
idr_get_new() is called. No locking is necessary when
calling idr_pre_get().
But idr_get_new(), idr_find() and idr_remove()
must be serialized with respect to each other.
All of the aforemention
18 matches
Mail list logo
