netdev - Re: [PATCH -next 0/7] clean up needless use of module infrastructure

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] [day] [month] [year] [list]

Message-Id: <20190422.215301.1058694136014998838.davem@davemloft.net>
Date:   Mon, 22 Apr 2019 21:53:01 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     paul.gortmaker@...driver.com
Cc:     netdev@...r.kernel.org, ast@...nel.org, kuznet@....inr.ac.ru,
        xiyou.wangcong@...il.com, daniel@...earbox.net,
        daniel.wagner@...-carit.de, yoshfuji@...ux-ipv6.org,
        jhs@...atatu.com, jiri@...nulli.us, kafai@...com,
        rami.rosen@...el.com, songliubraving@...com, tj@...nel.org,
        yhs@...com, yotam.gi@...il.com
Subject: Re: [PATCH -next 0/7] clean up needless use of module
 infrastructure

From: Paul Gortmaker <paul.gortmaker@...driver.com>
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.