On Tue, Apr 21, 2015 at 11:11:30AM -0700, Andi Kleen wrote: > From: Andi Kleen <ak@xxxxxxxxxxxxxxx> > > 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> > --- > mm/memory-failure.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/mm/memory-failure.c b/mm/memory-failure.c > index 25c2054..d553993 100644 > --- a/mm/memory-failure.c > +++ b/mm/memory-failure.c > @@ -20,6 +20,13 @@ > * 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 if: > + * - You know how to test it. > + * - You have a test that can be added to mce-test > + * - 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 > -- > 1.9.3 > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href