On Fri, 10 Jan 2025 at 19:18, Dave Young <dyoung@xxxxxxxxxx> wrote: > > On Fri, 10 Jan 2025 at 19:12, Usama Arif <usamaarif642@xxxxxxxxx> wrote: > > > > > > > > On 10/01/2025 02:50, Dave Young wrote: > > > Hi Usama, > > > > > > On Thu, 9 Jan 2025 at 06:00, Usama Arif <usamaarif642@xxxxxxxxx> wrote: > > >> > > >> When this area is not reserved, it comes up as usable in > > >> /sys/firmware/memmap. This means that kexec, which uses that memmap > > >> to find usable memory regions, can select the region where > > >> efi_mem_attr_table is and overwrite it and relocate_kernel. > > > > > > Is the attr table BOOT SERVICE DATA? If so, does efi_mem_reserve() > > > work for you? > > > Just refer to esrt.c. > > > > > > > Hi Dave, > > > > Its a bit difficult to reproduce the problem and therefore test the fix, but > > we are seeing it a lot in production. Ard proposed the same thing in > > https://lore.kernel.org/all/6b4780a5-ada0-405e-9f0a-4d2186177f29@xxxxxxxxx/ > > but as I mentioned there, I dont think that efi_mem_reserve would help, > > as efi_mem_reserve changes e820_table, while kexec looks at > > /sys/firmware/memmap which uses e820_table_firmware. > > I sent a question to pm people, if the sysfs memmap comes from > e820_table then it will be fine. Let's see: s/e820_table/e820_table_kexec > https://lore.kernel.org/all/CALu+AoS-nk4u=9UYP7BLS=diOxjJRf+vfv7KHXG=uXozoYazsw@xxxxxxxxxxxxxx/ > > > > > Thanks, > > Usama > > > > > Thanks > > > Dave > > > > >
