Re: [RFC] RT-patch update to remove the global pi_lock

[Steven Rostedt]

On Thu, 2005-08-25 at 21:34 +0200, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> 
> > > does the system truly lock up, or is this some transitional condition?  
> > > In any case, i agree that this should be debugged independently of the 
> > > pi_lock patch.
> > 
> > Hmm, I forgot that you took out the bit_spin_lock fixes.  I think this 
> > may be caused by them.  I haven't look further into it yet.
> 
> yeah, i took them out because they clashed with upstream changes. Note 
> that i meanwhile also introduced a per-bh lock, which might make it 
> easier to fix the deadlock:
> 
>  --- linux.orig/fs/buffer.c
>  +++ linux/fs/buffer.c
>  @@ -537,8 +537,7 @@ static void end_buffer_async_read(struct
>           * decide that the page is now completely done.
>           */
>          first = page_buffers(page);
>  -       local_irq_save(flags);
>  -       bit_spin_lock(BH_Uptodate_Lock, &first->b_state);
>  +       spin_lock_irqsave(&first->b_uptodate_lock, flags);
>          clear_buffer_async_read(bh);
>          unlock_buffer(bh);
>          tmp = bh;
> 
> could jbd reuse this lock - or would it need another lock?

I think it can.  I'm looking into right now, but first I'm updating my
logdev to the latest release.  I stripped it all out after submitting
that pi_lock patch and now I have to put it back in!   I didn't save the
updates that I added earlier, so I'm reworking things now.  The logging
definitely helps me, since that was a major factor in getting that
pi_lock patch done so quick.

-- Steve


-
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/