Hi!
On Mon, May 06, 2002 at 11:31:27AM +0200, Olaf Frączyk <olaf@xxxxxxxxxxxxx>
wrote:
> Can somebody confirm it, or is it working now? (kernel 2.4.18).
> And I would like to know if it is safe to add lock breaking patch.
It does not work. I think the bug is not in XFS, nor lock break. It is
in the way they play together. I mean if you use them separately, everything
are ok. But as soon as you add either(!) XFS or JFS to lock break, you will
have problems.
I try to fix it with some kernel hackers including Robert M. Love, but
until now the bug is still out there. For me it seems that with a journaling
filesystem (XFS | JFS) a lock is acquired early in the boot process,
and never released. Thus it causes dead lock when you write on a loop mounted
filesystem (regardless of it's type).
I have not posted the current state of bug hunting here, but do it now:
fs/buffer.c in function wait_for_buffers():
if (conditional_schedule_needed() && nr_rescheds < 100) {
nr_rescheds++;
debug_lock_break(1);
spin_unlock(&lru_list_lock);
return -EAGAIN;
}
My test shows that if you write on a loop device then as soon as it would like
to sync to the disk, conditional_schedule_needed() will be constant one, and
nr_rescheds zero. Thus it will step into the if, and returns -EAGAIN. Thus
it tries again, and again etc. Deadlock, but I still does not know why
conditional_schedule_needed() is constant one in these cases.
(Forgot that I get a line next from the Init version 2.84 loading, which
shows that Sxxdevfs exited with preempt_count 1; and after this every process
show this at termination.)
If anyone has any idea, please share with me,
GCS
|