diff mbox series

modpost: check for static EXPORT_SYMBOL* functions

Message ID 20190728100906.18847-1-efremov@linux.com (mailing list archive)
State New, archived
Headers show
Series modpost: check for static EXPORT_SYMBOL* functions | expand

Commit Message

Denis Efremov (Oracle) July 28, 2019, 10:09 a.m. UTC
This patch adds a check to warn about static EXPORT_SYMBOL* functions
during the modpost. In most of the cases, a static symbol marked for
exporting is an odd combination that should be fixed either by deleting
the exporting mark or by removing the static attribute and adding the
appropriate declaration to headers.

This check could help to detect the following problems:
1. 550113d4e9f5 ("i2c: add newly exported functions to the header, too")
2. 54638c6eaf44 ("net: phy: make exported variables non-static")
3. 98ef2046f28b ("mm: remove the exporting of totalram_pages")
4. 73df167c819e ("s390/zcrypt: remove the exporting of ap_query_configuration")
5. a57caf8c527f ("sunrpc/cache: remove the exporting of cache_seq_next")
6. e4e4730698c9 ("crypto: skcipher - remove the exporting of skcipher_walk_next")
7. 14b4c48bb1ce ("gve: Remove the exporting of gve_probe")
8. 9b79ee9773a8 ("scsi: libsas: remove the exporting of sas_wait_eh")
9. ...

Build time impact, allmodconfig, Dell XPS 15 9570 (measurements 3x):
$ make mrproper; make allmodconfig; time make -j12; \
  git checkout HEAD~1; \
  make mrproper; make allmodconfig; time make -j12
1.
   (with patch) 17635,94s user 1895,54s system 1085% cpu 29:59,22 total
   (w/o  patch) 17275,42s user 1803,87s system 1112% cpu 28:35,66 total
2.
   (with patch) 17369,51s user 1763,28s system 1111% cpu 28:41,47 total
   (w/o  patch) 16880,50s user 1670,93s system 1113% cpu 27:46,56 total
3.
   (with patch) 17937,88s user 1842,53s system 1109% cpu 29:42,26 total
   (w/o  patch) 17267,55s user 1725,09s system 1111% cpu 28:28,17 total

Thus, the current implementation adds approx. 1 min for allmodconfig.

Acked-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
---
 scripts/mod/modpost.c | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

Comments

Masahiro Yamada July 29, 2019, 3:29 a.m. UTC | #1
On Sun, Jul 28, 2019 at 7:09 PM Denis Efremov <efremov@linux.com> wrote:
>
> This patch adds a check to warn about static EXPORT_SYMBOL* functions
> during the modpost. In most of the cases, a static symbol marked for
> exporting is an odd combination that should be fixed either by deleting
> the exporting mark or by removing the static attribute and adding the
> appropriate declaration to headers.
>
> This check could help to detect the following problems:
> 1. 550113d4e9f5 ("i2c: add newly exported functions to the header, too")
> 2. 54638c6eaf44 ("net: phy: make exported variables non-static")
> 3. 98ef2046f28b ("mm: remove the exporting of totalram_pages")
> 4. 73df167c819e ("s390/zcrypt: remove the exporting of ap_query_configuration")
> 5. a57caf8c527f ("sunrpc/cache: remove the exporting of cache_seq_next")
> 6. e4e4730698c9 ("crypto: skcipher - remove the exporting of skcipher_walk_next")
> 7. 14b4c48bb1ce ("gve: Remove the exporting of gve_probe")
> 8. 9b79ee9773a8 ("scsi: libsas: remove the exporting of sas_wait_eh")
> 9. ...
>
> Build time impact, allmodconfig, Dell XPS 15 9570 (measurements 3x):
> $ make mrproper; make allmodconfig; time make -j12; \
>   git checkout HEAD~1; \
>   make mrproper; make allmodconfig; time make -j12
> 1.
>    (with patch) 17635,94s user 1895,54s system 1085% cpu 29:59,22 total
>    (w/o  patch) 17275,42s user 1803,87s system 1112% cpu 28:35,66 total
> 2.
>    (with patch) 17369,51s user 1763,28s system 1111% cpu 28:41,47 total
>    (w/o  patch) 16880,50s user 1670,93s system 1113% cpu 27:46,56 total
> 3.
>    (with patch) 17937,88s user 1842,53s system 1109% cpu 29:42,26 total
>    (w/o  patch) 17267,55s user 1725,09s system 1111% cpu 28:28,17 total
>
> Thus, the current implementation adds approx. 1 min for allmodconfig.
>
> Acked-by: Emil Velikov <emil.l.velikov@gmail.com>
> Signed-off-by: Denis Efremov <efremov@linux.com>
> ---
>  scripts/mod/modpost.c | 32 ++++++++++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
>

>
> @@ -2425,6 +2443,7 @@ int main(int argc, char **argv)
>         char *dump_write = NULL, *files_source = NULL;
>         int opt;
>         int err;
> +       size_t n;

Sorry, I missed to ask this in the previous version.

If there is not a particular reason,
may I ask you to use 'int' instead of 'size_t' here?

SYMBOL_HASH_SIZE (= 1024) is small enough, and
it will keep consistency with
the write_dump() function in this file.

If it is tedious to send a new version,
may I fix-up 'size_t' -> 'int' ?

Thanks.


>         struct ext_sym_list *extsym_iter;
>         struct ext_sym_list *extsym_start = NULL;
>
> @@ -2520,6 +2539,19 @@ int main(int argc, char **argv)
>         if (sec_mismatch_count && sec_mismatch_fatal)
>                 fatal("modpost: Section mismatches detected.\n"
>                       "Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them.\n");
> +       for (n = 0; n < SYMBOL_HASH_SIZE; n++) {
> +               struct symbol *s = symbolhash[n];
> +
> +               while (s) {
> +                       if (s->is_static)
> +                               warn("\"%s\" [%s] is the static %s\n",
> +                                    s->name, s->module->name,
> +                                    export_str(s->export));
> +
> +                       s = s->next;
> +               }
> +       }
> +
>         free(buf.p);
>
>         return err;
> --
> 2.21.0
>
Stephen Rothwell July 29, 2019, 5:13 a.m. UTC | #2
Hi Denis,

On Sun, 28 Jul 2019 13:09:06 +0300 Denis Efremov <efremov@linux.com> wrote:
>
> Thus, the current implementation adds approx. 1 min for allmodconfig.

Just a reminder that some of us (just me?) do well over 100+ builds per
day ...  if this can be optimised some what that would be good.
Denis Efremov (Oracle) July 29, 2019, 9:16 a.m. UTC | #3
> Just a reminder that some of us (just me?) do well over 100+ builds per
> day ...  if this can be optimised some what that would be good.

These measurements for the worst case (allmodconfig). Is it possible to 
measure the slowdown in your case? How it will perform on your typical 
workflow?

Looks like it is possible to optimize it, but I need some hints from 
Masahiro on how to do it properly. Because I don't know how to match 
__ksymtab_<symbol> with the <symbol> without an additional loop. 
Introduce another hash table?

The first loop from this patch could traverse only the exported symbols 
instead of all symbols. But in this case, I don't know how to break 
early from the loop because there can be many symbols with the same name 
but with the different scope (static/non-static).

For example, ring_buffer_size:
kernel/trace/ring_buffer.c
4334:unsigned long ring_buffer_size(struct ring_buffer *buffer, int cpu)
4347:EXPORT_SYMBOL_GPL(ring_buffer_size);
And
drivers/usb/misc/ldusb.c
125:static int ring_buffer_size = 128;

Or for, nfs4_disable_idmapping:
fs/nfs/super.c
2920:bool nfs4_disable_idmapping = true;
2930:EXPORT_SYMBOL_GPL(nfs4_disable_idmapping);
fs/nfsd/nfs4idmap.c
48:static bool nfs4_disable_idmapping = true;

Regards,
Denis
Masahiro Yamada July 29, 2019, 9:32 a.m. UTC | #4
On Mon, Jul 29, 2019 at 6:16 PM Denis Efremov <efremov@linux.com> wrote:
>
> > Just a reminder that some of us (just me?) do well over 100+ builds per
> > day ...  if this can be optimised some what that would be good.
>
> These measurements for the worst case (allmodconfig). Is it possible to
> measure the slowdown in your case? How it will perform on your typical
> workflow?
>
> Looks like it is possible to optimize it, but I need some hints from
> Masahiro on how to do it properly. Because I don't know how to match
> __ksymtab_<symbol> with the <symbol> without an additional loop.

Right.
This is not feasible without an additional loop
since we put only exported symbols into the hash table.


Perhaps, we could put every symbol into the hash table
so that we can quickly look-up <symbol> from __ksymtab_<symbol>,
but it would consume lots of memory.

So, I think the implementation is this patch is good enough.


> Introduce another hash table?
>
> The first loop from this patch could traverse only the exported symbols
> instead of all symbols. But in this case, I don't know how to break
> early from the loop because there can be many symbols with the same name
> but with the different scope (static/non-static).
>
> For example, ring_buffer_size:
> kernel/trace/ring_buffer.c
> 4334:unsigned long ring_buffer_size(struct ring_buffer *buffer, int cpu)
> 4347:EXPORT_SYMBOL_GPL(ring_buffer_size);
> And
> drivers/usb/misc/ldusb.c
> 125:static int ring_buffer_size = 128;
>
> Or for, nfs4_disable_idmapping:
> fs/nfs/super.c
> 2920:bool nfs4_disable_idmapping = true;
> 2930:EXPORT_SYMBOL_GPL(nfs4_disable_idmapping);
> fs/nfsd/nfs4idmap.c
> 48:static bool nfs4_disable_idmapping = true;
Denis Efremov (Oracle) July 29, 2019, 9:51 a.m. UTC | #5
On 29.07.2019 06:29, Masahiro Yamada wrote:
> may I ask you to use 'int' instead of 'size_t' here?

Fixed in v2.

Regards,
Denis
Stephen Rothwell July 29, 2019, 12:40 p.m. UTC | #6
Hi Denis,

On Mon, 29 Jul 2019 12:16:29 +0300 Denis Efremov <efremov@linux.com> wrote:
>
> > Just a reminder that some of us (just me?) do well over 100+ builds per
> > day ...  if this can be optimised some what that would be good.  
> 
> These measurements for the worst case (allmodconfig). Is it possible to 
> measure the slowdown in your case? How it will perform on your typical 
> workflow?

I did 3 x86_64 allmodconfig builds without and with the patch (I do
-j 80 powerpc64 le hosted cross builds) and it doesn't look like the
patch has much impact at all.

Without the patch:

real	8m41.390s user	587m25.249s sys	22m0.411s
real	8m40.100s user	587m32.148s sys	21m58.419s
real	8m40.084s user	587m25.311s sys	22m2.794s

With the patch:

real	8m40.351s user	587m21.819s sys	21m57.389s
real	8m40.868s user	587m23.730s sys	21m58.737s
real	8m40.970s user	587m22.525s sys	22m2.467s

I do other builds as well, but that is the biggest, so actually looks
ok.
Denis Efremov (Oracle) July 29, 2019, 12:52 p.m. UTC | #7
On 7/29/19 3:40 PM, Stephen Rothwell wrote:
> Hi Denis,
> 
> On Mon, 29 Jul 2019 12:16:29 +0300 Denis Efremov <efremov@linux.com> wrote:
>>
>>> Just a reminder that some of us (just me?) do well over 100+ builds per
>>> day ...  if this can be optimised some what that would be good.  
>>
>> These measurements for the worst case (allmodconfig). Is it possible to 
>> measure the slowdown in your case? How it will perform on your typical 
>> workflow?
> 
> I did 3 x86_64 allmodconfig builds without and with the patch (I do
> -j 80 powerpc64 le hosted cross builds) and it doesn't look like the
> patch has much impact at all.
> 
> Without the patch:
> 
> real	8m41.390s user	587m25.249s sys	22m0.411s
> real	8m40.100s user	587m32.148s sys	21m58.419s
> real	8m40.084s user	587m25.311s sys	22m2.794s
> 
> With the patch:
> 
> real	8m40.351s user	587m21.819s sys	21m57.389s
> real	8m40.868s user	587m23.730s sys	21m58.737s
> real	8m40.970s user	587m22.525s sys	22m2.467s
> 
> I do other builds as well, but that is the biggest, so actually looks
> ok.
> 

Is it worth to include your measurements instead of mine in the commit
description? Maybe the note about performance downgrade could be omitted
at all in this case?

Denis
Stephen Rothwell July 29, 2019, 1:07 p.m. UTC | #8
Hi Denis,

On Mon, 29 Jul 2019 15:52:15 +0300 Denis Efremov <efremov@linux.com> wrote:
>
> Is it worth to include your measurements instead of mine in the commit
> description? Maybe the note about performance downgrade could be omitted
> at all in this case?

Just leave your measurements (they are yours after all), but maybe say
"less than a minute" rather than "approx. 1 min".
diff mbox series

Patch

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index f277e116e0eb..85e885235c96 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -169,6 +169,7 @@  struct symbol {
 	unsigned int kernel:1;     /* 1 if symbol is from kernel
 				    *  (only for external modules) **/
 	unsigned int preloaded:1;  /* 1 if symbol from Module.symvers, or crc */
+	unsigned int is_static:1;  /* 1 if symbol is not global */
 	enum export  export;       /* Type of export */
 	char name[0];
 };
@@ -201,6 +202,7 @@  static struct symbol *alloc_symbol(const char *name, unsigned int weak,
 	strcpy(s->name, name);
 	s->weak = weak;
 	s->next = next;
+	s->is_static = 1;
 	return s;
 }
 
@@ -1980,6 +1982,22 @@  static void read_symbols(const char *modname)
 		handle_modversions(mod, &info, sym, symname);
 		handle_moddevtable(mod, &info, sym, symname);
 	}
+
+	// check for static EXPORT_SYMBOL_* functions && global vars
+	for (sym = info.symtab_start; sym < info.symtab_stop; sym++) {
+		unsigned char bind = ELF_ST_BIND(sym->st_info);
+		unsigned char type = ELF_ST_TYPE(sym->st_info);
+
+		if (type == STT_OBJECT || type == STT_FUNC) {
+			struct symbol *s =
+				find_symbol(remove_dot(info.strtab +
+						       sym->st_name));
+
+			if (s && (bind == STB_GLOBAL || bind == STB_WEAK))
+				s->is_static = 0;
+		}
+	}
+
 	if (!is_vmlinux(modname) || vmlinux_section_warnings)
 		check_sec_ref(mod, modname, &info);
 
@@ -2425,6 +2443,7 @@  int main(int argc, char **argv)
 	char *dump_write = NULL, *files_source = NULL;
 	int opt;
 	int err;
+	size_t n;
 	struct ext_sym_list *extsym_iter;
 	struct ext_sym_list *extsym_start = NULL;
 
@@ -2520,6 +2539,19 @@  int main(int argc, char **argv)
 	if (sec_mismatch_count && sec_mismatch_fatal)
 		fatal("modpost: Section mismatches detected.\n"
 		      "Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them.\n");
+	for (n = 0; n < SYMBOL_HASH_SIZE; n++) {
+		struct symbol *s = symbolhash[n];
+
+		while (s) {
+			if (s->is_static)
+				warn("\"%s\" [%s] is the static %s\n",
+				     s->name, s->module->name,
+				     export_str(s->export));
+
+			s = s->next;
+		}
+	}
+
 	free(buf.p);
 
 	return err;