From: Andrew Morton <akpm@linux-foundation.org>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
linux-parisc@vger.kernel.org, linux-mm@kvack.org
Subject: Re: 4.0-rc1/PARISC: BUG: non-zero nr_pmds on freeing mm
Date: Wed, 25 Feb 2015 14:13:58 -0800 [thread overview]
Message-ID: <20150225141358.8bd74b14c6e1ae039d25dc1c@linux-foundation.org> (raw)
In-Reply-To: <20150225215757.GA23672@node.dhcp.inet.fi>
On Wed, 25 Feb 2015 23:57:57 +0200 "Kirill A. Shutemov" <kirill@shutemov.name> wrote:
> On Wed, Feb 25, 2015 at 01:31:40PM -0800, Andrew Morton wrote:
> > On Wed, 25 Feb 2015 22:47:43 +0200 "Kirill A. Shutemov" <kirill@shutemov.name> wrote:
> >
> > > > > If not, I can prepare a patchset which only adds missing
> > > > > __PAGETABLE_PUD_FOLDED and __PAGETABLE_PMD_FOLDED.
> > > >
> > > > Something simple would be preferred, but I don't know how much simpler
> > > > the above would be?
> > >
> > > Not much simplier: __PAGETABLE_PMD_FOLDED is missing in frv, m32r, m68k,
> > > mn10300, parisc and s390.
> >
> > I don't really know what's going on here. Let's rewind a bit, please.
> > What is the bug, what causes it, which commit caused it and why the
> > heck does it require a massive patchset to fix 4.0?
>
> PMD accounting happens in __pmd_alloc() and free_pmd_range(). PMD
> accounting only makes sense on architectures with 3 or more page tables
> levels. We use __PAGETABLE_PMD_FOLDED to check whether the PMD page table
> level exists.
>
> Unfortunately, some architectures don't use <asm-generic/pgtable-nopmd.h>
> to indicate that PMD level doesn't exists and fold it in a custom way.
> Some of them don't define __PAGETABLE_PMD_FOLDED as pgtable-nopmd.h does.
>
> Missing __PAGETABLE_PMD_FOLDED causes undeflow of mm->nr_pmds:
> __pmd_alloc() is never called, but we decrement mm->nr_pmds in
> free_pmd_range().
>
> These architecures need to be fixed to define __PAGETABLE_PMD_FOLDED too.
>
> I can do in one patch if you want. Or split per-arch. After that
> CONFIG_PGTABLE_LEVELS patchset will require rebasing.
I guess one patch will be OK - arch maintainers will be able
review/apply/test that easily enough.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2015-02-25 22:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-24 22:54 Aaro Koskinen
2015-02-25 20:21 ` Kirill A. Shutemov
2015-02-25 20:30 ` Andrew Morton
2015-02-25 20:47 ` Kirill A. Shutemov
2015-02-25 21:31 ` Andrew Morton
2015-02-25 21:57 ` Kirill A. Shutemov
2015-02-25 22:13 ` Andrew Morton [this message]
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=20150225141358.8bd74b14c6e1ae039d25dc1c@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=aaro.koskinen@iki.fi \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-mm@kvack.org \
--cc=linux-parisc@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