On Mon Jan 6, 2025 at 7:23 PM EET, Ard Biesheuvel wrote: > On Wed, 25 Dec 2024 at 16:31, Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote: > > > > On Tue Dec 24, 2024 at 6:05 PM EET, Ard Biesheuvel wrote: > > > On Tue, 24 Dec 2024 at 05:03, Jarkko Sakkinen <jarkko@xxxxxxxxxx> 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. > > > > > > > > > > How can you be sure the memory contents will be preserved? Does it say > > > anywhere in the TCG spec that this needs to use a memory type that is > > > preserved by default? > > > > TCG log calls the size as the minimum size for the log area but is not > > too accurate on details [1]. I don't actually know what "minimum" even > > means in this context as it is just a fixed size cut of the physical > > address space. > > > > I don't think that can ever change. It would be oddballs if some > > dynamic change would make ACPI tables show incorrect information > > on memory ranges. Do you know any pre-existing example of such > > behavior (not sarcasm, just interested)? > > > > Anyway considering this type of dynamics TCG spec is inaccurate. > > > > Thanks for the context but that is not at all what I was asking. > > This change assumes that the contents of the memory region described > by the ACPI table will be reserved in some way, and not be released to > the kernel for general allocation. > > This is not always the case for firmware tables: EFI configuration > tables need to be reserved explicitly unless the memory type is > EfiRuntimeServicesData. For ACPI tables, the situation might be > different but there is at least one example (BGRT) where the memory > type typically used is not one that the kernel usually reserves by > default. > > So my question is whether there is anything in the TCG platform spec > (or whichever spec describes this ACPI table) that guarantees that the > region that the TCPA or TPM2 table points to is of a type that does > not require an explicit reservation? I agree that we must assume that we cannot guarantee taht since it is open in the spec. I think I went over the top with this. Let's go with the simpler devm_add_action_or_reset() fix. BR, Jarkko
