From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 4/6] libxfs: reused invalidated buffers leak state and data
Date: Mon, 7 Jul 2014 10:09:29 +1000 [thread overview]
Message-ID: <20140707000929.GR9508@dastard> (raw)
In-Reply-To: <20140706235444.GP9508@dastard>
On Mon, Jul 07, 2014 at 09:54:44AM +1000, Dave Chinner wrote:
> On Sat, Jul 05, 2014 at 02:48:07AM -0700, Christoph Hellwig wrote:
> > On Sat, Jul 05, 2014 at 08:22:10AM +1000, Dave Chinner wrote:
> > > I'm open to other ways of fixing this, but right now we've got to
> > > fix xfs_repair because it's currently breaking filesystems worse
> > > than before xfs_repair was run...
> >
> > Ok, so clearly mark this as difference from kernel code in a long
> > comment explaining the situation similar to wrote you above.
>
> Will do.
Ok, I added this to the top of the libxfs/rdwr.c file:
/*
* Important design/architecture note:
*
* The userspace code that uses the buffer cache is much less constrained than
* the kernel code. The userspace code is pretty nasty in places, especially
* when it comes to buffer error handling. Very little of the userspace code
* outside libxfs clears bp->b_error - very little code even checks it - so the
* libxfs code is tripping on stale errors left by the userspace code.
*
* We can't clear errors or zero buffer contents in libxfs_getbuf-* like we do
* in the kernel, because those functions are used by the libxfs_readbuf_*
* functions and hence need to leave the buffers unchanged on cache hits. This
* is actually the only way to gather a write error from a libxfs_writebuf()
* call - you need to get the buffer again so you can check bp->b_error field -
* assuming that the buffer is still in the cache when you check, that is.
*
* This is very different to the kernel code which does not release buffers on a
* write so we can wait on IO and check errors. The kernel buffer cache also
* guarantees a buffer of a known initial state from xfs_buf_get() even on a
* cache hit.
*
* IOWs, userspace is behaving quite differently to the kernel and as a result
* it leaks errors from reads, invalidations and writes through
* libxfs_getbuf/libxfs_readbuf.
*
* The result of this is that until the userspace code outside libxfs is cleaned
* up, functions that release buffers from userspace control (i.e
* libxfs_writebuf/libxfs_putbuf) need to zero bp->b_error to prevent
* propagation of stale errors into future buffer operations.
*/
Is that sufficient for the moment?
-Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-07-07 0:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-04 5:57 [PATCH 0/6] xfsprogs: fixes for 3.2.1 Dave Chinner
2014-07-04 5:57 ` [PATCH 1/6] repair: support more than 25 ACLs Dave Chinner
2014-07-04 14:23 ` Christoph Hellwig
2014-07-04 5:57 ` [PATCH 2/6] xfs_db: write command broken on 64 bit values Dave Chinner
2014-07-04 14:08 ` Christoph Hellwig
2014-07-04 5:57 ` [PATCH 3/6] repair: handle directory block corruption in phase 6 Dave Chinner
2014-07-04 14:24 ` Christoph Hellwig
2014-07-04 5:57 ` [PATCH 4/6] libxfs: reused invalidated buffers leak state and data Dave Chinner
2014-07-04 14:15 ` Christoph Hellwig
2014-07-04 22:22 ` Dave Chinner
2014-07-05 9:48 ` Christoph Hellwig
2014-07-06 23:54 ` Dave Chinner
2014-07-07 0:09 ` Dave Chinner [this message]
2014-07-07 10:05 ` Christoph Hellwig
2014-07-04 5:57 ` [PATCH 5/6] repair: fix quota inode handling in secondary superblocks Dave Chinner
2014-07-04 14:35 ` Christoph Hellwig
2014-07-04 5:57 ` [PATCH 6/6] repair: get rid of BADFSINO Dave Chinner
2014-07-04 14:15 ` Christoph Hellwig
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=20140707000929.GR9508@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