Re: linux-next: manual merge of the signal tree with the modules tree

[Sedat Dilek <sedat.dilek@gmail.com>]

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

On Fri, Mar 15, 2013 at 11:21 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> On Fri, Mar 15, 2013 at 5:41 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>> Stephen Rothwell <sfr@canb.auug.org.au> writes:
>>> Hi Al,
>>>
>>> Today's linux-next merge of the signal tree got a conflict in
>>> include/asm-generic/unistd.h between commit 837718bfd28b
>>> ("CONFIG_SYMBOL_PREFIX: cleanup") from the modules tree and commit
>>> e1b5bb6d1236 ("consolidate cond_syscall and SYSCALL_ALIAS declarations")
>>> from the signal tree.
>>>
>>> The latter moved the cond_syscall stuff to linkage.h, so I applied the
>>> following patch as a merge fixup and can carry the fix as necessary (no
>>> action is required).  I am not sure if this is completely correct or all
>>> that is needed.
>>
>> Your fix looks correct, thanks.
>>
>> I've been forced to update that patch after another round of
>> improvements, so you may need to re-do the merge.
>>
>
> Hi,
>
> I just looked into modules-next...
> The improved version is in [1]...
> ...and contains a file called "kernel/modsign_certificate.S" which is
> NOT in the latest Linux-Next tree [2].
> So, I thought about reverting the one in -next and apply the new one
> from modules-next.
> This is not possible!
>
> $ git log --oneline -2
> d98f244 Merge tag 'next-20130315' of
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next into
> Linux-Next-v20130315
> 1765898 Add linux-next specific files for 20130315
>
> $ LC_ALL=C ls -l kernel/mod*
> -rw-r--r-- 1 wearefam wearefam   458 Mar 15 11:13 kernel/module-internal.h
> -rw-r--r-- 1 wearefam wearefam 99000 Mar 15 11:13 kernel/module.c
> -rw-r--r-- 1 wearefam wearefam  6063 Mar 15 11:13 kernel/module_signing.c
>

OK, renamed: kernel/modsign_certificate.S -> kernel/system_certificates.S... see

commit ebe2e946f60e0012c02a27845bdab70e34cc4202
KEYS: Separate the kernel signature checking keyring from module signing

> Is this a generated file?
> I have attached both patches extracted from Linux-Next [3] and modules-next [4].
> Both patches list changes to "kernel/modsign_certificate.S".
> /me ---> confused!
>
> Can you please enlighten me?
>

Is this attached follow-up correct?

- Sedat -

>
> Regards,
> - Sedat -
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/rusty/linux.git/commit/?h=modules-next&id=b92021b09df70c1609e3547f3d6128dd560be97f
> [2] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/kernel?id=next-20130315
> [3] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/patch/?id=837718bfd28ba5f474c1182ef2639b6949d854fc
> [4] http://git.kernel.org/cgit/linux/kernel/git/rusty/linux.git/patch/?id=b92021b09df70c1609e3547f3d6128dd560be97f
>
>> Cheers,
>> Rusty.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-next" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: 0001-CONFIG_SYMBOL_PREFIX-cleanup-improved-version.patch --]
[-- Type: application/octet-stream, Size: 4261 bytes --]

From 7c921951784cbc978a5e0193b91f0c3f8a464810 Mon Sep 17 00:00:00 2001
From: Sedat Dilek <sedat.dilek@gmail.com>
Date: Fri, 15 Mar 2013 12:22:26 +0100
Subject: [PATCH] CONFIG_SYMBOL_PREFIX: cleanup (improved version)

Import missing bits from improved version pending in modules-next.

This is a follow up to commit 837718bfd28b ("CONFIG_SYMBOL_PREFIX: cleanup.")
in Linux-Next (next-20130315).

Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
---
 Makefile                      |  2 +-
 drivers/mtd/chips/gen_probe.c |  8 +++++---
 include/linux/export.h        |  9 ++-------
 scripts/mod/modpost.c         | 17 +++++++++--------
 4 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/Makefile b/Makefile
index 10fb6c7..0b09ba5 100644
--- a/Makefile
+++ b/Makefile
@@ -1398,7 +1398,7 @@ quiet_cmd_rmfiles = $(if $(wildcard $(rm-files)),CLEAN   $(wildcard $(rm-files))
 # Run depmod only if we have System.map and depmod is executable
 quiet_cmd_depmod = DEPMOD  $(KERNELRELEASE)
       cmd_depmod = $(CONFIG_SHELL) $(srctree)/scripts/depmod.sh $(DEPMOD) \
-                   $(KERNELRELEASE) "$(patsubst y,_,$(CONFIG_HAVE_SYMBOL_PREFIX_UNDERSCORE))"
+                   $(KERNELRELEASE) "$(patsubst y,_,$(CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX))"
 
 # Create temporary dir for module support files
 # clean it up only when building all modules
diff --git a/drivers/mtd/chips/gen_probe.c b/drivers/mtd/chips/gen_probe.c
index 00d20ad..74dbb6b 100644
--- a/drivers/mtd/chips/gen_probe.c
+++ b/drivers/mtd/chips/gen_probe.c
@@ -204,14 +204,16 @@ static inline struct mtd_info *cfi_cmdset_unknown(struct map_info *map,
 	struct cfi_private *cfi = map->fldrv_priv;
 	__u16 type = primary?cfi->cfiq->P_ID:cfi->cfiq->A_ID;
 #ifdef CONFIG_MODULES
-	char probename[16+sizeof(VMLINUX_SYMBOL_PREFIX_STR)];
+	char probename[sizeof(VMLINUX_SYMBOL_STR(cfi_cmdset_%4.4X))];
 	cfi_cmdset_fn_t *probe_function;
 
-	sprintf(probename, VMLINUX_SYMBOL_PREFIX_STR "cfi_cmdset_%4.4X", type);
+	sprintf(probename, VMLINUX_SYMBOL_STR(cfi_cmdset_%4.4X), type);
 
 	probe_function = __symbol_get(probename);
 	if (!probe_function) {
-		request_module(probename + sizeof(VMLINUX_SYMBOL_PREFIX_STR)-1);
+		char modname[sizeof("cfi_cmdset_%4.4X")];
+		sprintf(modname, "cfi_cmdset_%4.4X", type);
+		request_module(modname);
 		probe_function = __symbol_get(probename);
 	}
 
diff --git a/include/linux/export.h b/include/linux/export.h
index fc83b2a..412cd50 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -5,22 +5,17 @@
  * to reduce the amount of pointless cruft we feed to gcc when only
  * exporting a simple symbol or two.
  *
- * If you feel the need to add #include <linux/foo.h> to this file
- * then you are doing something wrong and should go away silently.
- *
- * If you think the above arrogance just encourages more people to add
- * random crap to this file, you're not alone.
+ * Try not to add #includes here.  It slows compilation and makes kernel
+ * hackers place grumpy comments in header files.
  */
 
 /* Some toolchains use a `_' prefix for all user symbols. */
 #ifdef CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX
 #define __VMLINUX_SYMBOL(x) _##x
 #define __VMLINUX_SYMBOL_STR(x) "_" #x
-#define VMLINUX_SYMBOL_PREFIX_STR "_"
 #else
 #define __VMLINUX_SYMBOL(x) x
 #define __VMLINUX_SYMBOL_STR(x) #x
-#define VMLINUX_SYMBOL_PREFIX_STR ""
 #endif
 
 /* Indirect, so macros are expanded before pasting. */
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 6985021..282decf 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -630,14 +630,15 @@ static void handle_modversions(struct module *mod, struct elf_info *info,
 		}
 #endif
 
-		if (memcmp(symname, VMLINUX_SYMBOL_PREFIX_STR,
-			   strlen(VMLINUX_SYMBOL_PREFIX_STR)) == 0) {
-			mod->unres =
-			  alloc_symbol(symname +
-			               strlen(VMLINUX_SYMBOL_PREFIX_STR),
-			               ELF_ST_BIND(sym->st_info) == STB_WEAK,
-			               mod->unres);
-		}
+#ifdef CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX
+		if (symname[0] != '_')
+			break;
+		else
+			symname++;
+#endif
+		mod->unres = alloc_symbol(symname,
+					  ELF_ST_BIND(sym->st_info) == STB_WEAK,
+					  mod->unres);
 		break;
 	default:
 		/* All exported symbols */
-- 
1.8.2