From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: zhong jiang <zhongjiang@huawei.com>
Cc: Minchan Kim <minchan@kernel.org>,
Michal Hocko <mhocko@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Linux Memory Management List <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Qestion] Hit a WARN_ON_ONCE in try_to_unmap_one when runing syzkaller
Date: Thu, 14 Mar 2019 06:27:55 +0000 [thread overview]
Message-ID: <20190314062757.GA27899@hori.linux.bs1.fc.nec.co.jp> (raw)
In-Reply-To: <5C87D848.7030802@huawei.com>
Hi,
On Wed, Mar 13, 2019 at 12:03:20AM +0800, zhong jiang wrote:
...
>
> Minchan has changed the conditon check from BUG_ON to WARN_ON_ONCE in try_to_unmap_one.
> However, It is still an abnormal condition when PageSwapBacked is not equal to PageSwapCache.
>
> But Is there any case it will meet the conditon in the mainline.
>
> It is assumed that PageSwapBacked(page) is true in the anonymous page, This is to say, PageSwapcache
> is false. however, That is impossible because we will update the pte for hwpoison entry.
>
> Because page is locked , Its page flags should not be changed except for PageSwapBacked
try_to_unmap_one() from hwpoison_user_mappings() could reach the
WARN_ON_ONCE() only if TTU_IGNORE_HWPOISON is set, because PageHWPoison()
is set at the beginning of memory_failure().
Clearing TTU_IGNORE_HWPOISON might happen on the following two paths:
static bool hwpoison_user_mappings(struct page *p, unsigned long pfn,
int flags, struct page **hpagep)
{
...
if (PageSwapCache(p)) {
pr_err("Memory failure: %#lx: keeping poisoned page in swap cache\n",
pfn);
ttu |= TTU_IGNORE_HWPOISON;
}
...
mapping = page_mapping(hpage);
if (!(flags & MF_MUST_KILL) && !PageDirty(hpage) && mapping &&
mapping_cap_writeback_dirty(mapping)) {
if (page_mkclean(hpage)) {
SetPageDirty(hpage);
} else {
kill = 0;
ttu |= TTU_IGNORE_HWPOISON;
pr_info("Memory failure: %#lx: corrupted page was clean: dropped without side effects\n",
pfn);
}
}
...
unmap_success = try_to_unmap(hpage, ttu);
...
So either of the above "ttu |= TTU_IGNORE_HWPOISON" should be executed.
I'm not sure which one, but both paths show printk messages, so if you
could have kernel message log, that might help ...
Thanks,
Naoya Horiguchi
WARNING: multiple messages have this Message-ID (diff)
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: zhong jiang <zhongjiang@huawei.com>
Cc: Minchan Kim <minchan@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Vlastimil Babka <vbabka@suse.cz>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [Qestion] Hit a WARN_ON_ONCE in try_to_unmap_one when runing syzkaller
Date: Thu, 14 Mar 2019 06:27:55 +0000 [thread overview]
Message-ID: <20190314062757.GA27899@hori.linux.bs1.fc.nec.co.jp> (raw)
In-Reply-To: <5C87D848.7030802@huawei.com>
Hi,
On Wed, Mar 13, 2019 at 12:03:20AM +0800, zhong jiang wrote:
...
>
> Minchan has changed the conditon check from BUG_ON to WARN_ON_ONCE in try_to_unmap_one.
> However, It is still an abnormal condition when PageSwapBacked is not equal to PageSwapCache.
>
> But Is there any case it will meet the conditon in the mainline.
>
> It is assumed that PageSwapBacked(page) is true in the anonymous page, This is to say, PageSwapcache
> is false. however, That is impossible because we will update the pte for hwpoison entry.
>
> Because page is locked , Its page flags should not be changed except for PageSwapBacked
try_to_unmap_one() from hwpoison_user_mappings() could reach the
WARN_ON_ONCE() only if TTU_IGNORE_HWPOISON is set, because PageHWPoison()
is set at the beginning of memory_failure().
Clearing TTU_IGNORE_HWPOISON might happen on the following two paths:
static bool hwpoison_user_mappings(struct page *p, unsigned long pfn,
int flags, struct page **hpagep)
{
...
if (PageSwapCache(p)) {
pr_err("Memory failure: %#lx: keeping poisoned page in swap cache\n",
pfn);
ttu |= TTU_IGNORE_HWPOISON;
}
...
mapping = page_mapping(hpage);
if (!(flags & MF_MUST_KILL) && !PageDirty(hpage) && mapping &&
mapping_cap_writeback_dirty(mapping)) {
if (page_mkclean(hpage)) {
SetPageDirty(hpage);
} else {
kill = 0;
ttu |= TTU_IGNORE_HWPOISON;
pr_info("Memory failure: %#lx: corrupted page was clean: dropped without side effects\n",
pfn);
}
}
...
unmap_success = try_to_unmap(hpage, ttu);
...
So either of the above "ttu |= TTU_IGNORE_HWPOISON" should be executed.
I'm not sure which one, but both paths show printk messages, so if you
could have kernel message log, that might help ...
Thanks,
Naoya Horiguchi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-03-14 6:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-12 16:03 [Qestion] Hit a WARN_ON_ONCE in try_to_unmap_one when runing syzkaller zhong jiang
2019-03-12 16:03 ` zhong jiang
2019-03-14 6:27 ` Naoya Horiguchi [this message]
2019-03-14 6:27 ` Naoya Horiguchi
2019-03-14 6:27 ` Naoya Horiguchi
2019-03-14 7:54 ` zhong jiang
2019-03-14 7:54 ` zhong jiang
2019-03-14 7:54 ` zhong jiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190314062757.GA27899@hori.linux.bs1.fc.nec.co.jp \
--to=n-horiguchi@ah.jp.nec.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=minchan@kernel.org \
--cc=vbabka@suse.cz \
--cc=zhongjiang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.