From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: fix error handling for synchronous writes
Date: Mon, 10 Jan 2011 11:21:09 +1100 [thread overview]
Message-ID: <20110110002109.GD28803@dastard> (raw)
In-Reply-To: <20110107130223.GB12134@infradead.org>
On Fri, Jan 07, 2011 at 08:02:23AM -0500, Christoph Hellwig wrote:
> If we get an IO error on a synchronous superblock write, we attach an
> error release function to it so that when the last reference goes away
> the release function is called and the buffer is invalidated and
> unlocked. The buffer is left locked until the release function is
> called so that other concurrent users of the buffer will be locked out
> until the buffer error is fully processed.
>
> Unfortunately, for the superblock buffer the filesyetm itself holds a
> reference to the buffer which prevents the reference count from
> dropping to zero and the release function being called. As a result,
> once an IO error occurs on a sync write, the buffer will never be
> unlocked and all future attempts to lock the buffer will hang.
>
> To make matters worse, this problems is not unique to such buffers;
> if there is a concurrent _xfs_buf_find() running, the lookup will grab
> a reference to the buffer and then wait on the buffer lock, preventing
> the reference count from ever falling to zero and hence unlocking the
> buffer.
>
> As such, the whole b_relse function implementation is broken because it
> cannot rely on the buffer reference count falling to zero to unlock the
> errored buffer. The synchronous write error path is the only path that
> uses this callback - it is used to ensure that the synchronous waiter
> gets the buffer error before the error state is cleared from the buffer
> by the release function.
>
> Given that the only sychronous buffer writes now go through xfs_bwrite
> and the error path in question can only occur for a write of a dirty,
> logged buffer, we can move most of the b_relse processing to happen
> inline in xfs_buf_iodone_callbacks, just like a normal I/O completion.
> In addition to that we make sure the error is not cleared in
> xfs_buf_iodone_callbacks, so that xfs_bwrite can reliably check it.
> Given that xfs_bwrite keeps the buffer locked until it has waited for
> it and checked the error this allows to reliably propagate the error
> to the caller, and make sure that the buffer is reliably unlocked.
>
> Given that xfs_buf_iodone_callbacks was the only instance of the
> b_relse callback we can remove it entirely.
>
> Based on earlier patches by Dave Chinner and Ajeet Yadav.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Reported-by: Ajeet Yadav <ajeet.yadav.77@gmail.com>
Passes xfsqa fine here.
Reviewed-by: Dave Chinner <dchinner@redhat.com>
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2011-01-10 0:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-07 13:02 [PATCH] xfs: fix error handling for synchronous writes Christoph Hellwig
2011-01-10 0:21 ` Dave Chinner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110110002109.GD28803@dastard \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox