[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Extended Attributes and Access Control Lists



Hi,

On Thu, Nov 01, 2001 at 10:08:00PM +0000, Stephen C. Tweedie wrote:
> 
> On Thu, Nov 01, 2001 at 12:21:05PM -0800, Andrew Morton wrote:
> 
> > It looks like you're calling get_write_access() against a
> > locked buffer.  ext3 considers that a bug because a
> > locked buffer is presumably undergoing writeout to the
> > journal, and modifying it at that stage violates all sorts
> > of ordering requirements.
> 
> No, that should be fine --- getting the write access should cause an
> implicit wait on the buffer until it is unlocked, and should prevent
> future flushing of that buffer.

I take it back, that's bogus --- the buffer clearly expects to be
unlocked at this point.

We expect the callers to either be doing IO to new buffers (which
should not be undergoing IO), or to old buffers.  For the old buffers
case, the "uptodate" flag on the buffer is undefined while the buffer
is undergoing IO, so on any buffer cache lookup, we have to
wait_on_buffer() before it's safe to proceed.  Either way, by the time
the fs wants to modify the buffer, it should be unlocked.

Can it get locked by anybody else in the mean time?  For dirty
data, that's handled by different paths entirely.  For dirty metadata,
we check early on in the do_get_write_access() call path to see if
that's happening, and we pull the buffer off any write queues before
unlocking it.

Andrew, there may be a race if the buffer is locked at this point: we
go down the steal-from-checkpoint path, unlock the journal, then lock
the buffer, but that can block and somebody else can then modify
buffer state before we wake up.

I think we need to do something like

	if (buffer_locked(bh)) {
		unlock_journal(journal);
		wait_on_buffer(bh);
		lock_journal(journal);
		goto repeat;
	}

to make sure that we don't race with other jfs operations while
waiting on the buffer lock here.

I'm not convinced that that's the problem here, though --- running
with CONFIG_BUFFER_TRACE would be a great help in diagnosing this more
accurately.

Cheers,
 Stephen





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]