From: Ingo Molnar <mingo@elte.hu>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: hpa@zytor.com, tglx@linutronix.de, linux-kernel@vger.kernel.org,
venkatesh.pallipadi@intel.com, Daniel.Beschorner@facton.com,
pageexec@freemail.hu, stable@kernel.org
Subject: Re: [patch] x86: fix PTE corruption issue while mapping RAM using /dev/mem
Date: Tue, 13 Jan 2009 00:51:35 +0100 [thread overview]
Message-ID: <20090112235135.GA22722@elte.hu> (raw)
In-Reply-To: <20090112203114.GA13157@linux-os.sc.intel.com>
* Suresh Siddha <suresh.b.siddha@intel.com> wrote:
> From: Suresh Siddha <suresh.b.siddha@intel.com>
> Subject: x86: fix PTE corruption issue while mapping RAM using /dev/mem
>
> Beschorner Daniel reported:
> > hwinfo problem since 2.6.28, showing this in the oops:
> > Corrupted page table at address 7fd04de3ec00
>
> PaX Team reported a regression with this commit:
>
> > commit 9542ada803198e6eba29d3289abb39ea82047b92
> > Author: Suresh Siddha <suresh.b.siddha@intel.com>
> > Date: Wed Sep 24 08:53:33 2008 -0700
> >
> > x86: track memtype for RAM in page struct
>
> This commit breaks mapping any RAM page through /dev/mem, as the
> reserve_memtype() was not initializing the return attribute type and as such
> corrupting the PTE entry that was setup with the return attribute type.
>
> Because of this bug, application mapping this RAM page through /dev/mem
> will die with "Corrupted page table at address xxxx" message in the kernel
> log and also the kernel identity mapping which maps the underlying RAM
> page gets converted to UC.
>
> Fix this by initializing the return attribute type before calling
> reserve_ram_pages_type()
>
> Reported-by: PaX Team <pageexec@freemail.hu>
> Reported-and-tested-by: Beschorner Daniel <Daniel.Beschorner@facton.com>
> Tested-and-Acked-by: PaX Team <pageexec@freemail.hu>
> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
> Cc: <stable@kernel.org>
> ---
applied to tip/x86/urgent, thanks Suresh!
note that the patch caused some conflicts (there were other changes in
pat.c) - i merged it up manually but could you please check the final
commit in tip/master whether it's all OK?
Ingo
next prev parent reply other threads:[~2009-01-12 23:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-12 20:31 [patch] x86: fix PTE corruption issue while mapping RAM using /dev/mem Suresh Siddha
2009-01-12 23:51 ` Ingo Molnar [this message]
2009-01-12 23:19 ` pageexec
2009-01-13 0:31 ` Ingo Molnar
2009-01-13 18:21 ` Suresh Siddha
2009-01-21 17:42 ` Ingo Molnar
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=20090112235135.GA22722@elte.hu \
--to=mingo@elte.hu \
--cc=Daniel.Beschorner@facton.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pageexec@freemail.hu \
--cc=stable@kernel.org \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=venkatesh.pallipadi@intel.com \
/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