From: Matt Fleming <matt@console-pimps.org>
To: Josh Triplett <josh@joshtriplett.org>
Cc: Matt Fleming <matt.fleming@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, linux-efi@vger.kernel.org,
linux-kernel@vger.kernel.org,
Srihari Vijayaraghavan <linux.bug.reporting@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: [PATCH] efi-bgrt: Add error handling; inform the user when ignoring the BGRT
Date: Mon, 4 Aug 2014 13:19:59 +0100 [thread overview]
Message-ID: <20140804121959.GG15082@console-pimps.org> (raw)
In-Reply-To: <20140801161154.GA1258@thin>
On Fri, 01 Aug, at 09:11:54AM, Josh Triplett wrote:
>
> The original bug report was about an allocation failure for a fairly
> reasonable BGRT size. We can certainly prohibit absurdly huge ones (for
> instance, bigger than the maximum likely screen resolution times 4 bytes
> per pixel), but allocation failures may well occur for smaller sizes,
> and I don't think we want to spew a massive warning for that either.
Oh, dammit, that's my bad. I misread the allocation size and thought it
was huge, but now realise it was only 6MB or so. Sorry Josh.
I was worried that this was the first reported instance of a BGRT
claiming to be valid but with a bogusly large image size. I've never
been so happy to be wrong.
However, the fact that the allocation failed is worth investigating -
this machine appears to have GBs of ram. Perhaps we should switch to
requesting pages directly instead of relying on kmalloc()?
I appreciate that the BGRT code isn't mission critical or anything like
that, and that failing the alloc isn't the end of the world, but if we
have code in the kernel it should really be as robust as possible. I
don't think trying to kmalloc() ~6MB can claim to be robust.
--
Matt Fleming, Intel Open Source Technology Center
next prev parent reply other threads:[~2014-08-04 12:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-30 19:23 [PATCH] efi-bgrt: Add error handling; inform the user when ignoring the BGRT Josh Triplett
2014-07-30 19:23 ` Josh Triplett
2014-07-31 10:31 ` Matt Fleming
2014-07-31 10:31 ` Matt Fleming
2014-07-31 16:11 ` josh
2014-08-01 9:19 ` Matt Fleming
2014-08-01 9:19 ` Matt Fleming
[not found] ` <20140801091949.GD15082-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2014-08-01 16:11 ` Josh Triplett
2014-08-01 16:11 ` Josh Triplett
2014-08-04 12:19 ` Matt Fleming [this message]
[not found] ` <20140804121959.GG15082-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2014-08-05 16:39 ` Josh Triplett
2014-08-05 16:39 ` Josh Triplett
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=20140804121959.GG15082@console-pimps.org \
--to=matt@console-pimps.org \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=josh@joshtriplett.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux.bug.reporting@gmail.com \
--cc=matt.fleming@intel.com \
--cc=mingo@redhat.com \
--cc=mjg59@srcf.ucam.org \
--cc=tglx@linutronix.de \
--cc=x86@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 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.