On Sun Dec 22, 2024 at 4:30 PM EET, Jarkko Sakkinen wrote:
The following failure was reported:
[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0
Above shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by mapping the region when needed instead of copying.
Cc: stable@vger.kernel.org # v2.6.16+ Fixes: 55a82ab3181b ("[PATCH] tpm: add bios measurement log") Reported-by: Andy Liang andy.liang@hpe.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219495 Suggested-by: Matthew Garrett mjg59@srcf.ucam.org Signed-off-by: Jarkko Sakkinen jarkko@kernel.org
As you can see from the bug comments clearly both v2 and v3 pass the tests in the failing hardware. I don't think it is really a problem for us to map 16 MB of address space, as that is zero cost of resources, even if there is only some dozens of kilobytes of data. Since ACPI does that it will never be available for general consumption anyway.
Also I've tested the following configurations in QEMU:
1. TPM2 FIFO (or TIS) 2. TPM2 CRB 3. TPM1 FIFO
95 insertions and 65 deletions is neither too bad figure, and as side-effect makes tpm1.c and tpm2.c pretty much chip independent.
James earlier suggestion to "fix" also OF and other stuff is purposely left out as we don't falling tree over there. They should continue to use devm_kmalloc() for the moment although in principle zero copy mapping is always better (but definitely notin the scope of bug fix).
BR, Jarkko