From: Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
To: Matt Fleming <matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Jan Beulich <JBeulich-IBi9RG/b67k@public.gmane.org>,
Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
linux-efi <linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v2] fix setup_efi_pci()
Date: Fri, 25 Jan 2013 15:25:38 +0000 [thread overview]
Message-ID: <20130125152538.GA30685@srcf.ucam.org> (raw)
In-Reply-To: <1359103537.2496.132.camel-ZqTwcBeJ+wsBof6jY8KHXm7IUlhRatedral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On Fri, Jan 25, 2013 at 08:45:37AM +0000, Matt Fleming wrote:
> Matthew, what guarantees do we have that the memory we've allocated for
> the PCI ROMs isn't going to be reused? I suspect what's needed is for
> parse_setup_data() to reserve the SETUP_PCI regions, just like you would
> for any other key data structure.
Yeah, I think that originally I had a copy and then failed to update
this to handle just re-using the original allocation.
> It's the kernel's responsibility to protect any EFI_LOADER_DATA regions
> that it needs, we shouldn't have to trick ourselves by using the
> EFI_RUNTIME_SERVICES_DATA pool for allocations.
I guess the concern is that non-EFI systems may end up passing
SETUP_PCI? EFI_RUNTIME_DATA would solve one case without handling that,
so doing it in the data parsing code probably does make sense.
--
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org
next prev parent reply other threads:[~2013-01-25 15:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-18 12:35 [PATCH v2] fix setup_efi_pci() Jan Beulich
[not found] ` <50F94F9202000078000B74EE-ce6RLXgGx+vWGUEhTRrCg1aTQe2KTcn/@public.gmane.org>
2013-01-24 18:20 ` Matt Fleming
[not found] ` <1359051621.2496.95.camel-ZqTwcBeJ+wsBof6jY8KHXm7IUlhRatedral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2013-01-25 7:41 ` Jan Beulich
[not found] ` <5102452202000078000B9755-ce6RLXgGx+vWGUEhTRrCg1aTQe2KTcn/@public.gmane.org>
2013-01-25 8:45 ` Matt Fleming
[not found] ` <1359103537.2496.132.camel-ZqTwcBeJ+wsBof6jY8KHXm7IUlhRatedral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2013-01-25 11:04 ` Matt Fleming
2013-01-25 15:25 ` Matthew Garrett [this message]
2013-01-25 15:32 ` David Woodhouse
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=20130125152538.GA30685@srcf.ucam.org \
--to=mjg59-1xo5oi07kqx4cg9nei1l7q@public.gmane.org \
--cc=JBeulich-IBi9RG/b67k@public.gmane.org \
--cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.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.