(Including akpm, the __GFP_NOWARN police) On Thu, 31 Jul, at 09:11:33AM, Josh Triplett wrote: > > I started to add an explicit limit, but any reasonable limit (large > enough for modern screens) would be large enough that there's still a > non-trivial possibility of allocation failure. And I think it makes > sense for BGRT image allocation to be non-fatal and minimally noisy > (just a single-line error, not a scary-looking allocation warning), > considering the highly optional and cosmetic nature of BGRT. So, I > believe __GFP_NOWARN makes sense. Yes, I agree that we don't want to trigger the page allocator warning, but I don't agree that passing __GFP_NOWARN is OK, which is why I'm advocating some size limit checks. We need to distinguish between "Your BGRT image size is huge, and assumed buggy" and "Your BGRT looks valid, but we ran out of memory". We've already got enough problems with the EFI code because we silently paper over bugs, and using the page allocator's failure path as a way to check for buggy BGRT images just doesn't make any sense to me at all. If we get the limit wrong, it's not the end of the world, we can change it later, but it's a safe bet that if the firmware engineers start seeing "BGRT is buggy" in the kernel log they're going to start a dialogue with us. Original patch, https://lkml.org/lkml/2014/7/30/543 -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
