linux-kernel - Re: [PATCH] fix modpost warnings for xtensa

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]
Date:	Wed, 25 Jul 2007 22:29:22 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Chris Zankel <czankel@...silica.com>
Cc:	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	chris@...kel.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fix modpost warnings for xtensa

On Thu, Jul 19, 2007 at 11:37:56AM -0700, Chris Zankel wrote:
> 	[PATCH] fix modpost warnings for xtensa
> 
> 	The Xtensa architecture places literal pools in sections separate 
> 	from the instructions. The corresponsing text sections, therefore, 
> 	reference the .literal section, and we have to suppress those
> 	warnings. The naming convention defines the name for a literal 
> 	section as .SECTION.literal, unless .SECTION is .text. In that case
> 	the name is only .literal. Using strncmp() instead of strcmp() 
> 	to compare the from-section with .SECTION.init.refok in pattern 0
> 	should not cause any regressions for other architectures.
> 	We also need to suppress warnings for two informational 
> 	sections (.xt.lit and .xt.prop) used by the Xtensa architecture.
> 
> 	Signed-off-by: Chris Zankel <chris@...kel.net>

Hi Chris,
I hand applied your patch and have pushed the following patch to kbuild.git.
I simplified it a bit and decided to break the 80 char limit..

	Sam

>From cb7e51d8b1f8e2390970f4bb7d095c414b1bf3cf Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <sam@...nborg.org>
Date: Wed, 25 Jul 2007 22:24:52 +0200
Subject: [PATCH] kbuild: fix modpost warnings for xtensa

The Xtensa architecture places literal pools in sections separate
from the instructions. The corresponsing text sections, therefore,
reference the .literal section, and we have to suppress those
warnings.

The naming convention defines the name for a literal
section as .SECTION.literal, unless .SECTION is .text. In that case
the name is only .literal. Using strncmp() instead of strcmp()
to compare the from-section with .SECTION.init.refok in pattern 0
should not cause any regressions for other architectures.

We also need to suppress warnings for two informational
sections (.xt.lit and .xt.prop) used by the Xtensa architecture.

Signed-off-by: Chris Zankel <chris@...kel.net>
Signed-off-by: Sam Ravnborg <sam@...nborg.org>
---
 scripts/mod/modpost.c |   30 ++++++++++++++++++++++++------
 1 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 3db4edc..ee58ded 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -640,7 +640,7 @@ static int data_section(const char *name)
  * Pattern 0:
  *   Do not warn if funtion/data are marked with __init_refok/__initdata_refok.
  *   The pattern is identified by:
- *   fromsec = .text.init.refok | .data.init.refok
+ *   fromsec = .text.init.refok* | .data.init.refok*
  *
  * Pattern 1:
  *   If a module parameter is declared __initdata and permissions=0
@@ -675,11 +675,18 @@ static int data_section(const char *name)
  *   This pattern is identified by
  *   refsymname = __init_begin, _sinittext, _einittext
  *
+ * Pattern 5:
+ *   Xtensa uses literal sections for constants that are accessed PC-relative.
+ *   Literal sections may safely reference their text sections.
+ *   (Note that the name for the literal section omits any trailing '.text')
+ *   tosec = <section>[.text]
+ *   fromsec = <section>.literal
  **/
 static int secref_whitelist(const char *modname, const char *tosec,
 			    const char *fromsec, const char *atsym,
 			    const char *refsymname)
 {
+	int len;
 	const char **s;
 	const char *pat2sym[] = {
 		"driver",
@@ -701,8 +708,8 @@ static int secref_whitelist(const char *modname, const char *tosec,
 	};
 
 	/* Check for pattern 0 */
-	if ((strcmp(fromsec, ".text.init.refok") == 0) ||
-	    (strcmp(fromsec, ".data.init.refok") == 0))
+	if ((strncmp(fromsec, ".text.init.refok", strlen(".text.init.refok")) == 0) ||
+	    (strncmp(fromsec, ".data.init.refok", strlen(".data.init.refok")) == 0))
 		return 1;
 
 	/* Check for pattern 1 */
@@ -728,6 +735,15 @@ static int secref_whitelist(const char *modname, const char *tosec,
 		if (strcmp(refsymname, *s) == 0)
 			return 1;
 
+	/* Check for pattern 5 */
+	if (strrcmp(tosec, ".text") == 0)
+		len = strlen(tosec) - strlen(".text");
+	else
+		len = strlen(tosec);
+	if ((strncmp(tosec, fromsec, len) == 0) && (strlen(fromsec) > len) &&
+	    (strcmp(fromsec + len, ".literal") == 0))
+		return 1;
+
 	return 0;
 }
 
@@ -856,9 +872,9 @@ static void warn_sec_mismatch(const char *modname, const char *fromsec,
 		refsymname = elf->strtab + refsym->st_name;
 
 	/* check whitelist - we may ignore it */
-	if (before &&
-	    secref_whitelist(modname, secname, fromsec,
-			     elf->strtab + before->st_name, refsymname))
+	if (secref_whitelist(modname, secname, fromsec,
+			     before ? elf->strtab + before->st_name : "",
+	                     refsymname))
 		return;
 
 	if (before && after) {
@@ -1111,6 +1127,8 @@ static int initexit_section_ref_ok(const char *name)
 		".smp_locks",
 		".stab",
 		".m68k_fixup",
+		".xt.prop",		/* xtensa informational section */
+		".xt.lit",		/* xtensa informational section */
 		NULL
 	};
 	/* Start of section names */
-- 
1.5.1.rc3.g84b7-dirty

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/