All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.