linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lars Persson <lists@bofh.nu>
To: Jan Stancek <jstancek@redhat.com>
Cc: linux-mm@kvack.org, lersek@redhat.com,
	 alex williamson <alex.williamson@redhat.com>,
	aarcange@redhat.com, rientjes@google.com,  kirill@shutemov.name,
	mgorman@techsingularity.net, mhocko@suse.com,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm: page_mapped: don't assume compound page is huge or THP
Date: Mon, 18 Feb 2019 14:43:58 +0100	[thread overview]
Message-ID: <CADnJP=t25=AcVq7z3w8iG1+ywnSNN4Vbow3-7tOai+qnyD5ACQ@mail.gmail.com> (raw)
In-Reply-To: <997509746.100933786.1549350874925.JavaMail.zimbra@redhat.com>

On Tue, Feb 5, 2019 at 8:14 AM Jan Stancek <jstancek@redhat.com> wrote:
> Hi,
>
> are you using THP (CONFIG_TRANSPARENT_HUGEPAGE)?
>
> The changed line should affect only THP and normal compound pages,
> so a test with THP disabled might be interesting.
>
> >
> > The breakage consists of random processes dying with SIGILL or SIGSEGV
> > when we stress test the system with high memory pressure and explicit
> > memory compaction requested through /proc/sys/vm/compact_memory.
> > Reverting this patch fixes the crashes.
> >
> > We can put some effort on debugging if there are no obvious
> > explanations for this. Keep in mind that this is 32-bit system with
> > HIGHMEM.
>
> Nothing obvious that I can see. I've been trying to reproduce on
> 32-bit x86 Fedora with no luck so far.
>

Hi

Thanks for looking in to it. After some deep dive in MM code, I think
it is safe to say this patch was innocent.

All traces studied so far points to a missing cache coherency call in
mm/migrate.c:migrate_page that is needed only for those evil MIPSes
that lack I/D cache coherency. I will send a write-up to linux-mips
about this. Basically for a non-mapped page it does only a copy of
page data and metadata but no flush_dcache_page() call will be done.
This races with subsequent use of the page.

BR,
 Lars


  reply	other threads:[~2019-02-18 13:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-29 21:53 [PATCH] " Jan Stancek
2018-11-30 10:19 ` Kirill A. Shutemov
2018-11-30 12:06 ` [PATCH v2] " Jan Stancek
2018-11-30 12:18   ` Michal Hocko
2018-11-30 12:36     ` Kirill A. Shutemov
2018-11-30 12:45       ` Michal Hocko
2018-11-30 12:55         ` Kirill A. Shutemov
2018-11-30 15:53   ` David Hildenbrand
2018-12-03 10:23   ` Laszlo Ersek
2018-12-03 11:28     ` Kirill A. Shutemov
2019-01-04 21:56   ` Andrea Arcangeli
2019-02-04 14:38   ` Lars Persson
2019-02-05  7:14     ` Jan Stancek
2019-02-18 13:43       ` Lars Persson [this message]
2019-02-18 13:50         ` Michal Hocko

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='CADnJP=t25=AcVq7z3w8iG1+ywnSNN4Vbow3-7tOai+qnyD5ACQ@mail.gmail.com' \
    --to=lists@bofh.nu \
    --cc=aarcange@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=jstancek@redhat.com \
    --cc=kirill@shutemov.name \
    --cc=lersek@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=rientjes@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox