[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200917130948.GA1812@linux>
Date: Thu, 17 Sep 2020 15:09:52 +0200
From: Oscar Salvador <osalvador@...e.de>
To: HORIGUCHI NAOYA(堀口 直也)
<naoya.horiguchi@....com>
Cc: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"aris@...vo.org" <aris@...vo.org>,
"mhocko@...nel.org" <mhocko@...nel.org>,
"tony.luck@...el.com" <tony.luck@...el.com>,
"cai@....pw" <cai@....pw>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH v4 0/7] HWpoison: further fixes and cleanups
On Thu, Sep 17, 2020 at 11:39:21AM +0000, HORIGUCHI NAOYA(堀口 直也) wrote:
> Thanks for the update.
> This patchset triggers the following BUG_ON() with Aristeu's workload:
I just took a look, but I found more oddities.
The patchset you sent seems to be a bit buggy and it is missing some things
my patchset contains, e.g:
static __always_inline bool free_pages_prepare(struct page *page,
unsigned int order, bool check_free)
{
...
if (unlikely(PageHWPoison(page)) && !order) {
...
return false;
}
Moreover, in page_handle_poison, you managed it wrong because:
static bool page_handle_poison(struct page *page, bool hugepage_or_freepage, bool release)
{
if (release) {
put_page(page);
drain_all_pages(page_zone(page));
}
...
SetPageHWPoison(page);
page_ref_inc(page);
1) You are freeing the page first, which means it goes to buddy
2) Then you set it as poisoned and you update its refcount.
Now we have a page sitting in Buddy with a refcount = 1 and poisoned, and that is quite wrong.
Honestly, I do not know how your patchset diverged so much from mine, but is
not right.
I will go over my patchset and yours and compare/fix things.
--
Oscar Salvador
SUSE L3
Powered by blists - more mailing lists