* Ard Biesheuvel <[email protected]> wrote:
> On 14 May 2018 at 09:50, tip-bot for Hans de Goede <[email protected]> wrote: > > Commit-ID: 1de3a1be8a9345fd0c7d9bb1009b21afe6b6b10f > > Gitweb: > > https://git.kernel.org/tip/1de3a1be8a9345fd0c7d9bb1009b21afe6b6b10f > > Author: Hans de Goede <[email protected]> > > AuthorDate: Fri, 4 May 2018 08:00:01 +0200 > > Committer: Ingo Molnar <[email protected]> > > CommitDate: Mon, 14 May 2018 08:57:49 +0200 > > > > efi/x86: Ignore unrealistically large option ROMs > > > > setup_efi_pci() tries to save a copy of each PCI option ROM as this may > > be necessary for the device driver for the PCI device to have access too. > > > > On some systems the efi_pci_io_protocol's romimage and romsize fields > > contain invalid data, which looks a bit like pointers pointing back into > > other EFI code or data. Interpreting these pointers as romsize leads to > > a very large value and if we then try to alloc this amount of memory to > > save a copy the alloc call fails. > > > > This leads to a "Failed to alloc mem for rom" error being printed on the > > EFI console for each PCI device. > > > > This commit avoids the printing of these errors, by checking romsize before > > doing the alloc and if it is larger then the EFI spec limit of 16 MiB > > silently ignore the ROM fields instead of trying to alloc mem and fail. > > > > Tested-by: Hans de Goede <[email protected]> > > [ardb: deduplicate 32/64 bit changes, use SZ_16M symbolic constant] > > Signed-off-by: Hans de Goede <[email protected]> > > Signed-off-by: Ard Biesheuvel <[email protected]> > > This looks odd now: I sent this out as > > Signed-off-by: Hans de Goede <[email protected]> > [ardb: deduplicate 32/64 bit changes, use SZ_16M symbolic constant] > Tested-by: Hans de Goede <[email protected]> > Signed-off-by: Ard Biesheuvel <[email protected]> > > which clearly conveys that Hans tested the updated version of the patch. > > In general, I don't think there is a need to reorder signoffs unless > there is anything wrong with them, no? Indeed - this is a script bug that I failed to notice. Thanks, Ingo
