[RFC][PATCH] fail kernel compilation in case of unresolved symbols

[RFC][PATCH] fail kernel compilation in case of unresolved symbols

[Kirill Korotaev]

[-- Attachment #1: Type: text/plain, Size: 2301 bytes --]

At stage 2 modpost utility is used to check modules.
In case of unresolved symbols modpost only prints warning.

IMHO it is a good idea to fail compilation process in case of
unresolved symbols, since usually such errors are left unnoticed,
but kernel modules are broken.

Signed-Off-By: Andrey Mirkin <amirkin@sw.ru>
Signed-Off-By: Kirill Korotaev <dev@openvz.org>


diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index dfde0e8..81cbf95 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1187,16 +1187,19 @@ static void add_header(struct buffer *b,
 /**
  * Record CRCs for unresolved symbols
  **/
-static void add_versions(struct buffer *b, struct module *mod)
+static int add_versions(struct buffer *b, struct module *mod)
 {
 	struct symbol *s, *exp;
+	int err = 0;
 
 	for (s = mod->unres; s; s = s->next) {
 		exp = find_symbol(s->name);
 		if (!exp || exp->module == mod) {
-			if (have_vmlinux && !s->weak)
+			if (have_vmlinux && !s->weak) {
 				warn("\"%s\" [%s.ko] undefined!\n",
 				     s->name, mod->name);
+				err = 1;
+			}
 			continue;
 		}
 		s->module = exp->module;
@@ -1205,7 +1208,7 @@ static void add_versions(struct buffer *
 	}
 
 	if (!modversions)
-		return;
+		return err;
 
 	buf_printf(b, "\n");
 	buf_printf(b, "static const struct modversion_info ____versions[]\n");
@@ -1225,6 +1228,8 @@ static void add_versions(struct buffer *
 	}
 
 	buf_printf(b, "};\n");
+
+	return err;
 }
 
 static void add_depends(struct buffer *b, struct module *mod,
@@ -1402,6 +1407,7 @@ int main(int argc, char **argv)
 	char *kernel_read = NULL, *module_read = NULL;
 	char *dump_write = NULL;
 	int opt;
+	int err;
 
 	while ((opt = getopt(argc, argv, "i:I:mo:a")) != -1) {
 		switch(opt) {
@@ -1441,6 +1447,8 @@ int main(int argc, char **argv)
 		check_exports(mod);
 	}
 
+	err = 0;
+
 	for (mod = modules; mod; mod = mod->next) {
 		if (mod->skip)
 			continue;
@@ -1448,7 +1456,7 @@ int main(int argc, char **argv)
 		buf.pos = 0;
 
 		add_header(&buf, mod);
-		add_versions(&buf, mod);
+		err |= add_versions(&buf, mod);
 		add_depends(&buf, mod, modules);
 		add_moddevtable(&buf, mod);
 		add_srcversion(&buf, mod);
@@ -1460,5 +1468,5 @@ int main(int argc, char **argv)
 	if (dump_write)
 		write_dump(dump_write);
 
-	return 0;
+	return err;
 }


[-- Attachment #2: diff-modpost-undefined-symbols-20060905 --]
[-- Type: text/plain, Size: 1933 bytes --]

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index dfde0e8..81cbf95 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1187,16 +1187,19 @@ static void add_header(struct buffer *b,
 /**
  * Record CRCs for unresolved symbols
  **/
-static void add_versions(struct buffer *b, struct module *mod)
+static int add_versions(struct buffer *b, struct module *mod)
 {
 	struct symbol *s, *exp;
+	int err = 0;
 
 	for (s = mod->unres; s; s = s->next) {
 		exp = find_symbol(s->name);
 		if (!exp || exp->module == mod) {
-			if (have_vmlinux && !s->weak)
+			if (have_vmlinux && !s->weak) {
 				warn("\"%s\" [%s.ko] undefined!\n",
 				     s->name, mod->name);
+				err = 1;
+			}
 			continue;
 		}
 		s->module = exp->module;
@@ -1205,7 +1208,7 @@ static void add_versions(struct buffer *
 	}
 
 	if (!modversions)
-		return;
+		return err;
 
 	buf_printf(b, "\n");
 	buf_printf(b, "static const struct modversion_info ____versions[]\n");
@@ -1225,6 +1228,8 @@ static void add_versions(struct buffer *
 	}
 
 	buf_printf(b, "};\n");
+
+	return err;
 }
 
 static void add_depends(struct buffer *b, struct module *mod,
@@ -1402,6 +1407,7 @@ int main(int argc, char **argv)
 	char *kernel_read = NULL, *module_read = NULL;
 	char *dump_write = NULL;
 	int opt;
+	int err;
 
 	while ((opt = getopt(argc, argv, "i:I:mo:a")) != -1) {
 		switch(opt) {
@@ -1441,6 +1447,8 @@ int main(int argc, char **argv)
 		check_exports(mod);
 	}
 
+	err = 0;
+
 	for (mod = modules; mod; mod = mod->next) {
 		if (mod->skip)
 			continue;
@@ -1448,7 +1456,7 @@ int main(int argc, char **argv)
 		buf.pos = 0;
 
 		add_header(&buf, mod);
-		add_versions(&buf, mod);
+		err |= add_versions(&buf, mod);
 		add_depends(&buf, mod, modules);
 		add_moddevtable(&buf, mod);
 		add_srcversion(&buf, mod);
@@ -1460,5 +1468,5 @@ int main(int argc, char **argv)
 	if (dump_write)
 		write_dump(dump_write);
 
-	return 0;
+	return err;
 }

Re: [RFC][PATCH] fail kernel compilation in case of unresolved symbols

[Mikael Pettersson]

Kirill Korotaev writes:
 > At stage 2 modpost utility is used to check modules.
 > In case of unresolved symbols modpost only prints warning.
 > 
 > IMHO it is a good idea to fail compilation process in case of
 > unresolved symbols, since usually such errors are left unnoticed,
 > but kernel modules are broken.

Total disagree. A big warning is appropriate, but failure
is unnecessary and harmful.

Consider a big modular config, which has loads of modules
I'll never need or use. Even if $random_module has an
unresolved symbol, the kernel+modules will still work with
a fairly high degree of probability, allowing me to test
other things even though $random_module is (temporarily)
broken.

Your suggestion would either force me to reconfigure to
avoid the broken module (allowing me to forget about it),
or it would prevent me from testing that kernel at all
until I or someone else fixed the $random_module breakage.
Either way, testing suffers.

Re: [RFC][PATCH] fail kernel compilation in case of unresolved symbols

[Sam Ravnborg]

On Tue, Sep 05, 2006 at 05:47:25PM +0400, Kirill Korotaev wrote:
> At stage 2 modpost utility is used to check modules.
> In case of unresolved symbols modpost only prints warning.
> 
> IMHO it is a good idea to fail compilation process in case of
> unresolved symbols, since usually such errors are left unnoticed,
> but kernel modules are broken.

The primary reason why we do not fail in this case is that building
external modules often result in unresolved symbols at modpost time.

And there is many legitime uses of external modules that we shall support.

	Sam

Re: [RFC][PATCH] fail kernel compilation in case of unresolved symbols

[Adrian Bunk]

On Tue, Sep 05, 2006 at 05:31:59PM +0200, Sam Ravnborg wrote:
> On Tue, Sep 05, 2006 at 05:47:25PM +0400, Kirill Korotaev wrote:
> > At stage 2 modpost utility is used to check modules.
> > In case of unresolved symbols modpost only prints warning.
> > 
> > IMHO it is a good idea to fail compilation process in case of
> > unresolved symbols, since usually such errors are left unnoticed,
> > but kernel modules are broken.
> 
> The primary reason why we do not fail in this case is that building
> external modules often result in unresolved symbols at modpost time.
> 
> And there is many legitime uses of external modules that we shall support.

Is there a way we can get this only for building the kernel itself?
In this case an unresolved symbol is a real bug that should cause an 
abort of the compilation.

I'm often doing compile tests for the kernel, and the current warnings 
are too easy to miss.

> 	Sam

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [RFC][PATCH] fail kernel compilation in case of unresolved symbols

[Kirill Korotaev]

Sam Ravnborg wrote:
> On Tue, Sep 05, 2006 at 05:47:25PM +0400, Kirill Korotaev wrote:
> 
>>At stage 2 modpost utility is used to check modules.
>>In case of unresolved symbols modpost only prints warning.
>>
>>IMHO it is a good idea to fail compilation process in case of
>>unresolved symbols, since usually such errors are left unnoticed,
>>but kernel modules are broken.
> 
> 
> The primary reason why we do not fail in this case is that building
> external modules often result in unresolved symbols at modpost time.
> 
> And there is many legitime uses of external modules that we shall support.
ok. is it ok for you to introduce new Make target 'modules_check'?

Thanks,
Kirill

Re: [RFC][PATCH] fail kernel compilation in case of unresolved symbols

[Kirill Korotaev]

Adrian Bunk wrote:
> On Tue, Sep 05, 2006 at 05:31:59PM +0200, Sam Ravnborg wrote:
> 
>>On Tue, Sep 05, 2006 at 05:47:25PM +0400, Kirill Korotaev wrote:
>>
>>>At stage 2 modpost utility is used to check modules.
>>>In case of unresolved symbols modpost only prints warning.
>>>
>>>IMHO it is a good idea to fail compilation process in case of
>>>unresolved symbols, since usually such errors are left unnoticed,
>>>but kernel modules are broken.
>>
>>The primary reason why we do not fail in this case is that building
>>external modules often result in unresolved symbols at modpost time.
>>
>>And there is many legitime uses of external modules that we shall support.

> Is there a way we can get this only for building the kernel itself?
> In this case an unresolved symbol is a real bug that should cause an 
> abort of the compilation.
IMHO for kernel linking will fail...

Don't you consider the kernel to be broken if suddenly one of your modules
began to have unresolved symbols?

> I'm often doing compile tests for the kernel, and the current warnings 
> are too easy to miss.
exactly. and I'm pretty sure, that vendors have the same problem.

Thanks,
Kirill

Re: [RFC][PATCH] fail kernel compilation in case of unresolved symbols

[Adrian Bunk]

On Wed, Sep 06, 2006 at 07:05:51PM +0400, Kirill Korotaev wrote:
> Adrian Bunk wrote:
> >On Tue, Sep 05, 2006 at 05:31:59PM +0200, Sam Ravnborg wrote:
> >
> >>On Tue, Sep 05, 2006 at 05:47:25PM +0400, Kirill Korotaev wrote:
> >>
> >>>At stage 2 modpost utility is used to check modules.
> >>>In case of unresolved symbols modpost only prints warning.
> >>>
> >>>IMHO it is a good idea to fail compilation process in case of
> >>>unresolved symbols, since usually such errors are left unnoticed,
> >>>but kernel modules are broken.
> >>
> >>The primary reason why we do not fail in this case is that building
> >>external modules often result in unresolved symbols at modpost time.
> >>
> >>And there is many legitime uses of external modules that we shall support.
> 
> >Is there a way we can get this only for building the kernel itself?

s/kernel itself/modules shipped with the kernel/

> >In this case an unresolved symbol is a real bug that should cause an 
> >abort of the compilation.
> IMHO for kernel linking will fail...
> 
> Don't you consider the kernel to be broken if suddenly one of your modules
> began to have unresolved symbols?
>...

> Thanks,
> Kirill

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [RFC][PATCH] fail kernel compilation in case of unresolved symbols

[Sam Ravnborg]

On Wed, Sep 06, 2006 at 07:05:10PM +0400, Kirill Korotaev wrote:
> Sam Ravnborg wrote:
> >On Tue, Sep 05, 2006 at 05:47:25PM +0400, Kirill Korotaev wrote:
> >
> >>At stage 2 modpost utility is used to check modules.
> >>In case of unresolved symbols modpost only prints warning.
> >>
> >>IMHO it is a good idea to fail compilation process in case of
> >>unresolved symbols, since usually such errors are left unnoticed,
> >>but kernel modules are broken.
> >
> >
> >The primary reason why we do not fail in this case is that building
> >external modules often result in unresolved symbols at modpost time.
> >
> >And there is many legitime uses of external modules that we shall support.
> ok. is it ok for you to introduce new Make target 'modules_check'?
In top-level Makefile we already distingush between external modules and
internal modules. See the different calls to Makefile.modpost

Could you try updating your patch so in the normal case we exit with
a fail in case of unresolved symbols but if a specific flag is specified
we only warn on unresolved symbols.

And then introduce the nw flag only for external modules in the
top-level Makefile.

	Sam