Messages in this thread | | | Date | Fri, 22 Apr 2022 16:26:19 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCHv4 3/8] efi/x86: Implement support for unaccepted memory |
| |
On Fri, Apr 22, 2022 at 11:30:11AM +0200, Borislav Petkov wrote: > On Fri, Apr 22, 2022 at 03:21:24AM +0300, Kirill A. Shutemov wrote: > > There's still #include <linux/efi.h> in misc.h. You removed one, but > > there's a second one for some reason. > > I don't know which tree you're looking at but latest tip/master has: > > $ git grep -E "efi\.h" arch/x86/boot/ > arch/x86/boot/compressed/acpi.c:6:#include "efi.h" > arch/x86/boot/compressed/kaslr.c:25:#include "efi.h" > arch/x86/boot/compressed/misc.h:40:#include "efi.h" > arch/x86/boot/compressed/pgtable_64.c:7:#include "efi.h"
Sorry for the noise. I read 'elf.h' as 'efi.h' :/
But it also includes <linux/bitmap.h> indirectly:
In file included from include/linux/elf.h:6: In file included from arch/x86/include/asm/elf.h:8: In file included from include/linux/thread_info.h:60: In file included from arch/x86/include/asm/thread_info.h:53: In file included from arch/x86/include/asm/cpufeature.h:5: In file included from arch/x86/include/asm/processor.h:22: In file included from arch/x86/include/asm/msr.h:11: In file included from arch/x86/include/asm/cpumask.h:5: In file included from include/linux/cpumask.h:12:
> > Any plans for <linux/acpi.h>? It includes <linux/bitmap.h>: > > So if misc.h is including linux/bitmap.h indirectly, you can simply > include misc.h right?
Yes.
> And then you'll slide under the closing door, as you say below. :)
Is it sarcasm or clearance to go?
> > I also underesitmated what is required to be copied because of the > > indirect include. The list was only to compile bitmap.c. mem.c (former > > unaccepted_memory.c) would require more. > > More like?
for_each_clear_bitrange() is pain to unwind.
> Maybe I can help out converting some of the stuff. You could push your > current state somewhere - even if it doesn't build - so that I can take > a look...
I will push what I have a bit later today.
> > BTW, do we have a white list of linux/ includes that allowed? minmax.h? > > math.h? What is the line. > > Well, that's the thing. Even if those look innocuous now, if they get > new includes added to them, that has an influence on the decompressor. > > So I'm thinking copying the required bits would be the proper way > forward.
I understand where you comes from. But on my side I face suddenly higher entry bar. Yes, it is bad excuse, I know.
> > Maybe allow what is included directly or indirectly now? (Yes, it is my > > poor attempt to slide under closing door.) > > That's basically saying, can I get this done so that I can mark my > checkbox that my task is done - you can deal with the crap later > yourself. > > How about we take our time and solve this properly instead of hurrying > constantly?
I'm okay with this. But I lack coherent understating on how you want it to look like.
Like, looking on your new "efi.h", I see it still implicitly depends on <linux/types.h> and <linux/uuid.h>. Why is it okay? Is it temporary? What is criteria of what is okay to keep for now?
You mentioned having <asm/shared/bitops.h> as we do <asm/shared/io.h>. But <asm/bitops.h> has non-trivial dependencies on its own.
Okay, we can move them into asm/shared as well, but how to deal with asm-generic/ things? And linux/ dependencies? Do we create a copy in x86/include?
-- Kirill A. Shutemov
| |