search for: hwpoisoned

....19 15:45, Michal Hocko wrote: [...] > > There is state stored in the struct page. In other words this shouldn't > > be really different from HWPoison pages. I cannot find the code that is > > doing that and maybe we don't handle that. But we cannot simply online > > hwpoisoned page. Offlining the range will not make a broken memory OK > > all of the sudden. And your usecase sounds similar to me. > > Sorry to say, but whenever we online memory the memmap is overwritten, > because there is no way you could tell it contains garbage or not. You have > to a...

...king > (rc != -EAGAIN) is simply incorrect. Your change fixes the bug in memory > error handling. Great! Thanks for confirming, Naoya. I will send it as separate patch with Ccing -stable. > > > And when I read memory_failure, it bails out without killing if it > > encounters HWPoisoned page so I think it's not for catching and > > kill the poor proces. > > > > > > > > Also (but not your fault) the put_page() preceding > > > test_set_page_hwpoison(page)) IMHO deserves a comment saying which > > > pin we are releasing and which o...

...king > (rc != -EAGAIN) is simply incorrect. Your change fixes the bug in memory > error handling. Great! Thanks for confirming, Naoya. I will send it as separate patch with Ccing -stable. > > > And when I read memory_failure, it bails out without killing if it > > encounters HWPoisoned page so I think it's not for catching and > > kill the poor proces. > > > > > > > > Also (but not your fault) the put_page() preceding > > > test_set_page_hwpoison(page)) IMHO deserves a comment saying which > > > pin we are releasing and which o...

...and keep them in the offline state right? We do not poison offlined pages. There is state stored in the struct page. In other words this shouldn't be really different from HWPoison pages. I cannot find the code that is doing that and maybe we don't handle that. But we cannot simply online hwpoisoned page. Offlining the range will not make a broken memory OK all of the sudden. And your usecase sounds similar to me. > The driver that marked these pages to be skipped when offlining is > responsible for registering the online_page_callback_t callback where these > pages will get excluded...

...and keep them in the offline state right? We do not poison offlined pages. There is state stored in the struct page. In other words this shouldn't be really different from HWPoison pages. I cannot find the code that is doing that and maybe we don't handle that. But we cannot simply online hwpoisoned page. Offlining the range will not make a broken memory OK all of the sudden. And your usecase sounds similar to me. > The driver that marked these pages to be skipped when offlining is > responsible for registering the online_page_callback_t callback where these > pages will get excluded...

On 03/30/2016 09:12 AM, Minchan Kim wrote: > Procedure of page migration is as follows: > > First of all, it should isolate a page from LRU and try to > migrate the page. If it is successful, it releases the page > for freeing. Otherwise, it should put the page back to LRU > list. > > For LRU pages, we have used putback_lru_page for both freeing > and putback to LRU

On 03/30/2016 09:12 AM, Minchan Kim wrote: > Procedure of page migration is as follows: > > First of all, it should isolate a page from LRU and try to > migrate the page. If it is successful, it releases the page > for freeing. Otherwise, it should put the page back to LRU > list. > > For LRU pages, we have used putback_lru_page for both freeing > and putback to LRU

...verity (the latter causes kernel crash,) which led to the current code. > > And another practical thing is the race with unpoison_memory() as described > > in commit da1b13ccfbebe. unpoison_memory() properly works only for properly > > poisoned pages, so doing unpoison for in-use hwpoisoned pages is fragile. > > That's why I'd like to avoid setting PageHWPoison for in-use pages if possible. > > > >> (Also, which part prevents pages with PageHWPoison to be allocated > >> again, anyway? I can't find it and test_set_page_hwpoison() doesn't &...

...verity (the latter causes kernel crash,) which led to the current code. > > And another practical thing is the race with unpoison_memory() as described > > in commit da1b13ccfbebe. unpoison_memory() properly works only for properly > > poisoned pages, so doing unpoison for in-use hwpoisoned pages is fragile. > > That's why I'd like to avoid setting PageHWPoison for in-use pages if possible. > > > >> (Also, which part prevents pages with PageHWPoison to be allocated > >> again, anyway? I can't find it and test_set_page_hwpoison() doesn't &...

...on's failure, we shouldn't call test_set_page_hwpoison or num_poisoned_pages_inc, so current code checking (rc != -EAGAIN) is simply incorrect. Your change fixes the bug in memory error handling. Great! > And when I read memory_failure, it bails out without killing if it > encounters HWPoisoned page so I think it's not for catching and > kill the poor proces. > > > > > Also (but not your fault) the put_page() preceding > > test_set_page_hwpoison(page)) IMHO deserves a comment saying which > > pin we are releasing and which one we still have (hopefully? i...

...on's failure, we shouldn't call test_set_page_hwpoison or num_poisoned_pages_inc, so current code checking (rc != -EAGAIN) is simply incorrect. Your change fixes the bug in memory error handling. Great! > And when I read memory_failure, it bails out without killing if it > encounters HWPoisoned page so I think it's not for catching and > kill the poor proces. > > > > > Also (but not your fault) the put_page() preceding > > test_set_page_hwpoison(page)) IMHO deserves a comment saying which > > pin we are releasing and which one we still have (hopefully? i...

...memmap is basically garbage and not trustworthy. > > There is state stored in the struct page. In other words this shouldn't > be really different from HWPoison pages. I cannot find the code that is > doing that and maybe we don't handle that. But we cannot simply online > hwpoisoned page. Offlining the range will not make a broken memory OK > all of the sudden. And your usecase sounds similar to me. Sorry to say, but whenever we online memory the memmap is overwritten, because there is no way you could tell it contains garbage or not. You have to assume it is garbage. (m...

...m_poisoned_pages are successful migration, already freed page and successful invalidated page. IOW, they are already successful isolated page so I guess it should increase the count when only successful migration is done? And when I read memory_failure, it bails out without killing if it encounters HWPoisoned page so I think it's not for catching and kill the poor proces. > > Also (but not your fault) the put_page() preceding > test_set_page_hwpoison(page)) IMHO deserves a comment saying which > pin we are releasing and which one we still have (hopefully? if I > read description of...

On Thu 19-09-19 16:22:25, David Hildenbrand wrote: > virtio-mem wants to allow to offline memory blocks of which some parts > were unplugged, especially, to later offline and remove completely > unplugged memory blocks. The important part is that PageOffline() has > to remain set until the section is offline, so these pages will never > get accessed (e.g., when dumping). The pages

On Thu 19-09-19 16:22:25, David Hildenbrand wrote: > virtio-mem wants to allow to offline memory blocks of which some parts > were unplugged, especially, to later offline and remove completely > unplugged memory blocks. The important part is that PageOffline() has > to remain set until the section is offline, so these pages will never > get accessed (e.g., when dumping). The pages

...es looks to me an overkill. And marking hwpoison means that we can no longer do retry from userspace. And another practical thing is the race with unpoison_memory() as described in commit da1b13ccfbebe. unpoison_memory() properly works only for properly poisoned pages, so doing unpoison for in-use hwpoisoned pages is fragile. That's why I'd like to avoid setting PageHWPoison for in-use pages if possible. > (Also, which part prevents pages with PageHWPoison to be allocated > again, anyway? I can't find it and test_set_page_hwpoison() doesn't > remove from buddy freelists). che...

...es looks to me an overkill. And marking hwpoison means that we can no longer do retry from userspace. And another practical thing is the race with unpoison_memory() as described in commit da1b13ccfbebe. unpoison_memory() properly works only for properly poisoned pages, so doing unpoison for in-use hwpoisoned pages is fragile. That's why I'd like to avoid setting PageHWPoison for in-use pages if possible. > (Also, which part prevents pages with PageHWPoison to be allocated > again, anyway? I can't find it and test_set_page_hwpoison() doesn't > remove from buddy freelists). che...

..._pages_inc, so current code checking > (rc != -EAGAIN) is simply incorrect. Your change fixes the bug in memory > error handling. Great! Ah, I see, soft onlining works differently than I thought. >> And when I read memory_failure, it bails out without killing if it >> encounters HWPoisoned page so I think it's not for catching and >> kill the poor proces. >> >>> >>> Also (but not your fault) the put_page() preceding >>> test_set_page_hwpoison(page)) IMHO deserves a comment saying which >>> pin we are releasing and which one we still...

...be it will be just enough to switch the test_set_page_hwpoison() and put_page() calls? > And another practical thing is the race with unpoison_memory() as described > in commit da1b13ccfbebe. unpoison_memory() properly works only for properly > poisoned pages, so doing unpoison for in-use hwpoisoned pages is fragile. > That's why I'd like to avoid setting PageHWPoison for in-use pages if possible. > >> (Also, which part prevents pages with PageHWPoison to be allocated >> again, anyway? I can't find it and test_set_page_hwpoison() doesn't >> remove from...

...e *page, int count, int migratetype, int flags); @@ -58,7 +60,7 @@ undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn, * Test all pages in [start_pfn, end_pfn) are isolated or not. */ int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn, - bool skip_hwpoisoned_pages); + int flags); struct page *alloc_migrate_target(struct page *page, unsigned long private); diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index f08eb429b8f3..d23ff7c5c96b 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1127,7 +1127,8 @@ static bool is_pageblock...