Re: linux-next: manual merge of the rr tree with the mips tree
Geert Uytterhoeven writes:
> Hi Stephen, David,
>
> On Wed, Aug 22, 2012 at 5:11 AM, Stephen Rothwell
> wrote:
>> Today's linux-next merge of the rr tree got a conflict in
>> arch/mips/kernel/module.c between commit c54de490a2e4 ("MIPS: Module:
>> Deal with malformed HI16/LO16 relocation sequences") from the mips tree
>> and commit 9db0bbe072c8 ("MIPS: Fix module.c build for 32 bit") from the
>> rr tree.
>>
>> Just context changes (I think). I fixed it up (see below) and can carry
>> the fix as necessary.
>
>> + #endif
>
> At first I thought this merge conflict resolution introduced the bogus #endif:
>
> arch/mips/kernel/module.c:247:2: error: #endif without #if
That was my bad rebase against another patch.
Fixed now, thanks.
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the rr tree with the mips tree
Geert Uytterhoeven ge...@linux-m68k.org writes: Hi Stephen, David, On Wed, Aug 22, 2012 at 5:11 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Today's linux-next merge of the rr tree got a conflict in arch/mips/kernel/module.c between commit c54de490a2e4 (MIPS: Module: Deal with malformed HI16/LO16 relocation sequences) from the mips tree and commit 9db0bbe072c8 (MIPS: Fix module.c build for 32 bit) from the rr tree. Just context changes (I think). I fixed it up (see below) and can carry the fix as necessary. + #endif At first I thought this merge conflict resolution introduced the bogus #endif: arch/mips/kernel/module.c:247:2: error: #endif without #if That was my bad rebase against another patch. Fixed now, thanks. Rusty. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the rr tree with the mips tree
Hi Stephen, David,
On Wed, Aug 22, 2012 at 5:11 AM, Stephen Rothwell wrote:
> Today's linux-next merge of the rr tree got a conflict in
> arch/mips/kernel/module.c between commit c54de490a2e4 ("MIPS: Module:
> Deal with malformed HI16/LO16 relocation sequences") from the mips tree
> and commit 9db0bbe072c8 ("MIPS: Fix module.c build for 32 bit") from the
> rr tree.
>
> Just context changes (I think). I fixed it up (see below) and can carry
> the fix as necessary.
> + #endif
At first I thought this merge conflict resolution introduced the bogus #endif:
arch/mips/kernel/module.c:247:2: error: #endif without #if
(e.g. http://kisskb.ellerman.id.au/kisskb/buildresult/6999289/)
but it seems to be present already in David's commit
bd029f48459adc8a72a2db95f7d79a7296c5ad5a ("Make most arch
asm/module.h files use asm-generic/module.h")..
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the rr tree with the mips tree
Hi Stephen, David,
On Wed, Aug 22, 2012 at 5:11 AM, Stephen Rothwell s...@canb.auug.org.au wrote:
Today's linux-next merge of the rr tree got a conflict in
arch/mips/kernel/module.c between commit c54de490a2e4 (MIPS: Module:
Deal with malformed HI16/LO16 relocation sequences) from the mips tree
and commit 9db0bbe072c8 (MIPS: Fix module.c build for 32 bit) from the
rr tree.
Just context changes (I think). I fixed it up (see below) and can carry
the fix as necessary.
+ #endif
At first I thought this merge conflict resolution introduced the bogus #endif:
arch/mips/kernel/module.c:247:2: error: #endif without #if
(e.g. http://kisskb.ellerman.id.au/kisskb/buildresult/6999289/)
but it seems to be present already in David's commit
bd029f48459adc8a72a2db95f7d79a7296c5ad5a (Make most arch
asm/module.h files use asm-generic/module.h)..
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the rr tree with the mips tree
Hi Rusty,
Today's linux-next merge of the rr tree got a conflict in
arch/mips/kernel/module.c between commit c54de490a2e4 ("MIPS: Module:
Deal with malformed HI16/LO16 relocation sequences") from the mips tree
and commit 9db0bbe072c8 ("MIPS: Fix module.c build for 32 bit") from the
rr tree.
Just context changes (I think). I fixed it up (see below) and can carry
the fix as necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/mips/kernel/module.c
index 4f8c3cb,8ffd089..000
--- a/arch/mips/kernel/module.c
+++ b/arch/mips/kernel/module.c
@@@ -132,25 -107,6 +105,17 @@@ static int apply_r_mips_hi16_rel(struc
return 0;
}
- static int apply_r_mips_hi16_rela(struct module *me, u32 *location, Elf_Addr
v)
- {
- *location = (*location & 0x) |
- long long) v + 0x8000LL) >> 16) & 0x);
-
- return 0;
- }
-
+static void free_relocation_chain(struct mips_hi16 *l)
+{
+ struct mips_hi16 *next;
+
+ while (l) {
+ next = l->next;
+ kfree(l);
+ l = next;
+ }
+}
+
static int apply_r_mips_lo16_rel(struct module *me, u32 *location, Elf_Addr v)
{
unsigned long insnlo = *location;
@@@ -308,61 -217,9 +229,22 @@@ int apply_relocate(Elf_Shdr *sechdrs, c
return res;
}
+ /*
+ * Normally the hi16 list should be deallocated at this point. A
+ * malformed binary however could contain a series of R_MIPS_HI16
+ * relocations not followed by a R_MIPS_LO16 relocation. In that
+ * case, free up the list and return an error.
+ */
+ if (me->arch.r_mips_hi16_list) {
+ free_relocation_chain(me->arch.r_mips_hi16_list);
+ me->arch.r_mips_hi16_list = NULL;
+
+ return -ENOEXEC;
+ }
+
return 0;
}
-
- int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
- unsigned int symindex, unsigned int relsec,
- struct module *me)
- {
- Elf_Mips_Rela *rel = (void *) sechdrs[relsec].sh_addr;
- Elf_Sym *sym;
- u32 *location;
- unsigned int i;
- Elf_Addr v;
- int res;
-
- pr_debug("Applying relocate section %u to %u\n", relsec,
- sechdrs[relsec].sh_info);
-
- for (i = 0; i < sechdrs[relsec].sh_size / sizeof(*rel); i++) {
- /* This is where to make the change */
- location = (void *)sechdrs[sechdrs[relsec].sh_info].sh_addr
- + rel[i].r_offset;
- /* This is the symbol it is referring to */
- sym = (Elf_Sym *)sechdrs[symindex].sh_addr
- + ELF_MIPS_R_SYM(rel[i]);
- if (IS_ERR_VALUE(sym->st_value)) {
- /* Ignore unresolved weak symbol */
- if (ELF_ST_BIND(sym->st_info) == STB_WEAK)
- continue;
- printk(KERN_WARNING "%s: Unknown symbol %s\n",
- me->name, strtab + sym->st_name);
- return -ENOENT;
- }
-
- v = sym->st_value + rel[i].r_addend;
-
- res = reloc_handlers_rela[ELF_MIPS_R_TYPE(rel[i])](me,
location, v);
- if (res)
- return res;
- }
-
- return 0;
- }
+ #endif
/* Given an address, look for it in the module exception tables. */
const struct exception_table_entry *search_module_dbetables(unsigned long
addr)
pgpTKqPtCLMtG.pgp
Description: PGP signature
linux-next: manual merge of the rr tree with the mips tree
Hi Rusty,
Today's linux-next merge of the rr tree got a conflict in
arch/mips/kernel/module.c between commit c54de490a2e4 (MIPS: Module:
Deal with malformed HI16/LO16 relocation sequences) from the mips tree
and commit 9db0bbe072c8 (MIPS: Fix module.c build for 32 bit) from the
rr tree.
Just context changes (I think). I fixed it up (see below) and can carry
the fix as necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/mips/kernel/module.c
index 4f8c3cb,8ffd089..000
--- a/arch/mips/kernel/module.c
+++ b/arch/mips/kernel/module.c
@@@ -132,25 -107,6 +105,17 @@@ static int apply_r_mips_hi16_rel(struc
return 0;
}
- static int apply_r_mips_hi16_rela(struct module *me, u32 *location, Elf_Addr
v)
- {
- *location = (*location 0x) |
- long long) v + 0x8000LL) 16) 0x);
-
- return 0;
- }
-
+static void free_relocation_chain(struct mips_hi16 *l)
+{
+ struct mips_hi16 *next;
+
+ while (l) {
+ next = l-next;
+ kfree(l);
+ l = next;
+ }
+}
+
static int apply_r_mips_lo16_rel(struct module *me, u32 *location, Elf_Addr v)
{
unsigned long insnlo = *location;
@@@ -308,61 -217,9 +229,22 @@@ int apply_relocate(Elf_Shdr *sechdrs, c
return res;
}
+ /*
+ * Normally the hi16 list should be deallocated at this point. A
+ * malformed binary however could contain a series of R_MIPS_HI16
+ * relocations not followed by a R_MIPS_LO16 relocation. In that
+ * case, free up the list and return an error.
+ */
+ if (me-arch.r_mips_hi16_list) {
+ free_relocation_chain(me-arch.r_mips_hi16_list);
+ me-arch.r_mips_hi16_list = NULL;
+
+ return -ENOEXEC;
+ }
+
return 0;
}
-
- int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
- unsigned int symindex, unsigned int relsec,
- struct module *me)
- {
- Elf_Mips_Rela *rel = (void *) sechdrs[relsec].sh_addr;
- Elf_Sym *sym;
- u32 *location;
- unsigned int i;
- Elf_Addr v;
- int res;
-
- pr_debug(Applying relocate section %u to %u\n, relsec,
- sechdrs[relsec].sh_info);
-
- for (i = 0; i sechdrs[relsec].sh_size / sizeof(*rel); i++) {
- /* This is where to make the change */
- location = (void *)sechdrs[sechdrs[relsec].sh_info].sh_addr
- + rel[i].r_offset;
- /* This is the symbol it is referring to */
- sym = (Elf_Sym *)sechdrs[symindex].sh_addr
- + ELF_MIPS_R_SYM(rel[i]);
- if (IS_ERR_VALUE(sym-st_value)) {
- /* Ignore unresolved weak symbol */
- if (ELF_ST_BIND(sym-st_info) == STB_WEAK)
- continue;
- printk(KERN_WARNING %s: Unknown symbol %s\n,
- me-name, strtab + sym-st_name);
- return -ENOENT;
- }
-
- v = sym-st_value + rel[i].r_addend;
-
- res = reloc_handlers_rela[ELF_MIPS_R_TYPE(rel[i])](me,
location, v);
- if (res)
- return res;
- }
-
- return 0;
- }
+ #endif
/* Given an address, look for it in the module exception tables. */
const struct exception_table_entry *search_module_dbetables(unsigned long
addr)
pgpTKqPtCLMtG.pgp
Description: PGP signature
