[LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Jan Stancek]

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

Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Jan Stancek]

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>

[LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Naoya Horiguchi]

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>

Re: Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Naoya Horiguchi]

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>

[LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Naoya Horiguchi]

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

Re: Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Naoya Horiguchi]

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>

[LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Yisheng Xie]

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.

Re: Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Yisheng Xie]

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>

[LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Naoya Horiguchi]

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

Re: Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Naoya Horiguchi]

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>

[LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Zi Yan]

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>

Re: Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Zi Yan]

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

[LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Naoya Horiguchi]

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

Re: Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Naoya Horiguchi]

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>

[LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Zi Yan]

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>

Re: Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Zi Yan]

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

Re: [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Cyril Hrubis]

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>

[LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Cyril Hrubis]

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

[LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Richard Palethorpe]

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.

Re: [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Richard Palethorpe]

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>

[LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Andi Kleen]

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

Re: Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Andi Kleen]

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>

[LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Cyril Hrubis]

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

Re: [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Cyril Hrubis]

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>

[LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Andi Kleen]

> 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

Re: [LTP] Is MADV_HWPOISON supposed to work only on faulted-in pages?

[Andi Kleen]

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