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@xxxxxxxxxxxxxxx # v2.6.16+
> Fixes: 55a82ab3181b ("[PATCH] tpm: add bios measurement log")
> Reported-by: Andy Liang <andy.liang@xxxxxxx>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219495
> Suggested-by: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
> Signed-off-by: Jarkko Sakkinen <jarkko@xxxxxxxxxx>
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
