From: David Miller <davem@davemloft.net>
To: mroos@linux.ee
Cc: aaro.koskinen@iki.fi, sparclinux@vger.kernel.org,
linux-kernel@vger.kernel.org, hughd@google.com,
cat.schulze@alice-dsl.net
Subject: Re: sparc64 WARNING: at mm/mmap.c:2757 exit_mmap+0x13c/0x160()
Date: Tue, 29 Jul 2014 16:26:35 -0700 (PDT) [thread overview]
Message-ID: <20140729.162635.638786990787878495.davem@davemloft.net> (raw)
In-Reply-To: <alpine.SOC.1.00.1404170119550.20193@math.ut.ee>
From: mroos@linux.ee
Date: Thu, 17 Apr 2014 01:22:17 +0300 (EEST)
>> > Just for the archives, I got one of these again with 3.14:
>>
>> Meelis and Aaro, thanks again for all of your reports.
>>
>> After pouring over a lot of the data and auditing some code I'm
>> suspecting it's a problem with transparent huge pages.
>>
>> One thing you two can do to help me further confirm this is to run
>> with THP disabled for a while and see if you still get the log
>> messages.
>
> I have snice turned off CONFIG_TRANSPARENT_HUGEPAGE on 3 of 4 servers
> that had this problem (actually most of my sparc64 machines) and the 4th
> has
>
> CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
> CONFIG_TRANSPARENT_HUGEPAGE=y
> # CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set
> CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
> # CONFIG_HUGETLBFS is not set
> # CONFIG_HUGETLB_PAGE is not se
>
> and also has not had this problem since then. All 4 machines have been
> running through most -rc's of every kernel.
Here is something I'd like you guys to test.
Yesterday, Christopher (CC:'d), posted some fixes yesterday and one of
them is very interesting.
Basically the update_mmu_cache() methods on sparc64 can insert an
invalid PTE into the TSB hash tables, causing livelocks and other
annoying issues.
The path where this can happen is via remove_migration_pte().
I had a discussion with Johannes Weiner about this and we determined
that it would make sense to mis-diagnose THP as being the root cause
in the RSS counter et al. problems if this bug here is the real
reason those things are happening.
That's because if you're not using THP there is less compaction going
on. Less compaction means less migration, and therefore a lower
likelyhood of this code path triggering like this.
Could you guys please try this patch below? Thanks.
diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index 16b58ff..8e894e0 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -351,6 +351,10 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned long address, pte_t *
mm = vma->vm_mm;
+ /* Don't insert a non-valid PTE into the TSB, we'll deadlock. */
+ if (!pte_accessible(mm, pte))
+ return;
+
spin_lock_irqsave(&mm->context.lock, flags);
#if defined(CONFIG_HUGETLB_PAGE) || defined(CONFIG_TRANSPARENT_HUGEPAGE)
@@ -2617,6 +2621,10 @@ void update_mmu_cache_pmd(struct vm_area_struct *vma, unsigned long addr,
if (!pmd_large(entry) || !pmd_young(entry))
return;
+ /* Don't insert a non-valid PMD into the TSB, we'll deadlock. */
+ if (!(pte & _PAGE_VALID))
+ return;
+
pte = pmd_val(entry);
/* We are fabricating 8MB pages using 4MB real hw pages. */
next prev parent reply other threads:[~2014-07-29 23:26 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-16 21:06 Meelis Roos
2013-06-17 5:32 ` Aaro Koskinen
2013-06-17 5:58 ` Aaro Koskinen
2013-08-03 20:40 ` David Miller
2013-10-22 17:46 ` Aaro Koskinen
2013-10-22 17:54 ` David Miller
2014-04-14 18:43 ` Aaro Koskinen
2014-04-14 18:58 ` David Miller
2014-04-16 18:58 ` David Miller
2014-04-16 22:22 ` mroos
2014-04-16 22:49 ` David Miller
2014-07-29 23:26 ` David Miller [this message]
2014-07-30 22:02 ` Meelis Roos
2014-07-30 22:07 ` David Miller
2014-08-13 11:44 ` Meelis Roos
2014-08-13 19:46 ` David Miller
2014-08-14 12:20 ` Meelis Roos
2014-08-15 12:42 ` Meelis Roos
2014-08-18 12:30 ` Meelis Roos
2014-08-18 17:35 ` Aaro Koskinen
2014-08-18 17:38 ` David Miller
2014-08-30 22:27 ` Aaro Koskinen
2014-08-18 23:45 ` Julian Calaby
2014-08-19 21:29 ` Aaro Koskinen
2014-08-19 8:22 ` Meelis Roos
2014-04-25 20:09 ` Aaro Koskinen
2014-04-25 20:17 ` David Miller
2014-05-24 20:02 ` mroos
2014-05-24 21:08 ` David Miller
2014-06-09 6:36 ` Meelis Roos
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=20140729.162635.638786990787878495.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=aaro.koskinen@iki.fi \
--cc=cat.schulze@alice-dsl.net \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mroos@linux.ee \
--cc=sparclinux@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
all inboxes | Powered by JetHome®