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] [day] [month] [year] [list]
Date:   Mon, 22 Apr 2019 21:53:01 -0700 (PDT)
From:   David Miller <>
Subject: Re: [PATCH -next 0/7] clean up needless use of module

From: Paul Gortmaker <>
Date: Sat, 20 Apr 2019 23:29:41 -0400

> People can embed modular includes and modular exit functions into code
> that never use any of it, and they won't get any errors or warnings.
> Using modular infrastructure in non-modules might seem harmless, but some
> of the downfalls this leads to are:
>  (1) it is easy to accidentally write unused module_exit removal code
>  (2) it can be misleading when reading the source, thinking a driver can
>      be modular when the Makefile and/or Kconfig prohibit it
>  (3) an unused include of the module.h header file will in turn
>      include nearly everything else; adding a lot to CPP overhead.
>  (4) it gets copied/replicated into other drivers and spreads quickly.
> As a data point for #3 above, an empty C file that just includes the
> module.h header generates over 750kB of CPP output.  Repeating the same
> experiment with init.h and the result is less than 12kB; with export.h
> it is only about 1/2kB; with both it still is less than 12kB.  One driver
> in this series gets the module.h ---> init.h+export.h conversion.
> Worse, are headers in include/linux that in turn include <linux/module.h>
> as they can impact a whole fleet of drivers, or a whole subsystem, so
> special care should be used in order to avoid that.  Such headers should
> only include what they need to be stand-alone; they should not be trying
> to anticipate the various header needs of their possible end users.
> In this series, four include/linux headers have module.h removed from
> them because they don't strictly need it.  Then three chunks of net
> related code have modular infrastructure that isn't used, removed.
> There are no runtime changes, so the biggest risk is a genuine consumer
> of module.h content relying on implicitly getting it from one of the
> include/linux instances removed here - thus resulting in a build fail.
> With that in mind, allmodconfig build testing was done on x86-64, arm64,
> x86-32, arm. powerpc, and mips on linux-next (and hence net-next).

Series applied, thanks Paul.

Powered by blists - more mailing lists