[PATCH 1/2] module: fix BUG_ON() for powerpc (and other function descriptor archs)

[PATCH 1/2] module: fix BUG_ON() for powerpc (and other function descriptor archs)

[Rusty Russell]

The rarely-used symbol_put_addr() needs to use dereference_function_descriptor
on powerpc.

Reported-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au.

diff --git a/kernel/module.c b/kernel/module.c
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -909,16 +909,18 @@ void __symbol_put(const char *symbol)
 }
 EXPORT_SYMBOL(__symbol_put);
 
+/* Note this assumes addr is a function, which it currently always is. */
 void symbol_put_addr(void *addr)
 {
 	struct module *modaddr;
+	unsigned long a = (unsigned long)dereference_function_descriptor(addr);
 
-	if (core_kernel_text((unsigned long)addr))
+	if (core_kernel_text(a))
 		return;
 
 	/* module_text_address is safe here: we're supposed to have reference
 	 * to module from symbol_get, so it can't go away. */
-	modaddr = __module_text_address((unsigned long)addr);
+	modaddr = __module_text_address(a);
 	BUG_ON(!modaddr);
 	module_put(modaddr);
 }

[PATCH 2/2] module: workaround duplicate section names

[Rusty Russell]

From: James Bottomley <James.Bottomley@HansenPartnership.com>

(This patch leaves other problems, particularly the sections
 directory, but recent parisc toolchains seem to produce these
 modules and this prevents a crash and is a minimal change -- RR).

The root cause is a duplicate section name (.text); is this legal?

However, there's a problem with commit
6d76013381ed28979cd122eb4b249a88b5e384fa in that if you fail to allocate
a mod->sect_attrs (in this case it's null because of the duplication),
it still gets used without checking in add_notes_attrs()

This should fix it

Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Tested-by: Helge Deller <deller@gmx.de>
---

diff --git a/kernel/module.c b/kernel/module.c
index fd14114..a703c49 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2353,7 +2353,8 @@ static noinline struct module *load_module(void __user *umod,
 	if (err < 0)
 		goto unlink;
 	add_sect_attrs(mod, hdr->e_shnum, secstrings, sechdrs);
-	add_notes_attrs(mod, hdr->e_shnum, secstrings, sechdrs);
+	if (mod->sect_attrs)
+		add_notes_attrs(mod, hdr->e_shnum, secstrings, sechdrs);
 
 	/* Get rid of temporary copy */
 	vfree(hdr);

Re: [PATCH 2/2] module: workaround duplicate section names

[Amerigo Wang]

On Wed, Aug 26, 2009 at 10:04:12PM +0930, Rusty Russell wrote:
>From: James Bottomley <James.Bottomley@HansenPartnership.com>
>
>(This patch leaves other problems, particularly the sections
> directory, but recent parisc toolchains seem to produce these
> modules and this prevents a crash and is a minimal change -- RR).
>
>The root cause is a duplicate section name (.text); is this legal?

AFAIK, yes.


>
>However, there's a problem with commit
>6d76013381ed28979cd122eb4b249a88b5e384fa in that if you fail to allocate
>a mod->sect_attrs (in this case it's null because of the duplication),
>it still gets used without checking in add_notes_attrs()
>
>This should fix it
>
>Signed-off-by: James Bottomley <James.Bottomley@suse.de>
>Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>Tested-by: Helge Deller <deller@gmx.de>

Looks fine for me.

Reviewed-by: WANG Cong <xiyou.wangcong@gmail.com>

Thanks.


>---
>
>diff --git a/kernel/module.c b/kernel/module.c
>index fd14114..a703c49 100644
>--- a/kernel/module.c
>+++ b/kernel/module.c
>@@ -2353,7 +2353,8 @@ static noinline struct module *load_module(void __user *umod,
> 	if (err < 0)
> 		goto unlink;
> 	add_sect_attrs(mod, hdr->e_shnum, secstrings, sechdrs);
>-	add_notes_attrs(mod, hdr->e_shnum, secstrings, sechdrs);
>+	if (mod->sect_attrs)
>+		add_notes_attrs(mod, hdr->e_shnum, secstrings, sechdrs);
> 
> 	/* Get rid of temporary copy */
> 	vfree(hdr);
>--
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/