https://bugzilla.kernel.org/show_bug.cgi?id=219495 Matthew Garrett (mjg59-kernel@xxxxxxxxxxxxx) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mjg59-kernel@xxxxxxxxxxxxx --- Comment #32 from Matthew Garrett (mjg59-kernel@xxxxxxxxxxxxx) --- The spec doesn't define any maximum size for the buffer, so while this is ludicrous it's not inherently a bug in the firmware - what the firmware is communicating to us is that it's allocated at least that much space, and if we were still logging events in the firmware environment we could do so until we hit that limit. I believe that Stefan's figures are for the calculated size of the log rather than for the table's buffer size. An alternative approach to allocating the LAML would be to map the log area, use the code we already have for calculating how long the log *actually* is, and then only allocating that, which would be more computationally intensive but would probably save RAM? Alternatively, check whether the LAML is above some arbitrary size, throw a BIOS_BUG, and just copy that much. This would work fine in this scenario (where the log is much less than the LAML value) -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
