From: Dave Hansen <dave.hansen@intel.com>
To: Fengguang Wu <fengguang.wu@intel.com>, linux-mm@kvack.org
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"Michal Hocko" <mhocko@suse.com>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Mel Gorman" <mgorman@techsingularity.net>,
"Huang Ying" <ying.huang@intel.com>,
"Ross Zwisler" <ross.zwisler@linux.intel.com>,
"Minchan Kim" <minchan@kernel.org>,
"Hugh Dickins" <hughd@google.com>,
linux-kernel@vger.kernel.org, lkp@01.org
Subject: Re: BUG: Bad page map in process python2 pte:10000000000 pmd:17e8be067
Date: Thu, 19 Apr 2018 11:53:51 -0700 [thread overview]
Message-ID: <17463682-dc08-358d-8b44-02821352604c@intel.com> (raw)
In-Reply-To: <20180419054047.xxiljmzaf2u7odc6@wfg-t540p.sh.intel.com>
On 04/18/2018 10:40 PM, Fengguang Wu wrote:
> [ 716.494065] PASS concurrent_autogo_5ghz_ht40 4.803608 2018-03-23 09:57:21.586794
> [ 716.494069]
> [ 716.496923] passed all 1 test case(s)
> [ 716.496926]
> [ 716.511702] swap_info_get: Bad swap file entry 04000000
> [ 716.512731] BUG: Bad page map in process python2 pte:100_0000_0000 pmd:17e8be067
> [ 716.513844] addr:00000000860ba23b vm_flags:00000070 anon_vma: (null) mapping:000000004c76fece index:1e2
> [ 716.515160] file:libpcre.so.3.13.3 fault:filemap_fault mmap:generic_file_mmap readpage:simple_readpage
> [ 716.516418] CPU: 2 PID: 8907 Comm: python2 Not tainted 4.16.0-rc5 #1
> [ 716.517533] Hardware name: /DH67GD, BIOS BLH6710H.86A.0132.2011.1007.1505 10/07/2011
Did you say that you have a few more examples of this?
I would be really interested if it's always python or always the same
shared library, or always file-backed memory, always the same bit,
etc... From the vm_flags, I'd guess that this is the "rw-p" part of the
file mapping.
The bit that gets set is really weird. It's bit 40. I could definitely
see scenarios where we might set the dirty bit, or even NX for that
matter, or some *bit* that we mess with in software. It's not even
close to the boundary where it could represent a swapoffset=1 or swapfile=1.
It's also unlikely to be _PAGE_PSE having gone missing from the PMD
since it's in the middle of a file-backed mapping and the PMD is
obviously pointing to a 4k page.
If I had to put money on it, I'd guess it's a hardware bit flip, or less
likely, a rogue software bit flip. But, more examples will hopefully
shed some more light.
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave.hansen@intel.com>
To: lkp@lists.01.org
Subject: Re: BUG: Bad page map in process python2 pte:10000000000 pmd:17e8be067
Date: Thu, 19 Apr 2018 11:53:51 -0700 [thread overview]
Message-ID: <17463682-dc08-358d-8b44-02821352604c@intel.com> (raw)
In-Reply-To: <20180419054047.xxiljmzaf2u7odc6@wfg-t540p.sh.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]
On 04/18/2018 10:40 PM, Fengguang Wu wrote:
> [ 716.494065] PASS concurrent_autogo_5ghz_ht40 4.803608 2018-03-23 09:57:21.586794
> [ 716.494069]
> [ 716.496923] passed all 1 test case(s)
> [ 716.496926]
> [ 716.511702] swap_info_get: Bad swap file entry 04000000
> [ 716.512731] BUG: Bad page map in process python2 pte:100_0000_0000 pmd:17e8be067
> [ 716.513844] addr:00000000860ba23b vm_flags:00000070 anon_vma: (null) mapping:000000004c76fece index:1e2
> [ 716.515160] file:libpcre.so.3.13.3 fault:filemap_fault mmap:generic_file_mmap readpage:simple_readpage
> [ 716.516418] CPU: 2 PID: 8907 Comm: python2 Not tainted 4.16.0-rc5 #1
> [ 716.517533] Hardware name: /DH67GD, BIOS BLH6710H.86A.0132.2011.1007.1505 10/07/2011
Did you say that you have a few more examples of this?
I would be really interested if it's always python or always the same
shared library, or always file-backed memory, always the same bit,
etc... From the vm_flags, I'd guess that this is the "rw-p" part of the
file mapping.
The bit that gets set is really weird. It's bit 40. I could definitely
see scenarios where we might set the dirty bit, or even NX for that
matter, or some *bit* that we mess with in software. It's not even
close to the boundary where it could represent a swapoffset=1 or swapfile=1.
It's also unlikely to be _PAGE_PSE having gone missing from the PMD
since it's in the middle of a file-backed mapping and the PMD is
obviously pointing to a 4k page.
If I had to put money on it, I'd guess it's a hardware bit flip, or less
likely, a rogue software bit flip. But, more examples will hopefully
shed some more light.
next prev parent reply other threads:[~2018-04-19 18:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-19 5:40 BUG: Bad page map in process python2 pte:10000000000 pmd:17e8be067 Fengguang Wu
2018-04-19 5:40 ` Fengguang Wu
2018-04-19 18:53 ` Dave Hansen [this message]
2018-04-19 18:53 ` Dave Hansen
2018-05-03 3:20 ` Huaitong Han
2018-05-03 14:42 ` Dave Hansen
2018-05-03 14:42 ` Dave Hansen
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=17463682-dc08-358d-8b44-02821352604c@intel.com \
--to=dave.hansen@intel.com \
--cc=akpm@linux-foundation.org \
--cc=fengguang.wu@intel.com \
--cc=hughd@google.com \
--cc=jglisse@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@01.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=ross.zwisler@linux.intel.com \
--cc=ying.huang@intel.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.