The patch titled
Subject: mm, hwpoison: add comment describing when to add new cases
has been removed from the -mm tree. Its filename was
mm-hwpoison-add-comment-describing-when-to-add-new-cases.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
Subject: mm, hwpoison: add comment describing when to add new cases
Here's another comment fix for hwpoison.
It describes the "guiding principle" on when to add new
memory error recovery code.
Signed-off-by: Andi Kleen <ak@xxxxxxxxxxxxxxx>
Acked-by: Naoya Horiguchi <n-horiguchi@xxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/memory-failure.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff -puN mm/memory-failure.c~mm-hwpoison-add-comment-describing-when-to-add-new-cases mm/memory-failure.c
--- a/mm/memory-failure.c~mm-hwpoison-add-comment-describing-when-to-add-new-cases
+++ a/mm/memory-failure.c
@@ -20,6 +20,14 @@
* this code has to be extremely careful. Generally it tries to use
* normal locking rules, as in get the standard locks, even if that means
* the error handling takes potentially a long time.
+ *
+ * It can be very tempting to add handling for obscure cases here.
+ * In general any code for handling new cases should only be added iff:
+ * - You know how to test it.
+ * - You have a test that can be added to mce-test
+ * https://git.kernel.org/cgit/utils/cpu/mce/mce-test.git/
+ * - The case actually shows up as a frequent (top 10) page state in
+ * tools/vm/page-types when running a real workload.
*
* There are several operations here with exponential complexity because
* of unsuitable VM data structures. For example the operation to map back
_
Patches currently in -mm which might be from ak@xxxxxxxxxxxxxxx are
origin.patch
linux-next.patch
do_shared_fault-check-that-mmap_sem-is-held.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
