On Tue, Apr 19, 2022 at 09:39:53AM +0200, Borislav Petkov wrote: > On Tue, Apr 19, 2022 at 02:50:15AM +0300, Kirill A. Shutemov wrote: > > I find it strange that you go after <linux/bitmap.h> which has limited > > exposure while <linux/acpi.h> and <linux/efi.h> are there already. > > Funny you should mention that: > > https://lore.kernel.org/r/YlCKWhMJEMUgJmjF@xxxxxxx There's still #include <linux/efi.h> in misc.h. You removed one, but there's a second one for some reason. Any plans for <linux/acpi.h>? It includes <linux/bitmap.h>: In file included from ./include/linux/cpumask.h:12, from ./include/linux/smp.h:13, from ./include/linux/lockdep.h:14, from ./include/linux/mutex.h:17, from ./include/linux/kernfs.h:11, from ./include/linux/sysfs.h:16, from ./include/linux/kobject.h:20, from ./include/linux/of.h:17, from ./include/linux/irqdomain.h:35, from ./include/linux/acpi.h:13, from arch/x86/boot/compressed/misc.h:3 We will get name conflicts if we try to copy <linux/bitmap.h> stuff. Hm. 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. BTW, do we have a white list of linux/ includes that allowed? minmax.h? math.h? What is the line. Maybe allow what is included directly or indirectly now? (Yes, it is my poor attempt to slide under closing door.) -- Kirill A. Shutemov
