From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
linux-ia64@vger.kernel.org
Subject: Re: [patch 2/2] /dev/mem validate mmap requests
Date: Wed, 14 Dec 2005 15:48:56 +0000 [thread overview]
Message-ID: <200512140848.56570.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <B8E391BBE9FE384DAA4C5C003888BE6F0531E4BB@scsmsx401.amr.corp.intel.com>
On Tuesday 13 December 2005 5:25 pm, Luck, Tony wrote:
> > Tony, can you ack/nak this please? It touches both ia64 and generic
> > code.
>
> So if someone tries to mmap a range that spans across more than
> one EFI memory descriptor, the size will get trimmed back to an
> EFI memory boundary. Isn't that a problem since 1<<EFI_PAGE_SHIFT
> is less than the default ia64 Linux page size?
The EFI page size is smaller than the Linux page size, but firmware
typically coalesces adjacent ranges with the same attributes.
> I think you may need a more complex checker that does aggregation
> of adjacent efi memory descriptors with the same attributes.
We could, but I don't think it's worth it at this point. We've
been using the same simple-minded scheme for validating /dev/mem
read & write requests for quite a while with no problems, and I
don't want to over-engineer this.
If hot-plug memory is ever finished, the checker may have to
be extended to comprehend regions described by ACPI as well as
those described in the boot-time EFI memory map. I think that
would be the right time to make it smarter about spanning
descriptors.
next prev parent reply other threads:[~2005-12-14 15:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-13 23:56 [patch 2/2] /dev/mem validate mmap requests Bjorn Helgaas
2005-12-14 0:25 ` Luck, Tony
2005-12-14 15:48 ` Bjorn Helgaas [this message]
2005-12-15 22:06 ` Luck, Tony
2005-12-20 20:53 ` Bjorn Helgaas
2005-12-22 21:49 ` Bjorn Helgaas
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=200512140848.56570.bjorn.helgaas@hp.com \
--to=bjorn.helgaas@hp.com \
--cc=akpm@osdl.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@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