From: "Nish Aravamudan" <nish.aravamudan@gmail.com>
To: "Arjan van de Ven" <arjan@linux.intel.com>
Cc: mingo@elte.hu, torvalds@linux-foundation.org,
hans.rosenfeld@amd.com, linux-kernel@vger.kernel.org
Subject: Re: bisected boot regression post 2.6.25-rc3.. please revert
Date: Mon, 3 Mar 2008 09:15:22 -0800 [thread overview]
Message-ID: <29495f1d0803030915u19d99fc0nb4a706a9c8e85b59@mail.gmail.com> (raw)
In-Reply-To: <20080301105646.2c8620d9@laptopd505.fenrus.org>
On 3/1/08, Arjan van de Ven <arjan@linux.intel.com> wrote:
> Hi Linus, Ingo, Hans,
>
> Please revert commit cded932b75ab0a5f9181ee3da34a0a488d1a14fd
> ( x86: fix pmd_bad and pud_bad to support huge pages )
> since it prevents the kernel to finish booting on my (Penryn based)
> laptop. The boot stops right after freeing the init memory.
> Took a while to bisect (due to it touching page*.h, which forces a
> full recompile), but it definitely is caused by this commit...
>
> Please revert.
>
>
>
> [arjan@localhost linux.trees.git]$ git-bisect good
> cded932b75ab0a5f9181ee3da34a0a488d1a14fd is first bad commit
> commit cded932b75ab0a5f9181ee3da34a0a488d1a14fd
> Author: Hans Rosenfeld <hans.rosenfeld@amd.com>
> Date: Mon Feb 18 18:10:47 2008 +0100
>
> x86: fix pmd_bad and pud_bad to support huge pages
>
> I recently stumbled upon a problem in the support for huge pages. If a
> program using huge pages does not explicitly unmap them, they remain
> mapped (and therefore, are lost) after the program exits.
>
> I observed that the free huge page count in /proc/meminfo decreased when
> running my program, and it did not increase after the program exited.
> After running the program a few times, no more huge pages could be
> allocated.
>
> The reason for this seems to be that the x86 pmd_bad and pud_bad
> consider pmd/pud entries having the PSE bit set invalid. I think there
> is nothing wrong with this bit being set, it just indicates that the
> lowest level of translation has been reached. This bit has to be (and
> is) checked after the basic validity of the entry has been checked, like
> in this fragment from follow_page() in mm/memory.c:
>
> if (pmd_none(*pmd) || unlikely(pmd_bad(*pmd)))
> goto no_page_table;
>
> if (pmd_huge(*pmd)) {
> BUG_ON(flags & FOLL_GET);
> page = follow_huge_pmd(mm, address, pmd, flags & FOLL_WRITE);
> goto out;
> }
>
> Note that this code currently doesn't work as intended if the pmd refers
> to a huge page, the pmd_huge() check can not be reached if the page is
> huge.
>
> Extending pmd_bad() (and, for future 1GB page support, pud_bad()) to
> allow for the PSE bit being set fixes this. For similar reasons,
> allowing the NX bit being set is necessary, too. I have seen huge pages
> having the NX bit set in their pmd entry, which would cause the same
> problem.
>
> Signed-Off-By: Hans Rosenfeld <hans.rosenfeld@amd.com>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Hrm, not that I necessarily have the right to ask for this, but
shouldn't hugepage related patches at least be cc'd to linux-mm? it
seems this went via LKML to the x86 tree? There are a few of us that
work on hugepages that would have seen this there, but it got lost in
the noise (for me) on LKML.
Thanks,
Nish
prev parent reply other threads:[~2008-03-03 17:24 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-01 18:56 bisected boot regression post 2.6.25-rc3.. please revert Arjan van de Ven
2008-03-03 7:46 ` Ingo Molnar
2008-03-03 9:13 ` Ingo Molnar
2008-03-03 16:41 ` Arjan van de Ven
2008-03-03 17:40 ` Ingo Molnar
2008-03-03 17:51 ` Nish Aravamudan
2008-03-03 17:55 ` Ingo Molnar
2008-03-03 17:58 ` H. Peter Anvin
2008-03-03 18:36 ` Arjan van de Ven
2008-03-03 18:44 ` Linus Torvalds
2008-03-03 22:00 ` Arjan van de Ven
2008-03-04 1:05 ` Arjan van de Ven
2008-03-04 6:53 ` Ingo Molnar
2008-03-05 15:35 ` Arjan van de Ven
2008-03-09 11:56 ` Ingo Molnar
2008-03-09 17:27 ` Linus Torvalds
2008-03-09 18:57 ` Ingo Molnar
2008-03-10 2:45 ` Jeremy Fitzhardinge
2008-03-10 4:35 ` Paul Mackerras
2008-03-03 21:13 ` Segher Boessenkool
2008-03-03 21:22 ` Segher Boessenkool
2008-03-03 22:33 ` Segher Boessenkool
2008-03-03 22:55 ` H. Peter Anvin
2008-03-03 22:56 ` Jeremy Fitzhardinge
2008-03-03 23:04 ` H. Peter Anvin
2008-03-04 6:58 ` Ingo Molnar
2008-03-03 17:15 ` Nish Aravamudan [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=29495f1d0803030915u19d99fc0nb4a706a9c8e85b59@mail.gmail.com \
--to=nish.aravamudan@gmail.com \
--cc=arjan@linux.intel.com \
--cc=hans.rosenfeld@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).