All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Dave Chinner <david@fromorbit.com>
Cc: aelder@sgi.com, Andi Kleen <andi@firstfloor.org>, xfs@oss.sgi.com
Subject: Re: xfs: outstanding patches for 2.6.39
Date: Wed, 23 Mar 2011 17:05:15 +0100	[thread overview]
Message-ID: <20110323160515.GF21838@one.firstfloor.org> (raw)
In-Reply-To: <20110323113803.GB26611@dastard>

> We can't do that right now, anyway.

It seemed to work on XFS when we tested it. Undoutedly after your
patch it won't work anymore.

> If the page is not in use, we don't care about it after this patch
> set is applied - the page is either active in a buffer or it has been
> freed. If it is in use, then we'll shut the filesystem down if we
> detect the memory corruption just like we currently do. Hence I
> don't see any regression here.

I think you're confusing the memory_failure() HWPoison path with some XFS
internal checking. I don't think XFS has any HWPoison checking on its own.

> As it is, there is no way for the filesytem to be notified about
> such failures on active pages in buffers, so in reality we can't
> reliably detect them so there is little point in trying to recover
> from such errors.

Well it works today if the page is in pagecache. memory-failure will
just remove it transparently.

In principle you can check for HWPoison manually yourself, but I'm not sure
that is a good way to do it.


-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2011-03-23 16:02 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-23  6:14 xfs: outstanding patches for 2.6.39 Dave Chinner
2011-03-23  6:14 ` [PATCH 1/6] xfs: preallocation transactions do not need to be synchronous Dave Chinner
2011-03-24 17:18   ` brian.foster
2011-03-24 22:53     ` [PATCH V2] " Dave Chinner
2011-03-25 21:00   ` [PATCH 1/6] " Alex Elder
2011-03-25 22:02     ` Dave Chinner
2011-03-23  6:14 ` [PATCH 2/6] vmap: flush vmap aliases when mapping fails Dave Chinner
2011-03-25 21:00   ` Alex Elder
2011-03-23  6:14 ` [PATCH 3/6] xfs: introduce inode cluster buffer trylocks for xfs_iflush Dave Chinner
2011-03-25 21:00   ` Alex Elder
2011-03-23  6:14 ` [PATCH 4/6] xfs: xfs_trans_read_buf() should return an error on failure Dave Chinner
2011-03-23 11:53   ` Christoph Hellwig
2011-03-25 21:01   ` Alex Elder
2011-03-23  6:14 ` [PATCH 5/6] xfs: register the inode cache shrinker before quotachecks Dave Chinner
2011-03-23 21:24   ` Arkadiusz Miskiewicz
2011-03-25 12:56     ` Michael Weissenbacher
2011-03-25 23:08       ` Dave Chinner
2011-03-25 21:01   ` Alex Elder
2011-03-23  6:14 ` [PATCH 6/6] xfs: stop using the page cache to back the buffer cache Dave Chinner
2011-03-25 21:02   ` Alex Elder
2011-03-25 22:04     ` Dave Chinner
2011-03-23  7:01 ` xfs: outstanding patches for 2.6.39 Andi Kleen
2011-03-23 11:38   ` Dave Chinner
2011-03-23 16:05     ` Andi Kleen [this message]
2011-03-23 22:48       ` Dave Chinner
2011-03-23 11:18 ` Christoph Hellwig
2011-03-23 11:38   ` Dave Chinner

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=20110323160515.GF21838@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=aelder@sgi.com \
    --cc=david@fromorbit.com \
    --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.