All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sachin Sant <sachinp@in.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH] powerpc/mm: Fix potential access to freed pages when using hugetlbfs
Date: Wed, 17 Jun 2009 14:48:34 +0530	[thread overview]
Message-ID: <4A38B4EA.20507@in.ibm.com> (raw)
In-Reply-To: <20090616025419.A5581DDD1B@ozlabs.org>

Benjamin Herrenschmidt wrote:
> When using 64k page sizes, our PTE pages are split in two halves,
> the second half containing the "extension" used to keep track of
> individual 4k pages when not using HW 64k pages.
>
> However, our page tables used for hugetlb have a slightly different
> format and don't carry that "second half".
>
> Our code that batched PTEs to be invalidated unconditionally reads
> the "second half" (to put it into the batch), which means that when
> called to invalidate hugetlb PTEs, it will access unrelated memory.
>
> It breaks when CONFIG_DEBUG_PAGEALLOC is enabled.
>
> This fixes it by only accessing the second half when the _PAGE_COMBO
> bit is set in the first half, which indicates that we are dealing with
> a "combo" page which represents 16x4k subpages. Anything else shouldn't
> have this bit set and thus not require loading from the second half.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Thanks for the patch. The machine survived after two days of
testing with hugetlbfs tests.


Regards
-Sachin

-- 

---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------

  reply	other threads:[~2009-06-17  9:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-16  2:53 [PATCH] powerpc/mm: Fix potential access to freed pages when using hugetlbfs Benjamin Herrenschmidt
2009-06-17  9:18 ` Sachin Sant [this message]
2009-06-17 10:11   ` Benjamin Herrenschmidt

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=4A38B4EA.20507@in.ibm.com \
    --to=sachinp@in.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.