linux-kernel - Re: [GIT PULL 1/4] Kbuild updates for v4.21

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=whg49nn5q_2QVMGN0u4rQFBmRKywtqJUSk+5=rBzTk1kg@mail.gmail.com>
Date:   Sat, 5 Jan 2019 10:35:23 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        masahiroy@...nel.org
Subject: Re: [GIT PULL 1/4] Kbuild updates for v4.21

Masahiro,
 this isn't really related to the your request, but to just another
pull request that caused much more of a rebuild than I expected.

Doing a "make --debug", I see that the cause was that it touched
include/uapi/linux/elf-em.h, and make says things like

     Prerequisite 'include/uapi/linux/elf-em.h' is newer than target
'drivers/net/ethernet/sfc/falcon/efx.o'.
    Must remake target 'drivers/net/ethernet/sfc/falcon/efx.o'.

which is obviously true, but was unexpected.

The chain seems to be

  <linux/module.h> ->
    <linux/elf.h> ->
      <uapi/linux/elf.h> ->
        <linux/elf-em.h>

or similar, and the reason <linux/module.h> does that is it wants some
of the elf types (ie code like this:

struct mod_kallsyms {
        Elf_Sym *symtab;
        unsigned int num_symtab;
        char *strtab;
};

and for declarations of module_bug_finalize() etc.

Fine, fine. I can see why everybody includes <linux/module.h>, and I
can see why module.h in turn wants the elf information.

And I think I can see a way to avoid this chain, particularly with
lots of those things really being internal to kernel/module.h and
shouldn't be visible to random <linux/module.h> users.

But the reason for this email to you is simply to ask whether you
use/have any tools for seeing these kinds of deep include chains.
Getting rid of some of the deep chains of header includes would likely
speed up kernel builds even when a rebuild is forced, and when it's
something like "we really shouldn't have rebuilt that file at all" the
speedup is obviously even bigger than just a "the compiler saw much
too much unnecessary header contents".

                 Linus