From: Andi Kleen <andi@firstfloor.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Dave Chinner <david@fromorbit.com>, "Luck\,
Tony" <tony.luck@intel.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>, "Kleen\,
Andi" <andi.kleen@intel.com>, "Wu\,
Fengguang" <fengguang.wu@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jan Kara <jack@suse.cz>,
Jun'ichi Nomura <j-nomura@ce.jp.nec.com>,
Akira Fujita <a-fujita@rs.jp.nec.com>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm\@kvack.org" <linux-mm@kvack.org>,
"linux-ext4\@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 2/3] ext4: introduce ext4_error_remove_page
Date: Mon, 29 Oct 2012 12:07:04 -0700 [thread overview]
Message-ID: <m21ughksh3.fsf@firstfloor.org> (raw)
In-Reply-To: <20121029182455.GA7098@thunk.org> (Theodore Ts'o's message of "Mon, 29 Oct 2012 14:24:56 -0400")
Theodore Ts'o <tytso@mit.edu> writes:
>
> It's actually pretty easy to test this particular one,
Note the error can happen at any time.
> and certainly
> one of the things I'd strongly encourage in this patch series is the
> introduction of an interface via madvise
It already exists of course.
I would suggest to study the existing framework before more
suggestions.
> simulate an ECC hard error event. So I don't think "it's hard to
> test" is a reason not to do the right thing. Let's make it easy to
What you can't test doesn't work. It's that simple.
And memory error handling is extremly hard to test. The errors
can happen at any time. It's not a well defined event.
There are test suites for it of course (mce-test, mce-inject[1]),
but they needed a lot of engineering effort to be at where
they are.
[1] despite the best efforts of some current RAS developers
at breaking it.
> Note that the problem that we're dealing with is buffered writes; so
> it's quite possible that the process which wrote the file, thus
> dirtying the page cache, has already exited; so there's no way we can
> guarantee we can inform the process which wrote the file via a signal
> or a error code return.
Is that any different from other IO errors? It doesn't need to
be better.
> Also, if you're going to keep this state in memory, what happens if
> the inode gets pushed out of memory?
You lose the error, just like you do today with any other IO error.
We had a lot of discussions on this when the memory error handling
was originally introduced, that was the conclusuion.
I don't think a special panic knob for this makes sense either.
We already have multiple panic knobs for memory errors, that
can be used.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
--
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>
next prev parent reply other threads:[~2012-10-29 19:07 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-25 15:12 [PATCH 0/3] HWPOISON: improve error_remove_page() Naoya Horiguchi
2012-10-25 15:12 ` [PATCH 1/3] mm: print out information of file affected by memory error Naoya Horiguchi
2012-10-25 19:32 ` Jan Kara
2012-10-25 20:34 ` Naoya Horiguchi
2012-10-25 15:12 ` [PATCH 2/3] ext4: introduce ext4_error_remove_page Naoya Horiguchi
2012-10-25 19:39 ` Jan Kara
2012-10-26 6:12 ` Theodore Ts'o
2012-10-26 16:55 ` Luck, Tony
2012-10-26 18:46 ` Theodore Ts'o
2012-10-26 22:24 ` Luck, Tony
2012-10-27 22:16 ` Theodore Ts'o
2012-10-28 1:57 ` Naoya Horiguchi
2012-10-29 1:16 ` Dave Chinner
2012-10-29 2:40 ` Theodore Ts'o
2012-10-29 10:37 ` Andi Kleen
2012-10-29 11:05 ` Jun'ichi Nomura
2012-10-29 18:24 ` Theodore Ts'o
2012-10-29 18:55 ` Jan Kara
2012-10-29 19:07 ` Andi Kleen [this message]
2012-10-29 21:47 ` Naoya Horiguchi
2012-10-30 0:00 ` Jun'ichi Nomura
2012-10-29 18:11 ` Luck, Tony
2012-10-31 0:21 ` Dave Chinner
2012-10-26 18:50 ` Naoya Horiguchi
2012-10-25 15:12 ` [PATCH 3/3] ext3: introduce ext3_error_remove_page Naoya Horiguchi
2012-10-25 19:45 ` Jan Kara
2012-10-25 20:35 ` Naoya Horiguchi
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=m21ughksh3.fsf@firstfloor.org \
--to=andi@firstfloor.org \
--cc=a-fujita@rs.jp.nec.com \
--cc=akpm@linux-foundation.org \
--cc=andi.kleen@intel.com \
--cc=david@fromorbit.com \
--cc=fengguang.wu@intel.com \
--cc=j-nomura@ce.jp.nec.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=tony.luck@intel.com \
--cc=tytso@mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).