From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)
Date: Tue, 23 Feb 2016 18:47:14 +0000 [thread overview]
Message-ID: <20160223184658.GA27281@arm.com> (raw)
In-Reply-To: <20160223191907.25719a4d@thinkpad>
[adding Steve, since he worked on THP for 32-bit ARM]
On Tue, Feb 23, 2016 at 07:19:07PM +0100, Gerald Schaefer wrote:
> On Tue, 23 Feb 2016 13:32:21 +0300
> "Kirill A. Shutemov" <kirill@shutemov•name> wrote:
> > The theory is that the splitting bit effetely masked bogus pmd_present():
> > we had pmd_trans_splitting() in all code path and that prevented mm from
> > touching the pmd. Once pmd_trans_splitting() has gone, mm proceed with the
> > pmd where it shouldn't and here's a boom.
>
> Well, I don't think pmd_present() == true is bogus for a trans_huge pmd under
> splitting, after all there is a page behind the the pmd. Also, if it was
> bogus, and it would need to be false, why should it be marked !pmd_present()
> only at the pmdp_invalidate() step before the pmd_populate()? It clearly
> is pmd_present() before that, on all architectures, and if there was any
> problem/race with that, setting it to !pmd_present() at this stage would
> only (marginally) reduce the race window.
>
> BTW, PowerPC and Sparc seem to do the same thing in pmdp_invalidate(),
> i.e. they do not set pmd_present() == false, only mark it so that it would
> not generate a new TLB entry, just like on s390. After all, the function
> is called pmdp_invalidate(), and I think the comment in mm/huge_memory.c
> before that call is just a little ambiguous in its wording. When it says
> "mark the pmd notpresent" it probably means "mark it so that it will not
> generate a new TLB entry", which is also what the comment is really about:
> prevent huge and small entries in the TLB for the same page at the same
> time.
>
> FWIW, and since the ARM arch-list is already on cc, I think there is
> an issue with pmdp_invalidate() on ARM, since it also seems to clear
> the trans_huge (and formerly trans_splitting) bit, which actually makes
> the pmd !pmd_present(), but it violates the other requirement from the
> comment:
> "the pmd_trans_huge and pmd_trans_splitting must remain set at all times
> on the pmd until the split is complete for this pmd"
I've only been testing this for arm64 (where I'm yet to see a problem),
but we use the generic pmdp_invalidate implementation from
mm/pgtable-generic.c there. On arm64, pmd_trans_huge will return true
after pmd_mknotpresent. On arm, it does look to be buggy, since it nukes
the entire entry... Steve?
Will
next prev parent reply other threads:[~2016-02-23 18:47 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-11 18:22 [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM) Gerald Schaefer
2016-02-11 19:09 ` Kirill A. Shutemov
2016-02-11 19:12 ` Kirill A. Shutemov
2016-02-12 12:21 ` Sebastian Ott
2016-02-11 19:57 ` Gerald Schaefer
2016-02-12 4:04 ` Aneesh Kumar K.V
2016-02-12 11:59 ` Gerald Schaefer
2016-02-12 16:17 ` Aneesh Kumar K.V
2016-02-12 10:01 ` Will Deacon
2016-02-12 10:12 ` Sebastian Ott
2016-02-12 15:52 ` Will Deacon
2016-02-12 15:41 ` Kirill A. Shutemov
2016-02-12 15:57 ` Christian Borntraeger
2016-02-12 17:16 ` Gerald Schaefer
2016-02-12 23:15 ` Kirill A. Shutemov
2016-02-13 11:58 ` Sebastian Ott
2016-02-15 11:31 ` Kirill A. Shutemov
2016-02-15 16:38 ` Sebastian Ott
2016-02-15 18:37 ` Gerald Schaefer
2016-02-15 21:35 ` Kirill A. Shutemov
2016-02-16 9:54 ` Sebastian Ott
2016-02-16 16:24 ` Gerald Schaefer
2016-02-17 15:04 ` Kirill A. Shutemov
2016-02-17 19:04 ` Sebastian Ott
2016-02-16 18:46 ` Christian Borntraeger
2016-02-17 19:13 ` Gerald Schaefer
2016-02-17 23:58 ` Kirill A. Shutemov
2016-02-18 15:00 ` Gerald Schaefer
2016-02-18 17:06 ` Kirill A. Shutemov
2016-02-19 14:15 ` Sebastian Ott
2016-02-15 16:41 ` Gerald Schaefer
2016-02-23 10:32 ` Kirill A. Shutemov
2016-02-23 17:46 ` Linus Torvalds
2016-02-23 18:19 ` Gerald Schaefer
2016-02-23 18:47 ` Will Deacon [this message]
2016-02-25 15:49 ` Steve Capper
2016-02-25 16:01 ` Kirill A. Shutemov
2016-02-25 16:08 ` Steve Capper
2016-02-23 19:33 ` Kirill A. Shutemov
2016-02-23 20:22 ` Will Deacon
2016-02-24 10:16 ` Christian Borntraeger
2016-02-24 10:41 ` Will Deacon
2016-02-24 10:51 ` Christian Borntraeger
2016-02-24 11:02 ` Will Deacon
2016-02-24 17:22 ` Aneesh Kumar K.V
2016-02-24 8:39 ` Martin Schwidefsky
2016-02-24 12:11 ` Sebastian Ott
2016-02-24 16:44 ` Gerald Schaefer
2016-02-24 8:22 ` Martin Schwidefsky
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=20160223184658.GA27281@arm.com \
--to=will.deacon@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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