From: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
To: Heiko Carstens <hca@linux.ibm.com>
Cc: Qian Cai <cai@redhat.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
linux-s390@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: BUG: Bad page state in process dirtyc0w_child
Date: Tue, 22 Sep 2020 19:03:50 +0200 [thread overview]
Message-ID: <20200922190350.7a0e0ca5@thinkpad> (raw)
In-Reply-To: <20200916142806.GD7076@osiris>
On Wed, 16 Sep 2020 16:28:06 +0200
Heiko Carstens <hca@linux.ibm.com> wrote:
> On Sat, Sep 12, 2020 at 09:54:12PM -0400, Qian Cai wrote:
> > Occasionally, running this LTP test will trigger an error below on
> > s390:
> > https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/security/dirtyc0w/dirtyc0w.c
> > https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/security/dirtyc0w/dirtyc0w_child.c
> >
> > this .config:
> > https://gitlab.com/cailca/linux-mm/-/blob/master/s390.config
> >
> > [ 6970.253173] LTP: starting dirtyc0w
> > [ 6971.599102] BUG: Bad page state in process dirtyc0w_child pfn:8865d
> > [ 6971.599867] page:000000001a8328d7 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8865d
> > [ 6971.599876] flags: 0x400000000008000e(referenced|uptodate|dirty|swapbacked)
> > [ 6971.599886] raw: 400000000008000e 0000000000000100 0000000000000122 0000000000000000
> > [ 6971.599893] raw: 0000000000000000 0000000000000000 ffffffff00000000 0000000000000000
> > [ 6971.599900] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
> > [ 6971.599906] Modules linked in: loop kvm ip_tables x_tables dm_mirror dm_region_hash dm_log dm_mod [last unloaded: dummy_del_mod]
> > [ 6971.599952] CPU: 1 PID: 65238 Comm: dirtyc0w_child Tainted: G O 5.9.0-rc4-next-20200909 #1
> > [ 6971.599959] Hardware name: IBM 2964 N96 400 (z/VM 6.4.0)
> > [ 6971.599964] Call Trace:
> > [ 6971.599979] [<0000000073aec038>] show_stack+0x158/0x1f0
> > [ 6971.599986] [<0000000073af724a>] dump_stack+0x1f2/0x238
> > [ 6971.599994] [<0000000072ed086a>] bad_page+0x1ba/0x1c0
> > [ 6971.600000] [<0000000072ed20c4>] free_pcp_prepare+0x4fc/0x658
> > [ 6971.600006] [<0000000072ed96a6>] free_unref_page+0xae/0x158
> > [ 6971.600013] [<0000000072e8286a>] unmap_page_range+0xb62/0x1df8
> > [ 6971.600019] [<0000000072e83bbc>] unmap_single_vma+0xbc/0x1c8
> > [ 6971.600025] [<0000000072e8418e>] zap_page_range+0x176/0x230
> > [ 6971.600033] [<0000000072eece8e>] do_madvise+0xfde/0x1270
> > [ 6971.600039] [<0000000072eed50a>] __s390x_sys_madvise+0x72/0x98
> > [ 6971.600047] [<0000000073b1cce4>] system_call+0xdc/0x278
> > [ 6971.600053] 2 locks held by dirtyc0w_child/65238:
> > [ 6971.600058] #0: 000000013442fa18 (&mm->mmap_lock){++++}-{3:3}, at: do_madvise+0x17a/0x1270
> > [ 6971.600432] #1: 00000001343f9060 (ptlock_ptr(page)#2){+.+.}-{2:2}, at: unmap_page_range+0x640/0x1df8
> > [ 6971.600487] Disabling lock debugging due to kernel taint
> >
> > Once it happens, running it again will trigger in on another PFN.
> >
> > [39717.085115] BUG: Bad page state in process dirtyc0w_child pfn:af065
> >
> > Any thoughts?
>
> Alexander, Gerald, could you take a look?
Thanks for reporting. From the header of dirtyc0w.c it seems that this
is testing some gup behavior. Given that we have an issue with gup_fast
on s390, this could be related. I'll try to reproduce and do more
analysis.
A fix for our gup_fast issue is also in linux-next now, as of 2020-09-20,
but it was not yet included in your kernel version 5.9.0-rc4-next-20200909.
So if this is related to the gup_fast issue, it should not occur again
with linux-next kernels after 2020-09-20.
next prev parent reply other threads:[~2020-09-22 17:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-13 1:54 BUG: Bad page state in process dirtyc0w_child Qian Cai
2020-09-16 14:28 ` Heiko Carstens
2020-09-22 17:03 ` Gerald Schaefer [this message]
2020-09-23 13:39 ` Gerald Schaefer
2020-09-23 20:00 ` Linus Torvalds
2020-09-23 21:33 ` Gerald Schaefer
2020-09-23 21:50 ` Linus Torvalds
2020-09-23 22:02 ` Gerald Schaefer
2020-09-24 12:06 ` Gerald Schaefer
2020-09-24 15:58 ` Linus Torvalds
2020-09-24 2:06 ` Qian Cai
2020-09-24 14:25 ` Alex Shi
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=20200922190350.7a0e0ca5@thinkpad \
--to=gerald.schaefer@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cai@redhat.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).