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

Re: Extended Attributes and Access Control Lists


On Fri, Nov 02, 2001 at 11:50:44AM -0800, Andrew Morton wrote:

> I think before we change anything we need a 100% understanding
> of exactly what's going on.

Yep, so we should try to reproduce with tracing.  If you don't get
anywhere with it I'll try once I'm back from ALS in a week's time.

> How about this: I'll take a look at reproducing Eric's testcase
> with tracing enabled and work out what's happening. We can then
> make a decision as to whether
> 1: Calling get_write_access() against a dirty, unjournalled
>    buffer is illegal or

The specific case I'm thinking about is checkpointed buffers getting

The checkpoint code batches up a list of buffers to be written out,
then calls __flush_batch to flush them.  __flush_batch will lock the
buffers then even if we've marked them clean since: ll_rw_block always
takes the buffer lock before checking the buffer dirty or uptodate

So we've got a scenario in the checkpoint code where the buffer can
get locked without the journal or journal_datalist locks held, just
because the buffer was previously placed on the flush batch list.

If do_get_write_access hits one of these, we're in trouble.  In this
case everything is eventually harmless because the locked buffer
should be found to be clean and hence won't be flushed to disk,

To be sure what's happening, we need to know at least the state of the
buffer when the assert fails, and preferably its trace history, but
I'm fairly sure that the scenario above can happen.

What to do about it?  If we're sure, just drop the assert, or change
it to test buffer_dirty() instead (have to be careful to think about
this first, and we're about to land in SFO so I'll leave that until


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