linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: Tony Luck <tony.luck@intel.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	Andi Kleen <andi.kleen@intel.com>,
	Wu Fengguang <fengguang.wu@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>,
	Jun'ichi Nomura <j-nomura@ce.jp.nec.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] HWPOISON: improve handling/reporting of memory error on dirty pagecache
Date: Sun, 12 Aug 2012 11:57:54 -0400	[thread overview]
Message-ID: <1344787074-6795-1-git-send-email-n-horiguchi@ah.jp.nec.com> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F19375BFE@ORSMSX104.amr.corp.intel.com>

Hi Tony,

Thank you for the comment.

On Sat, Aug 11, 2012 at 10:41:49PM +0000, Luck, Tony wrote:
> > dirty pagecache error recoverable under some conditions. Consider that
> > if there is a copy of the corrupted dirty pagecache on user buffer and
> > you write() over the error page with the copy data, then we can ignore
> > the effect of the error because no one consumes the corrupted data.
> 
> This sounds like a quite rare corner case. If the page is already dirty, it is
> most likely because someone recently did a write(2) (or touched it via
> mmap(2)).

Yes, that's right.

> Now you are hoping that some process is going to write the
> same page again.  Do you have an application in mind where this would
> be common.

No, I don't, particularly.

> Remember that the write(2), memory-error, new write(2)
> have to happen close together (before Linux decides to write out the
> dirty page).

Maybe this is different from my scenario, where I assumed that a hwpoison-
aware application kicks the second write(2) when it catches a memory error
report from kernel, and this write(2) copies from the same buffer from
which the first write(2) copied into pagecache.
In many case, user space applications keep their buffers for a while after
calling write(2), so then we can consider that dirty pagecaches also can
have copies in the buffers. This is a key idea of error recovery.

And let me discuss about another point. When memory errors happen on
dirty pagecaches, they are isolated from pagecache trees. So neither
fsync(2) nor writeback can write out the corrupted data on the backing
devices. So I don't think that we have to be careful about closeness
between two write(2)s.

Thanks,
Naoya

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2012-08-12 15:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-10 21:41 [PATCH 0/3 v1] HWPOISON: improve dirty pagecache error handling Naoya Horiguchi
2012-08-10 21:41 ` [PATCH 1/3] HWPOISON: fix action_result() to print out dirty/clean Naoya Horiguchi
2012-08-10 23:08   ` Andi Kleen
2012-08-10 21:41 ` [PATCH 2/3] HWPOISON: undo memory error handling for dirty pagecache Naoya Horiguchi
2012-08-10 23:09   ` Andi Kleen
2012-08-11  0:58     ` Naoya Horiguchi
2012-08-13 10:10     ` Jun'ichi Nomura
2012-08-10 21:41 ` [PATCH 3/3] HWPOISON: improve handling/reporting of memory error on " Naoya Horiguchi
2012-08-10 22:01   ` Naoya Horiguchi
2012-08-10 23:13   ` Andi Kleen
2012-08-11  1:01     ` Naoya Horiguchi
2012-08-11 11:15   ` Andi Kleen
2012-08-11 21:14     ` Naoya Horiguchi
2012-08-12  3:28       ` Andi Kleen
2012-08-12 15:19         ` Naoya Horiguchi
2012-08-11 22:41   ` Luck, Tony
2012-08-12 15:57     ` Naoya Horiguchi [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=1344787074-6795-1-git-send-email-n-horiguchi@ah.jp.nec.com \
    --to=n-horiguchi@ah.jp.nec.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi.kleen@intel.com \
    --cc=fengguang.wu@intel.com \
    --cc=j-nomura@ce.jp.nec.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@redhat.com \
    --cc=tony.luck@intel.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