All of lore.kernel.org
 help / color / mirror / Atom feed
* Is MADV_HWPOISON supposed to work only on faulted-in pages?
@ 2017-02-14 15:41 ` Jan Stancek
  0 siblings, 0 replies; 26+ messages in thread
From: Jan Stancek @ 2017-02-14 15:41 UTC (permalink / raw)
  To: linux-mm; +Cc: ltp

Hi,

code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
unless I touch/prefault page before call to madvise().

Is this expected behavior?

Thanks,
Jan

[1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise07.c

-------------------- 8< --------------------
#include <stdlib.h>
#include <sys/mman.h>
#include <unistd.h>

int main(void)
{
	void *mem = mmap(NULL, getpagesize(), PROT_READ | PROT_WRITE,
			MAP_ANONYMOUS | MAP_PRIVATE /*| MAP_POPULATE*/,
			-1, 0);

	if (mem == MAP_FAILED)
		exit(1);

	if (madvise(mem, getpagesize(), MADV_HWPOISON) == -1)
		exit(1);

	*((char *)mem) = 'd';

	return 0;
}
-------------------- 8< --------------------

--
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>

^ permalink raw reply	[flat|nested] 26+ messages in thread
* [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
@ 2017-02-14 15:41 ` Jan Stancek
  0 siblings, 0 replies; 26+ messages in thread
From: Jan Stancek @ 2017-02-14 15:41 UTC (permalink / raw)
  To: ltp

Hi,

code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
unless I touch/prefault page before call to madvise().

Is this expected behavior?

Thanks,
Jan

[1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise07.c

-------------------- 8< --------------------
#include <stdlib.h>
#include <sys/mman.h>
#include <unistd.h>

int main(void)
{
	void *mem = mmap(NULL, getpagesize(), PROT_READ | PROT_WRITE,
			MAP_ANONYMOUS | MAP_PRIVATE /*| MAP_POPULATE*/,
			-1, 0);

	if (mem == MAP_FAILED)
		exit(1);

	if (madvise(mem, getpagesize(), MADV_HWPOISON) == -1)
		exit(1);

	*((char *)mem) = 'd';

	return 0;
}
-------------------- 8< --------------------

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: Is MADV_HWPOISON supposed to work only on faulted-in pages?
  2017-02-14 15:41 ` [LTP] " Jan Stancek
@ 2017-02-20  5:00   ` Naoya Horiguchi
  -1 siblings, 0 replies; 26+ messages in thread
From: Naoya Horiguchi @ 2017-02-20  5:00 UTC (permalink / raw)
  To: Jan Stancek; +Cc: linux-mm, ltp

On Tue, Feb 14, 2017 at 04:41:29PM +0100, Jan Stancek wrote:
> Hi,
>
> code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
> unless I touch/prefault page before call to madvise().
>
> Is this expected behavior?

Thank you for reporting.

madvise(MADV_HWPOISON) triggers page fault when called on the address
over which no page is faulted-in, so I think that SIGBUS should be
called in such case.

But it seems that memory error handler considers such a page as "reserved
kernel page" and recovery action fails (see below.)

  [  383.371372] Injecting memory failure for page 0x1f10 at 0x7efcdc569000
  [  383.375678] Memory failure: 0x1f10: reserved kernel page still referenced by 1 users
  [  383.377570] Memory failure: 0x1f10: recovery action for reserved kernel page: Failed

I'm not sure how/when this behavior was introduced, so I try to understand.
IMO, the test code below looks valid to me, so no need to change.

Thanks,
Naoya Horiguchi

>
> Thanks,
> Jan
>
> [1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise07.c
>
> -------------------- 8< --------------------
> #include <stdlib.h>
> #include <sys/mman.h>
> #include <unistd.h>
>
> int main(void)
> {
> 	void *mem = mmap(NULL, getpagesize(), PROT_READ | PROT_WRITE,
> 			MAP_ANONYMOUS | MAP_PRIVATE /*| MAP_POPULATE*/,
> 			-1, 0);
>
> 	if (mem == MAP_FAILED)
> 		exit(1);
>
> 	if (madvise(mem, getpagesize(), MADV_HWPOISON) == -1)
> 		exit(1);
>
> 	*((char *)mem) = 'd';
>
> 	return 0;
> }
> -------------------- 8< --------------------
>
> --
> 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>
--
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>

^ permalink raw reply	[flat|nested] 26+ messages in thread
* [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
@ 2017-02-20  5:00   ` Naoya Horiguchi
  0 siblings, 0 replies; 26+ messages in thread
From: Naoya Horiguchi @ 2017-02-20  5:00 UTC (permalink / raw)
  To: ltp

On Tue, Feb 14, 2017 at 04:41:29PM +0100, Jan Stancek wrote:
> Hi,
>
> code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
> unless I touch/prefault page before call to madvise().
>
> Is this expected behavior?

Thank you for reporting.

madvise(MADV_HWPOISON) triggers page fault when called on the address
over which no page is faulted-in, so I think that SIGBUS should be
called in such case.

But it seems that memory error handler considers such a page as "reserved
kernel page" and recovery action fails (see below.)

  [  383.371372] Injecting memory failure for page 0x1f10 at 0x7efcdc569000
  [  383.375678] Memory failure: 0x1f10: reserved kernel page still referenced by 1 users
  [  383.377570] Memory failure: 0x1f10: recovery action for reserved kernel page: Failed

I'm not sure how/when this behavior was introduced, so I try to understand.
IMO, the test code below looks valid to me, so no need to change.

Thanks,
Naoya Horiguchi

>
> Thanks,
> Jan
>
> [1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise07.c
>
> -------------------- 8< --------------------
> #include <stdlib.h>
> #include <sys/mman.h>
> #include <unistd.h>
>
> int main(void)
> {
> 	void *mem = mmap(NULL, getpagesize(), PROT_READ | PROT_WRITE,
> 			MAP_ANONYMOUS | MAP_PRIVATE /*| MAP_POPULATE*/,
> 			-1, 0);
>
> 	if (mem == MAP_FAILED)
> 		exit(1);
>
> 	if (madvise(mem, getpagesize(), MADV_HWPOISON) == -1)
> 		exit(1);
>
> 	*((char *)mem) = 'd';
>
> 	return 0;
> }
> -------------------- 8< --------------------
>
> --
> 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>

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: Is MADV_HWPOISON supposed to work only on faulted-in pages?
  2017-02-20  5:00   ` [LTP] " Naoya Horiguchi
@ 2017-02-23  3:23     ` Naoya Horiguchi
  -1 siblings, 0 replies; 26+ messages in thread
From: Naoya Horiguchi @ 2017-02-23  3:23 UTC (permalink / raw)
  To: Jan Stancek; +Cc: linux-mm, ltp

On Mon, Feb 20, 2017 at 05:00:17AM +0000, Horiguchi Naoya(堀口 直也) wrote:
> On Tue, Feb 14, 2017 at 04:41:29PM +0100, Jan Stancek wrote:
> > Hi,
> >
> > code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
> > unless I touch/prefault page before call to madvise().
> >
> > Is this expected behavior?
> 
> Thank you for reporting.
> 
> madvise(MADV_HWPOISON) triggers page fault when called on the address
> over which no page is faulted-in, so I think that SIGBUS should be
> called in such case.
> 
> But it seems that memory error handler considers such a page as "reserved
> kernel page" and recovery action fails (see below.)
> 
>   [  383.371372] Injecting memory failure for page 0x1f10 at 0x7efcdc569000
>   [  383.375678] Memory failure: 0x1f10: reserved kernel page still referenced by 1 users
>   [  383.377570] Memory failure: 0x1f10: recovery action for reserved kernel page: Failed
> 
> I'm not sure how/when this behavior was introduced, so I try to understand.

I found that this is a zero page, which is not recoverable for memory
error now.

> IMO, the test code below looks valid to me, so no need to change.

I think that what the testcase effectively does is to test whether memory
handling on zero pages works or not.
And the testcase's failure seems acceptable, because it's simply not-implemented yet.
Maybe recovering from error on zero page is possible (because there's no data
loss for memory error,) but I'm not sure that code might be simple enough and/or
it's worth doing ...

Thanks,
Naoya Horiguchi
--
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>

^ permalink raw reply	[flat|nested] 26+ messages in thread
* [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
@ 2017-02-23  3:23     ` Naoya Horiguchi
  0 siblings, 0 replies; 26+ messages in thread
From: Naoya Horiguchi @ 2017-02-23  3:23 UTC (permalink / raw)
  To: ltp

On Mon, Feb 20, 2017 at 05:00:17AM +0000, Horiguchi Naoya(堀口 直也) wrote:
> On Tue, Feb 14, 2017 at 04:41:29PM +0100, Jan Stancek wrote:
> > Hi,
> >
> > code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
> > unless I touch/prefault page before call to madvise().
> >
> > Is this expected behavior?
> 
> Thank you for reporting.
> 
> madvise(MADV_HWPOISON) triggers page fault when called on the address
> over which no page is faulted-in, so I think that SIGBUS should be
> called in such case.
> 
> But it seems that memory error handler considers such a page as "reserved
> kernel page" and recovery action fails (see below.)
> 
>   [  383.371372] Injecting memory failure for page 0x1f10 at 0x7efcdc569000
>   [  383.375678] Memory failure: 0x1f10: reserved kernel page still referenced by 1 users
>   [  383.377570] Memory failure: 0x1f10: recovery action for reserved kernel page: Failed
> 
> I'm not sure how/when this behavior was introduced, so I try to understand.

I found that this is a zero page, which is not recoverable for memory
error now.

> IMO, the test code below looks valid to me, so no need to change.

I think that what the testcase effectively does is to test whether memory
handling on zero pages works or not.
And the testcase's failure seems acceptable, because it's simply not-implemented yet.
Maybe recovering from error on zero page is possible (because there's no data
loss for memory error,) but I'm not sure that code might be simple enough and/or
it's worth doing ...

Thanks,
Naoya Horiguchi

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: Is MADV_HWPOISON supposed to work only on faulted-in pages?
  2017-02-23  3:23     ` [LTP] " Naoya Horiguchi
@ 2017-02-25  2:28       ` Yisheng Xie
  -1 siblings, 0 replies; 26+ messages in thread
From: Yisheng Xie @ 2017-02-25  2:28 UTC (permalink / raw)
  To: Naoya Horiguchi, Jan Stancek; +Cc: linux-mm, ltp

hi Naoya,

On 2017/2/23 11:23, Naoya Horiguchi wrote:
> On Mon, Feb 20, 2017 at 05:00:17AM +0000, Horiguchi Naoya(堀口 直也) wrote:
>> On Tue, Feb 14, 2017 at 04:41:29PM +0100, Jan Stancek wrote:
>>> Hi,
>>>
>>> code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
>>> unless I touch/prefault page before call to madvise().
>>>
>>> Is this expected behavior?
>>
>> Thank you for reporting.
>>
>> madvise(MADV_HWPOISON) triggers page fault when called on the address
>> over which no page is faulted-in, so I think that SIGBUS should be
>> called in such case.
>>
>> But it seems that memory error handler considers such a page as "reserved
>> kernel page" and recovery action fails (see below.)
>>
>>   [  383.371372] Injecting memory failure for page 0x1f10 at 0x7efcdc569000
>>   [  383.375678] Memory failure: 0x1f10: reserved kernel page still referenced by 1 users
>>   [  383.377570] Memory failure: 0x1f10: recovery action for reserved kernel page: Failed
>>
>> I'm not sure how/when this behavior was introduced, so I try to understand.
> 
> I found that this is a zero page, which is not recoverable for memory
> error now.
> 
>> IMO, the test code below looks valid to me, so no need to change.
> 
> I think that what the testcase effectively does is to test whether memory
> handling on zero pages works or not.
> And the testcase's failure seems acceptable, because it's simply not-implemented yet.
> Maybe recovering from error on zero page is possible (because there's no data
> loss for memory error,) but I'm not sure that code might be simple enough and/or
> it's worth doing ...
I question about it,  if a memory error happened on zero page, it will
cause all of data read from zero page is error, I mean no-zero, right?
And can we just use re-initial it with zero data maybe by memset ?

Thanks
Yisheng Xie.


--
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>

^ permalink raw reply	[flat|nested] 26+ messages in thread
* [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
@ 2017-02-25  2:28       ` Yisheng Xie
  0 siblings, 0 replies; 26+ messages in thread
From: Yisheng Xie @ 2017-02-25  2:28 UTC (permalink / raw)
  To: ltp

hi Naoya,

On 2017/2/23 11:23, Naoya Horiguchi wrote:
> On Mon, Feb 20, 2017 at 05:00:17AM +0000, Horiguchi Naoya(堀口 直也) wrote:
>> On Tue, Feb 14, 2017 at 04:41:29PM +0100, Jan Stancek wrote:
>>> Hi,
>>>
>>> code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
>>> unless I touch/prefault page before call to madvise().
>>>
>>> Is this expected behavior?
>>
>> Thank you for reporting.
>>
>> madvise(MADV_HWPOISON) triggers page fault when called on the address
>> over which no page is faulted-in, so I think that SIGBUS should be
>> called in such case.
>>
>> But it seems that memory error handler considers such a page as "reserved
>> kernel page" and recovery action fails (see below.)
>>
>>   [  383.371372] Injecting memory failure for page 0x1f10 at 0x7efcdc569000
>>   [  383.375678] Memory failure: 0x1f10: reserved kernel page still referenced by 1 users
>>   [  383.377570] Memory failure: 0x1f10: recovery action for reserved kernel page: Failed
>>
>> I'm not sure how/when this behavior was introduced, so I try to understand.
> 
> I found that this is a zero page, which is not recoverable for memory
> error now.
> 
>> IMO, the test code below looks valid to me, so no need to change.
> 
> I think that what the testcase effectively does is to test whether memory
> handling on zero pages works or not.
> And the testcase's failure seems acceptable, because it's simply not-implemented yet.
> Maybe recovering from error on zero page is possible (because there's no data
> loss for memory error,) but I'm not sure that code might be simple enough and/or
> it's worth doing ...
I question about it,  if a memory error happened on zero page, it will
cause all of data read from zero page is error, I mean no-zero, right?
And can we just use re-initial it with zero data maybe by memset ?

Thanks
Yisheng Xie.



^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: Is MADV_HWPOISON supposed to work only on faulted-in pages?
  2017-02-25  2:28       ` [LTP] " Yisheng Xie
@ 2017-02-27  1:20         ` Naoya Horiguchi
  -1 siblings, 0 replies; 26+ messages in thread
From: Naoya Horiguchi @ 2017-02-27  1:20 UTC (permalink / raw)
  To: Yisheng Xie; +Cc: Jan Stancek, linux-mm, ltp

On Sat, Feb 25, 2017 at 10:28:15AM +0800, Yisheng Xie wrote:
> hi Naoya,
> 
> On 2017/2/23 11:23, Naoya Horiguchi wrote:
> > On Mon, Feb 20, 2017 at 05:00:17AM +0000, Horiguchi Naoya(堀口 直也) wrote:
> >> On Tue, Feb 14, 2017 at 04:41:29PM +0100, Jan Stancek wrote:
> >>> Hi,
> >>>
> >>> code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
> >>> unless I touch/prefault page before call to madvise().
> >>>
> >>> Is this expected behavior?
> >>
> >> Thank you for reporting.
> >>
> >> madvise(MADV_HWPOISON) triggers page fault when called on the address
> >> over which no page is faulted-in, so I think that SIGBUS should be
> >> called in such case.
> >>
> >> But it seems that memory error handler considers such a page as "reserved
> >> kernel page" and recovery action fails (see below.)
> >>
> >>   [  383.371372] Injecting memory failure for page 0x1f10 at 0x7efcdc569000
> >>   [  383.375678] Memory failure: 0x1f10: reserved kernel page still referenced by 1 users
> >>   [  383.377570] Memory failure: 0x1f10: recovery action for reserved kernel page: Failed
> >>
> >> I'm not sure how/when this behavior was introduced, so I try to understand.
> > 
> > I found that this is a zero page, which is not recoverable for memory
> > error now.
> > 
> >> IMO, the test code below looks valid to me, so no need to change.
> > 
> > I think that what the testcase effectively does is to test whether memory
> > handling on zero pages works or not.
> > And the testcase's failure seems acceptable, because it's simply not-implemented yet.
> > Maybe recovering from error on zero page is possible (because there's no data
> > loss for memory error,) but I'm not sure that code might be simple enough and/or
> > it's worth doing ...
> I question about it,  if a memory error happened on zero page, it will
> cause all of data read from zero page is error, I mean no-zero, right?

Hi Yisheng,

Yes, the impact is serious (could affect many processes,) but it's possibility
is very low because there's only one page in a system that is used for zero page.
There are many other pages which are not recoverable for memory error like
slab pages, so I'm not sure how I prioritize it (maybe it's not a
top-priority thing, nor low-hanging fruit.)

> And can we just use re-initial it with zero data maybe by memset ?

Maybe it's not enoguh. Under a real hwpoison, we should isolate the error
page to prevent the access on the broken data.
But zero page is statically defined as an array of global variable, so
it's not trival to replace it with a new zero page at runtime.

Anyway, it's in my todo list, so hopefully revisited in the future.

Thanks,
Naoya Horiguchi
--
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>

^ permalink raw reply	[flat|nested] 26+ messages in thread
* [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
@ 2017-02-27  1:20         ` Naoya Horiguchi
  0 siblings, 0 replies; 26+ messages in thread
From: Naoya Horiguchi @ 2017-02-27  1:20 UTC (permalink / raw)
  To: ltp

On Sat, Feb 25, 2017 at 10:28:15AM +0800, Yisheng Xie wrote:
> hi Naoya,
> 
> On 2017/2/23 11:23, Naoya Horiguchi wrote:
> > On Mon, Feb 20, 2017 at 05:00:17AM +0000, Horiguchi Naoya(堀口 直也) wrote:
> >> On Tue, Feb 14, 2017 at 04:41:29PM +0100, Jan Stancek wrote:
> >>> Hi,
> >>>
> >>> code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
> >>> unless I touch/prefault page before call to madvise().
> >>>
> >>> Is this expected behavior?
> >>
> >> Thank you for reporting.
> >>
> >> madvise(MADV_HWPOISON) triggers page fault when called on the address
> >> over which no page is faulted-in, so I think that SIGBUS should be
> >> called in such case.
> >>
> >> But it seems that memory error handler considers such a page as "reserved
> >> kernel page" and recovery action fails (see below.)
> >>
> >>   [  383.371372] Injecting memory failure for page 0x1f10 at 0x7efcdc569000
> >>   [  383.375678] Memory failure: 0x1f10: reserved kernel page still referenced by 1 users
> >>   [  383.377570] Memory failure: 0x1f10: recovery action for reserved kernel page: Failed
> >>
> >> I'm not sure how/when this behavior was introduced, so I try to understand.
> > 
> > I found that this is a zero page, which is not recoverable for memory
> > error now.
> > 
> >> IMO, the test code below looks valid to me, so no need to change.
> > 
> > I think that what the testcase effectively does is to test whether memory
> > handling on zero pages works or not.
> > And the testcase's failure seems acceptable, because it's simply not-implemented yet.
> > Maybe recovering from error on zero page is possible (because there's no data
> > loss for memory error,) but I'm not sure that code might be simple enough and/or
> > it's worth doing ...
> I question about it,  if a memory error happened on zero page, it will
> cause all of data read from zero page is error, I mean no-zero, right?

Hi Yisheng,

Yes, the impact is serious (could affect many processes,) but it's possibility
is very low because there's only one page in a system that is used for zero page.
There are many other pages which are not recoverable for memory error like
slab pages, so I'm not sure how I prioritize it (maybe it's not a
top-priority thing, nor low-hanging fruit.)

> And can we just use re-initial it with zero data maybe by memset ?

Maybe it's not enoguh. Under a real hwpoison, we should isolate the error
page to prevent the access on the broken data.
But zero page is statically defined as an array of global variable, so
it's not trival to replace it with a new zero page at runtime.

Anyway, it's in my todo list, so hopefully revisited in the future.

Thanks,
Naoya Horiguchi

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: Is MADV_HWPOISON supposed to work only on faulted-in pages?
  2017-02-27  1:20         ` [LTP] " Naoya Horiguchi
@ 2017-02-27  4:27           ` Zi Yan
  -1 siblings, 0 replies; 26+ messages in thread
From: Zi Yan @ 2017-02-27  4:27 UTC (permalink / raw)
  To: Naoya Horiguchi; +Cc: Yisheng Xie, Jan Stancek, linux-mm, ltp

[-- Attachment #1: Type: text/plain, Size: 3539 bytes --]

On 26 Feb 2017, at 19:20, Naoya Horiguchi wrote:

> On Sat, Feb 25, 2017 at 10:28:15AM +0800, Yisheng Xie wrote:
>> hi Naoya,
>>
>> On 2017/2/23 11:23, Naoya Horiguchi wrote:
>>> On Mon, Feb 20, 2017 at 05:00:17AM +0000, Horiguchi Naoya(堀口 直也) wrote:
>>>> On Tue, Feb 14, 2017 at 04:41:29PM +0100, Jan Stancek wrote:
>>>>> Hi,
>>>>>
>>>>> code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
>>>>> unless I touch/prefault page before call to madvise().
>>>>>
>>>>> Is this expected behavior?
>>>>
>>>> Thank you for reporting.
>>>>
>>>> madvise(MADV_HWPOISON) triggers page fault when called on the address
>>>> over which no page is faulted-in, so I think that SIGBUS should be
>>>> called in such case.
>>>>
>>>> But it seems that memory error handler considers such a page as "reserved
>>>> kernel page" and recovery action fails (see below.)
>>>>
>>>>   [  383.371372] Injecting memory failure for page 0x1f10 at 0x7efcdc569000
>>>>   [  383.375678] Memory failure: 0x1f10: reserved kernel page still referenced by 1 users
>>>>   [  383.377570] Memory failure: 0x1f10: recovery action for reserved kernel page: Failed
>>>>
>>>> I'm not sure how/when this behavior was introduced, so I try to understand.
>>>
>>> I found that this is a zero page, which is not recoverable for memory
>>> error now.
>>>
>>>> IMO, the test code below looks valid to me, so no need to change.
>>>
>>> I think that what the testcase effectively does is to test whether memory
>>> handling on zero pages works or not.
>>> And the testcase's failure seems acceptable, because it's simply not-implemented yet.
>>> Maybe recovering from error on zero page is possible (because there's no data
>>> loss for memory error,) but I'm not sure that code might be simple enough and/or
>>> it's worth doing ...
>> I question about it,  if a memory error happened on zero page, it will
>> cause all of data read from zero page is error, I mean no-zero, right?
>
> Hi Yisheng,
>
> Yes, the impact is serious (could affect many processes,) but it's possibility
> is very low because there's only one page in a system that is used for zero page.
> There are many other pages which are not recoverable for memory error like
> slab pages, so I'm not sure how I prioritize it (maybe it's not a
> top-priority thing, nor low-hanging fruit.)
>
>> And can we just use re-initial it with zero data maybe by memset ?
>
> Maybe it's not enoguh. Under a real hwpoison, we should isolate the error
> page to prevent the access on the broken data.
> But zero page is statically defined as an array of global variable, so
> it's not trival to replace it with a new zero page at runtime.
>
> Anyway, it's in my todo list, so hopefully revisited in the future.
>

Hi Naoya,

The test case tries to HWPOISON a range of virtual addresses that do not
map to any physical pages.

I expected either madvise should fail because HWPOISON does not work on
non-existing physical pages or madvise_hwpoison() should populate
some physical pages for that virtual address range and poison them.

As I tested it on kernel v4.10, the test application exited at
madvise, because madvise returns -1 and error message is
"Device or resource busy". I think this is a proper behavior.

There might be some confusion in madvise's man page on MADV_HWPOISON.
If you add some text saying madvise fails if any page is not mapped in
the given address range, that can eliminate the confusion.


--
Best Regards
Yan Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread
* [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
@ 2017-02-27  4:27           ` Zi Yan
  0 siblings, 0 replies; 26+ messages in thread
From: Zi Yan @ 2017-02-27  4:27 UTC (permalink / raw)
  To: ltp

On 26 Feb 2017, at 19:20, Naoya Horiguchi wrote:

> On Sat, Feb 25, 2017 at 10:28:15AM +0800, Yisheng Xie wrote:
>> hi Naoya,
>>
>> On 2017/2/23 11:23, Naoya Horiguchi wrote:
>>> On Mon, Feb 20, 2017 at 05:00:17AM +0000, Horiguchi Naoya(堀口 直也) wrote:
>>>> On Tue, Feb 14, 2017 at 04:41:29PM +0100, Jan Stancek wrote:
>>>>> Hi,
>>>>>
>>>>> code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
>>>>> unless I touch/prefault page before call to madvise().
>>>>>
>>>>> Is this expected behavior?
>>>>
>>>> Thank you for reporting.
>>>>
>>>> madvise(MADV_HWPOISON) triggers page fault when called on the address
>>>> over which no page is faulted-in, so I think that SIGBUS should be
>>>> called in such case.
>>>>
>>>> But it seems that memory error handler considers such a page as "reserved
>>>> kernel page" and recovery action fails (see below.)
>>>>
>>>>   [  383.371372] Injecting memory failure for page 0x1f10 at 0x7efcdc569000
>>>>   [  383.375678] Memory failure: 0x1f10: reserved kernel page still referenced by 1 users
>>>>   [  383.377570] Memory failure: 0x1f10: recovery action for reserved kernel page: Failed
>>>>
>>>> I'm not sure how/when this behavior was introduced, so I try to understand.
>>>
>>> I found that this is a zero page, which is not recoverable for memory
>>> error now.
>>>
>>>> IMO, the test code below looks valid to me, so no need to change.
>>>
>>> I think that what the testcase effectively does is to test whether memory
>>> handling on zero pages works or not.
>>> And the testcase's failure seems acceptable, because it's simply not-implemented yet.
>>> Maybe recovering from error on zero page is possible (because there's no data
>>> loss for memory error,) but I'm not sure that code might be simple enough and/or
>>> it's worth doing ...
>> I question about it,  if a memory error happened on zero page, it will
>> cause all of data read from zero page is error, I mean no-zero, right?
>
> Hi Yisheng,
>
> Yes, the impact is serious (could affect many processes,) but it's possibility
> is very low because there's only one page in a system that is used for zero page.
> There are many other pages which are not recoverable for memory error like
> slab pages, so I'm not sure how I prioritize it (maybe it's not a
> top-priority thing, nor low-hanging fruit.)
>
>> And can we just use re-initial it with zero data maybe by memset ?
>
> Maybe it's not enoguh. Under a real hwpoison, we should isolate the error
> page to prevent the access on the broken data.
> But zero page is statically defined as an array of global variable, so
> it's not trival to replace it with a new zero page at runtime.
>
> Anyway, it's in my todo list, so hopefully revisited in the future.
>

Hi Naoya,

The test case tries to HWPOISON a range of virtual addresses that do not
map to any physical pages.

I expected either madvise should fail because HWPOISON does not work on
non-existing physical pages or madvise_hwpoison() should populate
some physical pages for that virtual address range and poison them.

As I tested it on kernel v4.10, the test application exited at
madvise, because madvise returns -1 and error message is
"Device or resource busy". I think this is a proper behavior.

There might be some confusion in madvise's man page on MADV_HWPOISON.
If you add some text saying madvise fails if any page is not mapped in
the given address range, that can eliminate the confusion.


--
Best Regards
Yan Zi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linux.it/pipermail/ltp/attachments/20170226/d4157dde/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: Is MADV_HWPOISON supposed to work only on faulted-in pages?
  2017-02-27  4:27           ` [LTP] " Zi Yan
@ 2017-02-27  6:33             ` Naoya Horiguchi
  -1 siblings, 0 replies; 26+ messages in thread
From: Naoya Horiguchi @ 2017-02-27  6:33 UTC (permalink / raw)
  To: Zi Yan; +Cc: Yisheng Xie, Jan Stancek, linux-mm, ltp

On Sun, Feb 26, 2017 at 10:27:02PM -0600, Zi Yan wrote:
> On 26 Feb 2017, at 19:20, Naoya Horiguchi wrote:
> 
> > On Sat, Feb 25, 2017 at 10:28:15AM +0800, Yisheng Xie wrote:
> >> hi Naoya,
> >>
> >> On 2017/2/23 11:23, Naoya Horiguchi wrote:
> >>> On Mon, Feb 20, 2017 at 05:00:17AM +0000, Horiguchi Naoya(堀口 直也) wrote:
> >>>> On Tue, Feb 14, 2017 at 04:41:29PM +0100, Jan Stancek wrote:
> >>>>> Hi,
> >>>>>
> >>>>> code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
> >>>>> unless I touch/prefault page before call to madvise().
> >>>>>
> >>>>> Is this expected behavior?
> >>>>
> >>>> Thank you for reporting.
> >>>>
> >>>> madvise(MADV_HWPOISON) triggers page fault when called on the address
> >>>> over which no page is faulted-in, so I think that SIGBUS should be
> >>>> called in such case.
> >>>>
> >>>> But it seems that memory error handler considers such a page as "reserved
> >>>> kernel page" and recovery action fails (see below.)
> >>>>
> >>>>   [  383.371372] Injecting memory failure for page 0x1f10 at 0x7efcdc569000
> >>>>   [  383.375678] Memory failure: 0x1f10: reserved kernel page still referenced by 1 users
> >>>>   [  383.377570] Memory failure: 0x1f10: recovery action for reserved kernel page: Failed
> >>>>
> >>>> I'm not sure how/when this behavior was introduced, so I try to understand.
> >>>
> >>> I found that this is a zero page, which is not recoverable for memory
> >>> error now.
> >>>
> >>>> IMO, the test code below looks valid to me, so no need to change.
> >>>
> >>> I think that what the testcase effectively does is to test whether memory
> >>> handling on zero pages works or not.
> >>> And the testcase's failure seems acceptable, because it's simply not-implemented yet.
> >>> Maybe recovering from error on zero page is possible (because there's no data
> >>> loss for memory error,) but I'm not sure that code might be simple enough and/or
> >>> it's worth doing ...
> >> I question about it,  if a memory error happened on zero page, it will
> >> cause all of data read from zero page is error, I mean no-zero, right?
> >
> > Hi Yisheng,
> >
> > Yes, the impact is serious (could affect many processes,) but it's possibility
> > is very low because there's only one page in a system that is used for zero page.
> > There are many other pages which are not recoverable for memory error like
> > slab pages, so I'm not sure how I prioritize it (maybe it's not a
> > top-priority thing, nor low-hanging fruit.)
> >
> >> And can we just use re-initial it with zero data maybe by memset ?
> >
> > Maybe it's not enoguh. Under a real hwpoison, we should isolate the error
> > page to prevent the access on the broken data.
> > But zero page is statically defined as an array of global variable, so
> > it's not trival to replace it with a new zero page at runtime.
> >
> > Anyway, it's in my todo list, so hopefully revisited in the future.
> >
> 
> Hi Naoya,
> 
> The test case tries to HWPOISON a range of virtual addresses that do not
> map to any physical pages.
> 

Hi Yan,

> I expected either madvise should fail because HWPOISON does not work on
> non-existing physical pages or madvise_hwpoison() should populate
> some physical pages for that virtual address range and poison them.

The latter is the current behavior. It just comes from get_user_pages_fast()
which not only finds the page and takes refcount, but also touch the page.

madvise(MADV_HWPOISON) is a test feature, and calling it for address backed
by no page doesn't simulate anything real. IOW, the behavior is undefined.
So I don't have a strong opinion about how it should behave.

> 
> As I tested it on kernel v4.10, the test application exited at
> madvise, because madvise returns -1 and error message is
> "Device or resource busy". I think this is a proper behavior.

yes, maybe we see the same thing, you can see in dmesg "recovery action
for reserved kernel page: Failed" message.

> 
> There might be some confusion in madvise's man page on MADV_HWPOISON.
> If you add some text saying madvise fails if any page is not mapped in
> the given address range, that can eliminate the confusion*

Writing it down to man page makes readers think this behavior is a part of
specification, that might not be good now because the failure in error
handling of zero page is not the eventually fixed behavior.
I mean that if zero page handles hwpoison properly in the future, madvise
will succeed without any confusion.
So I feel that we don't have to update man page for this issue.

Thanks,
Naoya Horiguchi
--
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>

^ permalink raw reply	[flat|nested] 26+ messages in thread
* [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
@ 2017-02-27  6:33             ` Naoya Horiguchi
  0 siblings, 0 replies; 26+ messages in thread
From: Naoya Horiguchi @ 2017-02-27  6:33 UTC (permalink / raw)
  To: ltp

On Sun, Feb 26, 2017 at 10:27:02PM -0600, Zi Yan wrote:
> On 26 Feb 2017, at 19:20, Naoya Horiguchi wrote:
> 
> > On Sat, Feb 25, 2017 at 10:28:15AM +0800, Yisheng Xie wrote:
> >> hi Naoya,
> >>
> >> On 2017/2/23 11:23, Naoya Horiguchi wrote:
> >>> On Mon, Feb 20, 2017 at 05:00:17AM +0000, Horiguchi Naoya(堀口 直也) wrote:
> >>>> On Tue, Feb 14, 2017 at 04:41:29PM +0100, Jan Stancek wrote:
> >>>>> Hi,
> >>>>>
> >>>>> code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
> >>>>> unless I touch/prefault page before call to madvise().
> >>>>>
> >>>>> Is this expected behavior?
> >>>>
> >>>> Thank you for reporting.
> >>>>
> >>>> madvise(MADV_HWPOISON) triggers page fault when called on the address
> >>>> over which no page is faulted-in, so I think that SIGBUS should be
> >>>> called in such case.
> >>>>
> >>>> But it seems that memory error handler considers such a page as "reserved
> >>>> kernel page" and recovery action fails (see below.)
> >>>>
> >>>>   [  383.371372] Injecting memory failure for page 0x1f10 at 0x7efcdc569000
> >>>>   [  383.375678] Memory failure: 0x1f10: reserved kernel page still referenced by 1 users
> >>>>   [  383.377570] Memory failure: 0x1f10: recovery action for reserved kernel page: Failed
> >>>>
> >>>> I'm not sure how/when this behavior was introduced, so I try to understand.
> >>>
> >>> I found that this is a zero page, which is not recoverable for memory
> >>> error now.
> >>>
> >>>> IMO, the test code below looks valid to me, so no need to change.
> >>>
> >>> I think that what the testcase effectively does is to test whether memory
> >>> handling on zero pages works or not.
> >>> And the testcase's failure seems acceptable, because it's simply not-implemented yet.
> >>> Maybe recovering from error on zero page is possible (because there's no data
> >>> loss for memory error,) but I'm not sure that code might be simple enough and/or
> >>> it's worth doing ...
> >> I question about it,  if a memory error happened on zero page, it will
> >> cause all of data read from zero page is error, I mean no-zero, right?
> >
> > Hi Yisheng,
> >
> > Yes, the impact is serious (could affect many processes,) but it's possibility
> > is very low because there's only one page in a system that is used for zero page.
> > There are many other pages which are not recoverable for memory error like
> > slab pages, so I'm not sure how I prioritize it (maybe it's not a
> > top-priority thing, nor low-hanging fruit.)
> >
> >> And can we just use re-initial it with zero data maybe by memset ?
> >
> > Maybe it's not enoguh. Under a real hwpoison, we should isolate the error
> > page to prevent the access on the broken data.
> > But zero page is statically defined as an array of global variable, so
> > it's not trival to replace it with a new zero page at runtime.
> >
> > Anyway, it's in my todo list, so hopefully revisited in the future.
> >
> 
> Hi Naoya,
> 
> The test case tries to HWPOISON a range of virtual addresses that do not
> map to any physical pages.
> 

Hi Yan,

> I expected either madvise should fail because HWPOISON does not work on
> non-existing physical pages or madvise_hwpoison() should populate
> some physical pages for that virtual address range and poison them.

The latter is the current behavior. It just comes from get_user_pages_fast()
which not only finds the page and takes refcount, but also touch the page.

madvise(MADV_HWPOISON) is a test feature, and calling it for address backed
by no page doesn't simulate anything real. IOW, the behavior is undefined.
So I don't have a strong opinion about how it should behave.

> 
> As I tested it on kernel v4.10, the test application exited at
> madvise, because madvise returns -1 and error message is
> "Device or resource busy". I think this is a proper behavior.

yes, maybe we see the same thing, you can see in dmesg "recovery action
for reserved kernel page: Failed" message.

> 
> There might be some confusion in madvise's man page on MADV_HWPOISON.
> If you add some text saying madvise fails if any page is not mapped in
> the given address range, that can eliminate the confusion*

Writing it down to man page makes readers think this behavior is a part of
specification, that might not be good now because the failure in error
handling of zero page is not the eventually fixed behavior.
I mean that if zero page handles hwpoison properly in the future, madvise
will succeed without any confusion.
So I feel that we don't have to update man page for this issue.

Thanks,
Naoya Horiguchi

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: Is MADV_HWPOISON supposed to work only on faulted-in pages?
  2017-02-27  6:33             ` [LTP] " Naoya Horiguchi
@ 2017-02-27 16:10               ` Zi Yan
  -1 siblings, 0 replies; 26+ messages in thread
From: Zi Yan @ 2017-02-27 16:10 UTC (permalink / raw)
  To: Naoya Horiguchi; +Cc: Yisheng Xie, Jan Stancek, linux-mm, ltp

[-- Attachment #1: Type: text/plain, Size: 4902 bytes --]

On 27 Feb 2017, at 0:33, Naoya Horiguchi wrote:

> On Sun, Feb 26, 2017 at 10:27:02PM -0600, Zi Yan wrote:
>> On 26 Feb 2017, at 19:20, Naoya Horiguchi wrote:
>>
>>> On Sat, Feb 25, 2017 at 10:28:15AM +0800, Yisheng Xie wrote:
>>>> hi Naoya,
>>>>
>>>> On 2017/2/23 11:23, Naoya Horiguchi wrote:
>>>>> On Mon, Feb 20, 2017 at 05:00:17AM +0000, Horiguchi Naoya(堀口 直也) wrote:
>>>>>> On Tue, Feb 14, 2017 at 04:41:29PM +0100, Jan Stancek wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
>>>>>>> unless I touch/prefault page before call to madvise().
>>>>>>>
>>>>>>> Is this expected behavior?
>>>>>>
>>>>>> Thank you for reporting.
>>>>>>
>>>>>> madvise(MADV_HWPOISON) triggers page fault when called on the address
>>>>>> over which no page is faulted-in, so I think that SIGBUS should be
>>>>>> called in such case.
>>>>>>
>>>>>> But it seems that memory error handler considers such a page as "reserved
>>>>>> kernel page" and recovery action fails (see below.)
>>>>>>
>>>>>>   [  383.371372] Injecting memory failure for page 0x1f10 at 0x7efcdc569000
>>>>>>   [  383.375678] Memory failure: 0x1f10: reserved kernel page still referenced by 1 users
>>>>>>   [  383.377570] Memory failure: 0x1f10: recovery action for reserved kernel page: Failed
>>>>>>
>>>>>> I'm not sure how/when this behavior was introduced, so I try to understand.
>>>>>
>>>>> I found that this is a zero page, which is not recoverable for memory
>>>>> error now.
>>>>>
>>>>>> IMO, the test code below looks valid to me, so no need to change.
>>>>>
>>>>> I think that what the testcase effectively does is to test whether memory
>>>>> handling on zero pages works or not.
>>>>> And the testcase's failure seems acceptable, because it's simply not-implemented yet.
>>>>> Maybe recovering from error on zero page is possible (because there's no data
>>>>> loss for memory error,) but I'm not sure that code might be simple enough and/or
>>>>> it's worth doing ...
>>>> I question about it,  if a memory error happened on zero page, it will
>>>> cause all of data read from zero page is error, I mean no-zero, right?
>>>
>>> Hi Yisheng,
>>>
>>> Yes, the impact is serious (could affect many processes,) but it's possibility
>>> is very low because there's only one page in a system that is used for zero page.
>>> There are many other pages which are not recoverable for memory error like
>>> slab pages, so I'm not sure how I prioritize it (maybe it's not a
>>> top-priority thing, nor low-hanging fruit.)
>>>
>>>> And can we just use re-initial it with zero data maybe by memset ?
>>>
>>> Maybe it's not enoguh. Under a real hwpoison, we should isolate the error
>>> page to prevent the access on the broken data.
>>> But zero page is statically defined as an array of global variable, so
>>> it's not trival to replace it with a new zero page at runtime.
>>>
>>> Anyway, it's in my todo list, so hopefully revisited in the future.
>>>
>>
>> Hi Naoya,
>>
>> The test case tries to HWPOISON a range of virtual addresses that do not
>> map to any physical pages.
>>
>
> Hi Yan,
>
>> I expected either madvise should fail because HWPOISON does not work on
>> non-existing physical pages or madvise_hwpoison() should populate
>> some physical pages for that virtual address range and poison them.
>
> The latter is the current behavior. It just comes from get_user_pages_fast()
> which not only finds the page and takes refcount, but also touch the page.
>
> madvise(MADV_HWPOISON) is a test feature, and calling it for address backed
> by no page doesn't simulate anything real. IOW, the behavior is undefined.
> So I don't have a strong opinion about how it should behave.
>
>>
>> As I tested it on kernel v4.10, the test application exited at
>> madvise, because madvise returns -1 and error message is
>> "Device or resource busy". I think this is a proper behavior.
>
> yes, maybe we see the same thing, you can see in dmesg "recovery action
> for reserved kernel page: Failed" message.
>
>>
>> There might be some confusion in madvise's man page on MADV_HWPOISON.
>> If you add some text saying madvise fails if any page is not mapped in
>> the given address range, that can eliminate the confusion*
>
> Writing it down to man page makes readers think this behavior is a part of
> specification, that might not be good now because the failure in error
> handling of zero page is not the eventually fixed behavior.
> I mean that if zero page handles hwpoison properly in the future, madvise
> will succeed without any confusion.
> So I feel that we don't have to update man page for this issue.

You are right, I missed the part that get_user_pages_fast() will actually fault
in the madvised pages with zero_page.

Thanks for clarifying this.

--
Best Regards
Yan Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

^ permalink raw reply	[flat|nested] 26+ messages in thread
* [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
@ 2017-02-27 16:10               ` Zi Yan
  0 siblings, 0 replies; 26+ messages in thread
From: Zi Yan @ 2017-02-27 16:10 UTC (permalink / raw)
  To: ltp

On 27 Feb 2017, at 0:33, Naoya Horiguchi wrote:

> On Sun, Feb 26, 2017 at 10:27:02PM -0600, Zi Yan wrote:
>> On 26 Feb 2017, at 19:20, Naoya Horiguchi wrote:
>>
>>> On Sat, Feb 25, 2017 at 10:28:15AM +0800, Yisheng Xie wrote:
>>>> hi Naoya,
>>>>
>>>> On 2017/2/23 11:23, Naoya Horiguchi wrote:
>>>>> On Mon, Feb 20, 2017 at 05:00:17AM +0000, Horiguchi Naoya(堀口 直也) wrote:
>>>>>> On Tue, Feb 14, 2017 at 04:41:29PM +0100, Jan Stancek wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
>>>>>>> unless I touch/prefault page before call to madvise().
>>>>>>>
>>>>>>> Is this expected behavior?
>>>>>>
>>>>>> Thank you for reporting.
>>>>>>
>>>>>> madvise(MADV_HWPOISON) triggers page fault when called on the address
>>>>>> over which no page is faulted-in, so I think that SIGBUS should be
>>>>>> called in such case.
>>>>>>
>>>>>> But it seems that memory error handler considers such a page as "reserved
>>>>>> kernel page" and recovery action fails (see below.)
>>>>>>
>>>>>>   [  383.371372] Injecting memory failure for page 0x1f10 at 0x7efcdc569000
>>>>>>   [  383.375678] Memory failure: 0x1f10: reserved kernel page still referenced by 1 users
>>>>>>   [  383.377570] Memory failure: 0x1f10: recovery action for reserved kernel page: Failed
>>>>>>
>>>>>> I'm not sure how/when this behavior was introduced, so I try to understand.
>>>>>
>>>>> I found that this is a zero page, which is not recoverable for memory
>>>>> error now.
>>>>>
>>>>>> IMO, the test code below looks valid to me, so no need to change.
>>>>>
>>>>> I think that what the testcase effectively does is to test whether memory
>>>>> handling on zero pages works or not.
>>>>> And the testcase's failure seems acceptable, because it's simply not-implemented yet.
>>>>> Maybe recovering from error on zero page is possible (because there's no data
>>>>> loss for memory error,) but I'm not sure that code might be simple enough and/or
>>>>> it's worth doing ...
>>>> I question about it,  if a memory error happened on zero page, it will
>>>> cause all of data read from zero page is error, I mean no-zero, right?
>>>
>>> Hi Yisheng,
>>>
>>> Yes, the impact is serious (could affect many processes,) but it's possibility
>>> is very low because there's only one page in a system that is used for zero page.
>>> There are many other pages which are not recoverable for memory error like
>>> slab pages, so I'm not sure how I prioritize it (maybe it's not a
>>> top-priority thing, nor low-hanging fruit.)
>>>
>>>> And can we just use re-initial it with zero data maybe by memset ?
>>>
>>> Maybe it's not enoguh. Under a real hwpoison, we should isolate the error
>>> page to prevent the access on the broken data.
>>> But zero page is statically defined as an array of global variable, so
>>> it's not trival to replace it with a new zero page at runtime.
>>>
>>> Anyway, it's in my todo list, so hopefully revisited in the future.
>>>
>>
>> Hi Naoya,
>>
>> The test case tries to HWPOISON a range of virtual addresses that do not
>> map to any physical pages.
>>
>
> Hi Yan,
>
>> I expected either madvise should fail because HWPOISON does not work on
>> non-existing physical pages or madvise_hwpoison() should populate
>> some physical pages for that virtual address range and poison them.
>
> The latter is the current behavior. It just comes from get_user_pages_fast()
> which not only finds the page and takes refcount, but also touch the page.
>
> madvise(MADV_HWPOISON) is a test feature, and calling it for address backed
> by no page doesn't simulate anything real. IOW, the behavior is undefined.
> So I don't have a strong opinion about how it should behave.
>
>>
>> As I tested it on kernel v4.10, the test application exited at
>> madvise, because madvise returns -1 and error message is
>> "Device or resource busy". I think this is a proper behavior.
>
> yes, maybe we see the same thing, you can see in dmesg "recovery action
> for reserved kernel page: Failed" message.
>
>>
>> There might be some confusion in madvise's man page on MADV_HWPOISON.
>> If you add some text saying madvise fails if any page is not mapped in
>> the given address range, that can eliminate the confusion*
>
> Writing it down to man page makes readers think this behavior is a part of
> specification, that might not be good now because the failure in error
> handling of zero page is not the eventually fixed behavior.
> I mean that if zero page handles hwpoison properly in the future, madvise
> will succeed without any confusion.
> So I feel that we don't have to update man page for this issue.

You are right, I missed the part that get_user_pages_fast() will actually fault
in the madvised pages with zero_page.

Thanks for clarifying this.

--
Best Regards
Yan Zi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linux.it/pipermail/ltp/attachments/20170227/e82273e9/attachment.sig>

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
  2017-02-27  6:33             ` [LTP] " Naoya Horiguchi
@ 2017-03-14 13:20               ` Cyril Hrubis
  -1 siblings, 0 replies; 26+ messages in thread
From: Cyril Hrubis @ 2017-03-14 13:20 UTC (permalink / raw)
  To: Naoya Horiguchi
  Cc: Zi Yan, Yisheng Xie, linux-mm, ltp, linux-man, mtk.manpages

Hi!
> > >>>>> code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
> > >>>>> unless I touch/prefault page before call to madvise().
> > >>>>>
> > >>>>> Is this expected behavior?
> > >>>>
> > >>>> Thank you for reporting.
> > >>>>
> > >>>> madvise(MADV_HWPOISON) triggers page fault when called on the address
> > >>>> over which no page is faulted-in, so I think that SIGBUS should be
> > >>>> called in such case.
> > >>>>
> > >>>> But it seems that memory error handler considers such a page as "reserved
> > >>>> kernel page" and recovery action fails (see below.)
> > >>>>
> > >>>>   [  383.371372] Injecting memory failure for page 0x1f10 at 0x7efcdc569000
> > >>>>   [  383.375678] Memory failure: 0x1f10: reserved kernel page still referenced by 1 users
> > >>>>   [  383.377570] Memory failure: 0x1f10: recovery action for reserved kernel page: Failed
> > >>>>
> > >>>> I'm not sure how/when this behavior was introduced, so I try to understand.
> > >>>
> > >>> I found that this is a zero page, which is not recoverable for memory
> > >>> error now.
> > >>>
> > >>>> IMO, the test code below looks valid to me, so no need to change.
> > >>>
> > >>> I think that what the testcase effectively does is to test whether memory
> > >>> handling on zero pages works or not.
> > >>> And the testcase's failure seems acceptable, because it's simply not-implemented yet.
> > >>> Maybe recovering from error on zero page is possible (because there's no data
> > >>> loss for memory error,) but I'm not sure that code might be simple enough and/or
> > >>> it's worth doing ...
> > >> I question about it,  if a memory error happened on zero page, it will
> > >> cause all of data read from zero page is error, I mean no-zero, right?
> > >
> > > Hi Yisheng,
> > >
> > > Yes, the impact is serious (could affect many processes,) but it's possibility
> > > is very low because there's only one page in a system that is used for zero page.
> > > There are many other pages which are not recoverable for memory error like
> > > slab pages, so I'm not sure how I prioritize it (maybe it's not a
> > > top-priority thing, nor low-hanging fruit.)
> > >
> > >> And can we just use re-initial it with zero data maybe by memset ?
> > >
> > > Maybe it's not enoguh. Under a real hwpoison, we should isolate the error
> > > page to prevent the access on the broken data.
> > > But zero page is statically defined as an array of global variable, so
> > > it's not trival to replace it with a new zero page at runtime.
> > >
> > > Anyway, it's in my todo list, so hopefully revisited in the future.
> > >
> > 
> > Hi Naoya,
> > 
> > The test case tries to HWPOISON a range of virtual addresses that do not
> > map to any physical pages.
> > 
> 
> Hi Yan,
> 
> > I expected either madvise should fail because HWPOISON does not work on
> > non-existing physical pages or madvise_hwpoison() should populate
> > some physical pages for that virtual address range and poison them.
> 
> The latter is the current behavior. It just comes from get_user_pages_fast()
> which not only finds the page and takes refcount, but also touch the page.
> 
> madvise(MADV_HWPOISON) is a test feature, and calling it for address backed
> by no page doesn't simulate anything real. IOW, the behavior is undefined.
> So I don't have a strong opinion about how it should behave.
> 
> > 
> > As I tested it on kernel v4.10, the test application exited at
> > madvise, because madvise returns -1 and error message is
> > "Device or resource busy". I think this is a proper behavior.
> 
> yes, maybe we see the same thing, you can see in dmesg "recovery action
> for reserved kernel page: Failed" message.
> 
> > 
> > There might be some confusion in madvise's man page on MADV_HWPOISON.
> > If you add some text saying madvise fails if any page is not mapped in
> > the given address range, that can eliminate the confusion*
> 
> Writing it down to man page makes readers think this behavior is a part of
> specification, that might not be good now because the failure in error
> handling of zero page is not the eventually fixed behavior.
> I mean that if zero page handles hwpoison properly in the future, madvise
> will succeed without any confusion.
> So I feel that we don't have to update man page for this issue.

I still think that this is a worth of documenting in the manual page,
since the call failed silently before 4.10 right? I guess that we may as
well add a BUGS section and document at least that.

-- 
Cyril Hrubis
chrubis@suse.cz

--
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>

^ permalink raw reply	[flat|nested] 26+ messages in thread
* [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
@ 2017-03-14 13:20               ` Cyril Hrubis
  0 siblings, 0 replies; 26+ messages in thread
From: Cyril Hrubis @ 2017-03-14 13:20 UTC (permalink / raw)
  To: ltp

Hi!
> > >>>>> code below (and LTP madvise07 [1]) doesn't produce SIGBUS,
> > >>>>> unless I touch/prefault page before call to madvise().
> > >>>>>
> > >>>>> Is this expected behavior?
> > >>>>
> > >>>> Thank you for reporting.
> > >>>>
> > >>>> madvise(MADV_HWPOISON) triggers page fault when called on the address
> > >>>> over which no page is faulted-in, so I think that SIGBUS should be
> > >>>> called in such case.
> > >>>>
> > >>>> But it seems that memory error handler considers such a page as "reserved
> > >>>> kernel page" and recovery action fails (see below.)
> > >>>>
> > >>>>   [  383.371372] Injecting memory failure for page 0x1f10 at 0x7efcdc569000
> > >>>>   [  383.375678] Memory failure: 0x1f10: reserved kernel page still referenced by 1 users
> > >>>>   [  383.377570] Memory failure: 0x1f10: recovery action for reserved kernel page: Failed
> > >>>>
> > >>>> I'm not sure how/when this behavior was introduced, so I try to understand.
> > >>>
> > >>> I found that this is a zero page, which is not recoverable for memory
> > >>> error now.
> > >>>
> > >>>> IMO, the test code below looks valid to me, so no need to change.
> > >>>
> > >>> I think that what the testcase effectively does is to test whether memory
> > >>> handling on zero pages works or not.
> > >>> And the testcase's failure seems acceptable, because it's simply not-implemented yet.
> > >>> Maybe recovering from error on zero page is possible (because there's no data
> > >>> loss for memory error,) but I'm not sure that code might be simple enough and/or
> > >>> it's worth doing ...
> > >> I question about it,  if a memory error happened on zero page, it will
> > >> cause all of data read from zero page is error, I mean no-zero, right?
> > >
> > > Hi Yisheng,
> > >
> > > Yes, the impact is serious (could affect many processes,) but it's possibility
> > > is very low because there's only one page in a system that is used for zero page.
> > > There are many other pages which are not recoverable for memory error like
> > > slab pages, so I'm not sure how I prioritize it (maybe it's not a
> > > top-priority thing, nor low-hanging fruit.)
> > >
> > >> And can we just use re-initial it with zero data maybe by memset ?
> > >
> > > Maybe it's not enoguh. Under a real hwpoison, we should isolate the error
> > > page to prevent the access on the broken data.
> > > But zero page is statically defined as an array of global variable, so
> > > it's not trival to replace it with a new zero page at runtime.
> > >
> > > Anyway, it's in my todo list, so hopefully revisited in the future.
> > >
> > 
> > Hi Naoya,
> > 
> > The test case tries to HWPOISON a range of virtual addresses that do not
> > map to any physical pages.
> > 
> 
> Hi Yan,
> 
> > I expected either madvise should fail because HWPOISON does not work on
> > non-existing physical pages or madvise_hwpoison() should populate
> > some physical pages for that virtual address range and poison them.
> 
> The latter is the current behavior. It just comes from get_user_pages_fast()
> which not only finds the page and takes refcount, but also touch the page.
> 
> madvise(MADV_HWPOISON) is a test feature, and calling it for address backed
> by no page doesn't simulate anything real. IOW, the behavior is undefined.
> So I don't have a strong opinion about how it should behave.
> 
> > 
> > As I tested it on kernel v4.10, the test application exited at
> > madvise, because madvise returns -1 and error message is
> > "Device or resource busy". I think this is a proper behavior.
> 
> yes, maybe we see the same thing, you can see in dmesg "recovery action
> for reserved kernel page: Failed" message.
> 
> > 
> > There might be some confusion in madvise's man page on MADV_HWPOISON.
> > If you add some text saying madvise fails if any page is not mapped in
> > the given address range, that can eliminate the confusion*
> 
> Writing it down to man page makes readers think this behavior is a part of
> specification, that might not be good now because the failure in error
> handling of zero page is not the eventually fixed behavior.
> I mean that if zero page handles hwpoison properly in the future, madvise
> will succeed without any confusion.
> So I feel that we don't have to update man page for this issue.

I still think that this is a worth of documenting in the manual page,
since the call failed silently before 4.10 right? I guess that we may as
well add a BUGS section and document at least that.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
  2017-02-27  6:33             ` [LTP] " Naoya Horiguchi
@ 2017-03-27 12:08               ` Richard Palethorpe
  -1 siblings, 0 replies; 26+ messages in thread
From: Richard Palethorpe @ 2017-03-27 12:08 UTC (permalink / raw)
  To: Naoya Horiguchi; +Cc: Zi Yan, Yisheng Xie, linux-mm, ltp

Hi Naoya,

On Mon, 27 Feb 2017 06:33:09 +0000
"Naoya Horiguchi" <n-horiguchi@ah.jp.nec.com> wrote:

> 
> > I expected either madvise should fail because HWPOISON does not work on
> > non-existing physical pages or madvise_hwpoison() should populate
> > some physical pages for that virtual address range and poison them.  
> 
> The latter is the current behavior. It just comes from get_user_pages_fast()
> which not only finds the page and takes refcount, but also touch the page.

To clarify, the current behaviour seems to be the following:

1st madvise_hwpoison() -> EBUSY,
2nd madvise_hwpoison() -> SUCCESS, but no SIGBUS when the memory is accessed.

So it touches the zero page and madvise succeeds on the second attempt because
it is now mapped, but still the memory is not poisoned.

This means that when I modify the LTP test to accept EBUSY, it still fails if
a user runs it twice. This is OK, but I will need to document it in the test.

Thank you,
Richard.

--
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>

^ permalink raw reply	[flat|nested] 26+ messages in thread
* [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
@ 2017-03-27 12:08               ` Richard Palethorpe
  0 siblings, 0 replies; 26+ messages in thread
From: Richard Palethorpe @ 2017-03-27 12:08 UTC (permalink / raw)
  To: ltp

Hi Naoya,

On Mon, 27 Feb 2017 06:33:09 +0000
"Naoya Horiguchi" <n-horiguchi@ah.jp.nec.com> wrote:

> 
> > I expected either madvise should fail because HWPOISON does not work on
> > non-existing physical pages or madvise_hwpoison() should populate
> > some physical pages for that virtual address range and poison them.  
> 
> The latter is the current behavior. It just comes from get_user_pages_fast()
> which not only finds the page and takes refcount, but also touch the page.

To clarify, the current behaviour seems to be the following:

1st madvise_hwpoison() -> EBUSY,
2nd madvise_hwpoison() -> SUCCESS, but no SIGBUS when the memory is accessed.

So it touches the zero page and madvise succeeds on the second attempt because
it is now mapped, but still the memory is not poisoned.

This means that when I modify the LTP test to accept EBUSY, it still fails if
a user runs it twice. This is OK, but I will need to document it in the test.

Thank you,
Richard.

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: Is MADV_HWPOISON supposed to work only on faulted-in pages?
  2017-02-23  3:23     ` [LTP] " Naoya Horiguchi
@ 2017-03-27 23:54       ` Andi Kleen
  -1 siblings, 0 replies; 26+ messages in thread
From: Andi Kleen @ 2017-03-27 23:54 UTC (permalink / raw)
  To: Naoya Horiguchi; +Cc: Jan Stancek, linux-mm, ltp

Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> writes:
>
> I think that what the testcase effectively does is to test whether memory
> handling on zero pages works or not.
> And the testcase's failure seems acceptable, because it's simply not-implemented yet.
> Maybe recovering from error on zero page is possible (because there's no data
> loss for memory error,) but I'm not sure that code might be simple enough and/or
> it's worth doing ...

I doubt it's worth doing, it's just too unlikely that a specific page
is hit. Memory error handling is all about probabilities.

The test is just broken and should be fixed.

mce-test had similar problems at some point, but they were all fixed.

-Andi

--
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>

^ permalink raw reply	[flat|nested] 26+ messages in thread
* [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
@ 2017-03-27 23:54       ` Andi Kleen
  0 siblings, 0 replies; 26+ messages in thread
From: Andi Kleen @ 2017-03-27 23:54 UTC (permalink / raw)
  To: ltp

Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> writes:
>
> I think that what the testcase effectively does is to test whether memory
> handling on zero pages works or not.
> And the testcase's failure seems acceptable, because it's simply not-implemented yet.
> Maybe recovering from error on zero page is possible (because there's no data
> loss for memory error,) but I'm not sure that code might be simple enough and/or
> it's worth doing ...

I doubt it's worth doing, it's just too unlikely that a specific page
is hit. Memory error handling is all about probabilities.

The test is just broken and should be fixed.

mce-test had similar problems at some point, but they were all fixed.

-Andi

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
  2017-03-27 23:54       ` [LTP] " Andi Kleen
@ 2017-03-28  8:25         ` Cyril Hrubis
  -1 siblings, 0 replies; 26+ messages in thread
From: Cyril Hrubis @ 2017-03-28  8:25 UTC (permalink / raw)
  To: Andi Kleen; +Cc: Naoya Horiguchi, linux-mm, ltp

Hi!
> > I think that what the testcase effectively does is to test whether memory
> > handling on zero pages works or not.
> > And the testcase's failure seems acceptable, because it's simply not-implemented yet.
> > Maybe recovering from error on zero page is possible (because there's no data
> > loss for memory error,) but I'm not sure that code might be simple enough and/or
> > it's worth doing ...
> 
> I doubt it's worth doing, it's just too unlikely that a specific page
> is hit. Memory error handling is all about probabilities.
> 
> The test is just broken and should be fixed.
> 
> mce-test had similar problems at some point, but they were all fixed.

Well I disagree, the reason why the test fails is that MADV_HWPOISON on
not-faulted private mappings fails silently, which is a bug, albeit
minor one. If something is not implemented, it should report a failure,
the usual error return would be EINVAL in this case.

It appears that it fails with EBUSY on first try on newer kernels, but
still fails silently when we try for a second time.

Why can't we simply check if the page is faulted or not and return error
in the latter case?

-- 
Cyril Hrubis
chrubis@suse.cz

--
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>

^ permalink raw reply	[flat|nested] 26+ messages in thread
* [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
@ 2017-03-28  8:25         ` Cyril Hrubis
  0 siblings, 0 replies; 26+ messages in thread
From: Cyril Hrubis @ 2017-03-28  8:25 UTC (permalink / raw)
  To: ltp

Hi!
> > I think that what the testcase effectively does is to test whether memory
> > handling on zero pages works or not.
> > And the testcase's failure seems acceptable, because it's simply not-implemented yet.
> > Maybe recovering from error on zero page is possible (because there's no data
> > loss for memory error,) but I'm not sure that code might be simple enough and/or
> > it's worth doing ...
> 
> I doubt it's worth doing, it's just too unlikely that a specific page
> is hit. Memory error handling is all about probabilities.
> 
> The test is just broken and should be fixed.
> 
> mce-test had similar problems at some point, but they were all fixed.

Well I disagree, the reason why the test fails is that MADV_HWPOISON on
not-faulted private mappings fails silently, which is a bug, albeit
minor one. If something is not implemented, it should report a failure,
the usual error return would be EINVAL in this case.

It appears that it fails with EBUSY on first try on newer kernels, but
still fails silently when we try for a second time.

Why can't we simply check if the page is faulted or not and return error
in the latter case?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 26+ messages in thread
* Re: [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
  2017-03-28  8:25         ` Cyril Hrubis
@ 2017-03-28 20:26           ` Andi Kleen
  -1 siblings, 0 replies; 26+ messages in thread
From: Andi Kleen @ 2017-03-28 20:26 UTC (permalink / raw)
  To: Cyril Hrubis; +Cc: Andi Kleen, Naoya Horiguchi, linux-mm, ltp

> Well I disagree, the reason why the test fails is that MADV_HWPOISON on
> not-faulted private mappings fails silently, which is a bug, albeit
> minor one. If something is not implemented, it should report a failure,
> the usual error return would be EINVAL in this case.
> 
> It appears that it fails with EBUSY on first try on newer kernels, but
> still fails silently when we try for a second time.
> 
> Why can't we simply check if the page is faulted or not and return error
> in the latter case?

It's a debug interface. You're supposed to know what you're doing.

-Andi

--
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>

^ permalink raw reply	[flat|nested] 26+ messages in thread
* [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?
@ 2017-03-28 20:26           ` Andi Kleen
  0 siblings, 0 replies; 26+ messages in thread
From: Andi Kleen @ 2017-03-28 20:26 UTC (permalink / raw)
  To: ltp

> Well I disagree, the reason why the test fails is that MADV_HWPOISON on
> not-faulted private mappings fails silently, which is a bug, albeit
> minor one. If something is not implemented, it should report a failure,
> the usual error return would be EINVAL in this case.
> 
> It appears that it fails with EBUSY on first try on newer kernels, but
> still fails silently when we try for a second time.
> 
> Why can't we simply check if the page is faulted or not and return error
> in the latter case?

It's a debug interface. You're supposed to know what you're doing.

-Andi

^ permalink raw reply	[flat|nested] 26+ messages in thread
end of thread, other threads:[~2017-03-28 20:26 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-14 15:41 Is MADV_HWPOISON supposed to work only on faulted-in pages? Jan Stancek
2017-02-14 15:41 ` [LTP] " Jan Stancek
2017-02-20  5:00 ` Naoya Horiguchi
2017-02-20  5:00   ` [LTP] " Naoya Horiguchi
2017-02-23  3:23   ` Naoya Horiguchi
2017-02-23  3:23     ` [LTP] " Naoya Horiguchi
2017-02-25  2:28     ` Yisheng Xie
2017-02-25  2:28       ` [LTP] " Yisheng Xie
2017-02-27  1:20       ` Naoya Horiguchi
2017-02-27  1:20         ` [LTP] " Naoya Horiguchi
2017-02-27  4:27         ` Zi Yan
2017-02-27  4:27           ` [LTP] " Zi Yan
2017-02-27  6:33           ` Naoya Horiguchi
2017-02-27  6:33             ` [LTP] " Naoya Horiguchi
2017-02-27 16:10             ` Zi Yan
2017-02-27 16:10               ` [LTP] " Zi Yan
2017-03-14 13:20             ` Cyril Hrubis
2017-03-14 13:20               ` Cyril Hrubis
2017-03-27 12:08             ` Richard Palethorpe
2017-03-27 12:08               ` Richard Palethorpe
2017-03-27 23:54     ` Andi Kleen
2017-03-27 23:54       ` [LTP] " Andi Kleen
2017-03-28  8:25       ` Cyril Hrubis
2017-03-28  8:25         ` Cyril Hrubis
2017-03-28 20:26         ` Andi Kleen
2017-03-28 20:26           ` Andi Kleen

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.