From: Andi Kleen <ak@suse.de>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
Matt_Domsch@dell.com, hostmaster@ed-soft.at,
Bjorn Helgaas <bjorn.helgaas@hp.com>
Subject: Re: [PATCH 1/1] EFI iounpam fix for acpi_os_unmap_memory
Date: Tue, 21 Feb 2006 22:09:06 +0100 [thread overview]
Message-ID: <200602212209.07586.ak@suse.de> (raw)
In-Reply-To: <20060221125919.5085de5f.akpm@osdl.org>
On Tuesday 21 February 2006 21:59, Andrew Morton wrote:
> Andi Kleen <ak@suse.de> wrote:
> >
> > Andrew Morton <akpm@osdl.org> writes:
> >
> > >
> > > void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
> > > {
> > > + /* Don't unmap memory which was not mapped by acpi_os_map_memory */
> > > + if (efi_enabled &&
> > > + (efi_mem_attributes(virt_to_phys(virt)) & EFI_MEMORY_WB))
> > > + return;
> >
> >
> > The patch is wrong because if the address came from ioremap
> > virt_to_phys doesn't give the real physical address. Also looking
> > at acpi_os_map_memory it doesn't quite match the logic there.
> >
> > One working way to check for ioremap memory is
> > virt >= VMALLOC_START && virt < VMALLOC_END
> >
>
> OK, thanks. I don't think we actually know who is trying to unmap some
> memory which acpi didn't map.
>
> Edgar, can you please describe the bug which you're trying to fix?
I think the bug is clear - the logic in acpi_os_unmap_memory needs to match
what acpi_os_map_memory() does for EFI. In particular this means not calling
iounmap.
He probably has a EFI system where this caused troubles.
But think even acpi_os_miap_memory is broken - I doubt the efi_mem_attributes
thing guarantees that the memory is mapped. I guess this was added for
IA64 because ioremap used to return uncached memory there and IA64 doesn't
like this for memory accesses or something like that.
But Bjorn afaik recently fixed this by making ioremap handle it. So the right
fix probably would be to just drop all the efi_enabled gunk in acpi_os_map_memory
and just always use ioremap()
Also removed this ptr > ULONG_MAX check. Obvious it can never trigger.
<untested patch follows>
Signed-off-by: Andi Kleen <ak@suse.de>
Index: linux/drivers/acpi/osl.c
===================================================================
--- linux.orig/drivers/acpi/osl.c
+++ linux/drivers/acpi/osl.c
@@ -182,23 +182,10 @@ acpi_status
acpi_os_map_memory(acpi_physical_address phys, acpi_size size,
void __iomem ** virt)
{
- if (efi_enabled) {
- if (EFI_MEMORY_WB & efi_mem_attributes(phys)) {
- *virt = (void __iomem *)phys_to_virt(phys);
- } else {
- *virt = ioremap(phys, size);
- }
- } else {
- if (phys > ULONG_MAX) {
- printk(KERN_ERR PREFIX "Cannot map memory that high\n");
- return AE_BAD_PARAMETER;
- }
- /*
- * ioremap checks to ensure this is in reserved space
- */
- *virt = ioremap((unsigned long)phys, size);
- }
-
+ /*
+ * ioremap checks to ensure this is in reserved space
+ */
+ *virt = ioremap((unsigned long)phys, size);
if (!*virt)
return AE_NO_MEMORY;
>
next prev parent reply other threads:[~2006-02-21 21:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-20 23:36 [PATCH 1/1] EFI iounpam fix for acpi_os_unmap_memory Edgar Hucek
2006-02-21 6:02 ` Andrew Morton
2006-02-21 14:15 ` Andi Kleen
2006-02-21 20:59 ` Andrew Morton
2006-02-21 21:09 ` Andi Kleen [this message]
2006-02-22 6:50 ` Stelian Pop
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=200602212209.07586.ak@suse.de \
--to=ak@suse.de \
--cc=Matt_Domsch@dell.com \
--cc=akpm@osdl.org \
--cc=bjorn.helgaas@hp.com \
--cc=hostmaster@ed-soft.at \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@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