On Sat, Apr 20, 2002 at 05:00:23PM -0400, Robert Love wrote:
> On Sat, 2002-04-20 at 16:46, Andrew Morton wrote:
> > That's a livelock in the lock-break patch. Blame me for that.
>
> Not your fault I use your low-latency work in lock-break :)
>
> > It perhaps does imply that a large number of buffers of the
> > wrong dirty state are getting onto the wrong list. JFS
> > maybe missing a refile_buffer() call somewhere.
> >
> > Robert, I've updated the ll-patch thusly (hack atop of hack):
>
> Thank you very much, Andrew. I'll make the required changes too.
Robert, have you also looked at the initial bug report?
It triggers a debug_lock_break(551), and my reading of the lock_break
stuff is that 551 is your magic constant for "should not happen"..
Althouhh I haven't found out in which function as the patch in whiches
context this happened is to big to understand without applying I guess
it is fsync_inode_buffers. Rationale: besides the different lists
they operate on fsync_inode_buffers and fsync_inode_data_buffers are the
same thing in mainline (XXX: backport Al's 2.5 change to make both call a
generic version taking a list_head), but the lock_break stuff is different
without any reaon understandable to me.
GCS: could you please rerun your testcase after you replaced the occurance
of debug_lock_break(551); in fsync_inode_buffers with debug_lock_break(1)
and retry?
Christoph
_______________________________________________
Jfs-discussion mailing list
[EMAIL PROTECTED]
http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jfs-discussion
