On Tue, Feb 07, 2017 at 01:08:23PM -0600, Daniel Drake wrote:

The Intel Compute Stick STCK1A8LFC and Weibu F3C platforms both
log 2 error messages during boot:

   efi: requested map not found.
   esrt: ESRT header is not in the memory map.

Searching the web, this seems to affect many other platforms too.
Since these messages are logged as errors, they appear on-screen during
the boot process even when using the "quiet" boot parameter used by
distros.

Demote the ESRT error to a warning so that it does not appear on-screen,
and delete the error logging from efi_mem_desc_lookup; both callsites
of that function log more specific messages upon failure.

Out of curiosity I looked closer at the Weibu F3C. There is no entry in
the UEFI-provided memory map which corresponds to the ESRT pointer, but
hacking the code to map it anyway, the ESRT does appear to be valid with
2 entries.

The machine you've got does seem to be presenting a valid (if poorly
considered) table, but I don't quite think this is the right approach.
The first hunk of your patch is fine, but the test on the result of
efi_mem_desc_lookup() is more or less our check for "might reading this
table reboot the system or worse".  You're demoting it to a warning
while still /treating/ it as an error, so at least it remains safe,
but the when we get to that point, they've (plausibly) given us data
that could cause horrible behavior, and that is a thing worth logging an
error about.

It would be better to /check/ if it straddles multiple contiguous
segments which both have reasonable access modes and print an error if
there are gaps.  I'm still in favor of printing a warning to the log if
it straddles them and there /aren't/ gaps, because we're *going* to see
other weird bugs from any code base that decides it's stitching config
tables together from separate allocations.  It's not a fundamentally
reasonable thing to do, and as a lens it shows us some code with a
really worrisome internal structure.

-- 
        Peter