Prev: [PATCH V2 09/17] MAINTAINERS: Add STAGING - INDUSTRIAL IO
Next: EXT3 File System Corruption 2.6.34
From: Andrew Morton on 7 Jun 2010 16:30
On Sat, 22 May 2010 23:05:03 -0700
Greg Thelen <gthelen(a)google.com> wrote:

> > --- a/fs/buffer.c~buffer_head-remove-redundant-test-from-wait_on_buffer-fix
> > +++ a/fs/buffer.c
> > @@ -90,6 +90,12 @@ EXPORT_SYMBOL(unlock_buffer);
> > */
> > void __wait_on_buffer(struct buffer_head * bh)
> > {
> > + /*
> > + * Calling wait_on_buffer() against a zero-ref buffer is a nasty bug
> > + * because it will almost always "work". However this buffer can be
> > + * reclaimed at any time. So check for it.
> > + */
> > + VM_BUG_ON(atomic_read(&bh->b_count) == 0);
>
> My system is failing this VM_BUG_ON() occasionally. I think this is due to
> wait_on_buffer() calls with b_count=0 from locations within fs/buffer.c.

Thanks.

Yup, the buffers are protected by lock_page().

> These
> occasional b_count=0 callers are caused by buf reads that complete quickly -
> after the I/O is issued but before it is waited upon. Such fs/buffer.c callers
> need to either bypass this assertion or increment b_count. I don't think they
> need to grab an b_count reference. I suggest a bypass routine in the patch
> below. Does this look good?

I think I'll just drop
buffer_head-remove-redundant-test-from-wait_on_buffer-fix.patch and
wait_on_buffer-remove-the-buffer_locked-test.patch.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH V2 09/17] MAINTAINERS: Add STAGING - INDUSTRIAL IO
Next: EXT3 File System Corruption 2.6.34