xfs
[Top] [All Lists]

Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_bu

To: Andi Kleen <ak@xxxxxxx>
Subject: Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c
From: Luben Tuikov <luben@xxxxxxxxxxxx>
Date: Wed, 23 Oct 2002 00:43:08 -0400
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, linux-xfs <linux-xfs@xxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxx>
Organization: Splentec Ltd.
References: <3DB49424.9E4CAC0F@xxxxxxxxxxxx> <20021022213140.A11191@xxxxxxxxxxxxx> <3DB5CC26.D5F4BB84@xxxxxxxxxxxx> <20021023051713.B17128@xxxxxxxxxxxxx> <3DB62268.79A724BC@xxxxxxxxxxxx> <20021023061850.A29006@xxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
Andi Kleen wrote:
> 
> > >From what I can see and read, wake_up() and wake_up_sync() both wake
> > up all non-exclusive sleepers and one exclusive sleeper.
> >
> > The NON _sync versions, OTOH, will call reschedule_idle(), which _may_
> > cause (if the conditions are favourable) _another_ task to run
> > on _another_ CPU (SMP), _before_ the wake_up() returns.
> 
> Yes of course. But other CPUs are completely independent anyways, so
> there can be tasks scheduled there any time, no matter if you call
> wake_up or not.
> 
> > This will cause a problem if that other task does IO on xfs
> > and the code is as it was several days ago.
> 
> Can you explain how exactly that leads to problems ?

Hmm, ``exactly'' -- I wish!

But shortly, a lock up.

I've only been looking at the code for 2 days,
but a number of things have caught my eye.

First, we were getting BUG in unlock_page(), see xfs-bugzilla
bug #182. Reducing the md page size to 4, made the problem to
seemingly go away.

Now we get mount in D state, when mounting a synced md array
through lvm, and sometimes the other way around, when md is
syncing... sleeping in pagebuf_iowait() indefinitely...

I really wish I could explain ``exactly'' how this leads
to problems, but for now I'm debugging.

Andy, you must admit that there are bugs! And given the BUG()s
we've been getting, they are somehow related to pb_*.

If I could explain ``exactly'' how, the bugs would be fixed and
we wouldn't be having this conversation.

Anyway, for now any lead is a good lead.

-- 
Luben


<Prev in Thread] Current Thread [Next in Thread>