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.
From: Stephen Rothwell <[email protected]>
Date: Thu, 14 Mar 2013 17:14:41 +1100
Subject: [PATCH] cond_syscall and SYSCALL_ALIAS merge fixup
Signed-off-by: Stephen Rothwell <[email protected]>
---
include/linux/linkage.h | 20 ++++++--------------
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index 829d66c..bedcddf 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -2,7 +2,7 @@
#define _LINUX_LINKAGE_H
#include <linux/compiler.h>
-#include <linux/stringify.h>
+#include <linux/export.h>
#include <asm/linkage.h>
#ifdef __cplusplus
@@ -15,24 +15,16 @@
#define asmlinkage CPP_ASMLINKAGE
#endif
-#ifndef SYMBOL_NAME
-#ifdef CONFIG_SYMBOL_PREFIX
-#define SYMBOL_NAME(x) CONFIG_SYMBOL_PREFIX ## x
-#else
-#define SYMBOL_NAME(x) x
-#endif
-#endif
-#define __SYMBOL_NAME(x) __stringify(SYMBOL_NAME(x))
-
#ifndef cond_syscall
-#define cond_syscall(x) asm(".weak\t" __SYMBOL_NAME(x) \
- "\n\t.set\t" __SYMBOL_NAME(x) "," __SYMBOL_NAME(sys_ni_syscall));
+#define cond_syscall(x) asm(".weak\t" VMLINUX_SYMBOL_STR(x) "\n\t" \
+ ".set\t" VMLINUX_SYMBOL_STR(x) "," \
+ VMLINUX_SYMBOL_STR(sys_ni_syscall))
#endif
#ifndef SYSCALL_ALIAS
#define SYSCALL_ALIAS(alias, name) \
- asm ("\t.globl " __SYMBOL_NAME(alias) \
- "\n\t.set\t" __SYMBOL_NAME(alias) "," __SYMBOL_NAME(name))
+ asm ("\t.globl " VMLINUX_SYMBOL_STR(alias) \
+ "\n\t.set\t" VMLINUX_SYMBOL_STR(alias) "," VMLINUX_SYMBOL_STR(name))
#endif
#define __page_aligned_data __section(.data..page_aligned) __aligned(PAGE_SIZE)
--
1.8.1
--
Cheers,
Stephen Rothwell [email protected]
On 14/03/13 06:27, Stephen Rothwell wrote:
> 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.
FYI, I've tested that symbol prefix stuff works on linux-next for metag
(after fixes applied from Rusty's latest symbol prefix patch).
Al: your signal tree still breaks symbol prefixed arches due to stuff
like this in kernel/sys_ni.i:
asm(".weak\t" "CONFIG_SYMBOL_PREFIXsys_quotactl" "\n\t.set\t"
"CONFIG_SYMBOL_PREFIXsys_quotactl" ","
"CONFIG_SYMBOL_PREFIXsys_ni_syscall");;
Cheers
James
Stephen Rothwell <[email protected]> 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.
Cheers,
Rusty.
On Fri, Mar 15, 2013 at 5:41 AM, Rusty Russell <[email protected]> wrote:
> Stephen Rothwell <[email protected]> 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
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?
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Mar 15, 2013 at 11:21 AM, Sedat Dilek <[email protected]> wrote:
> On Fri, Mar 15, 2013 at 5:41 AM, Rusty Russell <[email protected]> wrote:
>> Stephen Rothwell <[email protected]> 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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
Sedat Dilek <[email protected]> writes:
> On Fri, Mar 15, 2013 at 5:41 AM, Rusty Russell <[email protected]> wrote:
>> Stephen Rothwell <[email protected]> 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!
I'd wait until Stephen has done the new merge, which should happen
within 12 hours from now.
Thanks,
Rusty.