uml: fix a link error

PATCH In review Américo Wang 11 participants 20 messages Jan 15, 2009 – Feb 12, 2009

Subsystems (2)

User-mode Linux (UML) ABI/API

lore

Share & tools

lore

Américo Wang

author

2009-01-15 11:41 UTC #0 lore raw

PATCH 1/1 uml: fix a link error

This patch fixes the following link error:

LD .tmp_vmlinux1
arch/um/sys-i386/built-in.o: In function sys_call_table':
(.rodata+0x308): undefined reference to sys_sigprocmask'
collect2: ld returned 1 exit status
KSYM .tmp_kallsyms1.S
nm: '.tmp_vmlinux1': No such file
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
arch/um/sys-i386/built-in.o: In function sys_call_table':
(.rodata+0x308): undefined reference to sys_sigprocmask'
collect2: ld returned 1 exit status
make[1]: *** [.tmp_vmlinux2] Error 1
make: *** [sub-make] Error 2

Signed-off-by WANG Cong <[email protected]>

Cc Jeff Dike <[email protected]>

---

arch/um/sys-i386/sys_call_table.S +1 -0

index 00e5f52..04147dc 100644
@@ -6,6 +6,7 @@
 
 #define sys_vm86old sys_ni_syscall
 #define sys_vm86 sys_ni_syscall
+#define sys_sigprocmask sigprocmask
 
 #define old_mmap old_mmap_i386

Andrew Morton

2009-01-16 20:42 UTC #1 lore raw

Quoted 27 lines · On Thu, 15 Jan 2009 19:40:33 +0000 Am__rico Wang <[email protected]>…

This patch fixes the following link error:
LD .tmp_vmlinux1
arch/um/sys-i386/built-in.o: In function sys_call_table':
(.rodata+0x308): undefined reference to sys_sigprocmask'
collect2: ld returned 1 exit status
KSYM .tmp_kallsyms1.S
nm: '.tmp_vmlinux1': No such file
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
arch/um/sys-i386/built-in.o: In function sys_call_table':
(.rodata+0x308): undefined reference to sys_sigprocmask'
collect2: ld returned 1 exit status
make[1]: *** [.tmp_vmlinux2] Error 1
make: *** [sub-make] Error 2
Signed-off-by WANG Cong <[email protected]>
Cc Jeff Dike <[email protected]>
---
arch/um/sys-i386/sys_call_table.S +0 -0
index 00e5f52..04147dc 100644

arch/um/sys-i386/sys_call_table.S line 12

Quoted 7 lines

arch/um/sys-i386/sys_call_table.S +1 -0

@@ -6,6 +6,7 @@
 
 #define sys_vm86old sys_ni_syscall
 #define sys_vm86 sys_ni_syscall
+#define sys_sigprocmask sigprocmask
 
 #define old_mmap old_mmap_i386

For how long has this problem been present?

Why aren't lots of other people reporting it?

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Jeff Dike

2009-01-16 21:44 UTC #2 lore raw

Quoted 6 lines · Andrew Morton

Quoted 4 lines · On Thu, 15 Jan 2009 19:40:33 +0000 Am__rico Wang <[email protected]>…
#define sys_vm86old sys_ni_syscall
#define sys_vm86 sys_ni_syscall
+#define sys_sigprocmask sigprocmask

Quoted 6 lines

Quoted 2 lines
#define old_mmap old_mmap_i386
For how long has this problem been present?
Why aren't lots of other people reporting it?

There's no problem AFAICT.

This is just bogus.

As you point out, if sigprocmask were missing, people would have noticed. Also, the proposed definition would pull in the libc system call wrapper, not the UML system call definition.

Jeff

Rob Landley

2009-01-17 20:46 UTC #3 lore raw

In reply to Andrew Morton

Quoted 10 lines · On Friday 16 January 2009 14:41:58 Andrew Morton wrote:

Quoted 10 lines
(quoted diff) +0 -0
b/arch/um/sys-i386/sys_call_table.S index 00e5f52..04147dc 100644
arch/um/sys-i386/sys_call_table.S +1 -0
@@ -6,6 +6,7 @@
 
 #define sys_vm86old sys_ni_syscall
 #define sys_vm86 sys_ni_syscall
+#define sys_sigprocmask sigprocmask
 

Quoted 5 lines

arch/um/sys-i386/sys_call_table.S line 11
Quoted 1 line
arch/um/sys-i386/sys_call_table.S +0 -0
 #define old_mmap old_mmap_i386
For how long has this problem been present?
Why aren't lots of other people reporting it?

I'm not sure User Mode Linux still has a lot of users regularly testing the latest and greatest version. (QEMU and KVM kinda took the wind out of its sails.)

I still find it useful to be able to stick printfs into the code and debug stuff even when the console isn't working, but I haven't been able to build a version of 2.6.28 that works for me at all:

cat > mini.conf << EOF
CONFIG_BINFMT_ELF=y
CONFIG_HOSTFS=y
CONFIG_LBD=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_LOOP=y CONFIG_STDERR_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_STATIC_LINK=y
CONFIG_NO_HZ=y
CONFIG_UNEVICTABLE_LRU=y
EOF
make ARCH=um allnoconfig KCONFIG_ALLCONFIG=mini.conf make ARCH=um -j 3
./linux rw init=/bin/bash rootfstype=hostfs

The result panics (twice) and exits, instead of giving me a shell prompt. Built and run on stock Ubuntu 8.10. (I posted about it on tuesday, but nobody replied...)

Rob

Daolong Wang

2009-01-18 06:23 UTC #4 lore raw

I can confirm this link error. And this patch works for me.

Quoted 47 lines · Rob Landley

Quoted 10 lines · On Friday 16 January 2009 14:41:58 Andrew Morton wrote:
Quoted 10 lines
(quoted diff) +0 -0
b/arch/um/sys-i386/sys_call_table.S index 00e5f52..04147dc 100644
arch/um/sys-i386/sys_call_table.S +1 -0
@@ -6,6 +6,7 @@
 
 #define sys_vm86old sys_ni_syscall
 #define sys_vm86 sys_ni_syscall
+#define sys_sigprocmask sigprocmask
 
Quoted 5 lines
arch/um/sys-i386/sys_call_table.S line 11
Quoted 1 line
arch/um/sys-i386/sys_call_table.S +0 -0
 #define old_mmap old_mmap_i386
For how long has this problem been present?
Why aren't lots of other people reporting it?
I'm not sure User Mode Linux still has a lot of users regularly testing the latest and greatest version. (QEMU and KVM kinda took the wind out of its sails.)
I still find it useful to be able to stick printfs into the code and debug stuff even when the console isn't working, but I haven't been able to build a version of 2.6.28 that works for me at all:
cat > mini.conf << EOF
CONFIG_BINFMT_ELF=y
CONFIG_HOSTFS=y
CONFIG_LBD=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_LOOP=y CONFIG_STDERR_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_STATIC_LINK=y
CONFIG_NO_HZ=y
CONFIG_UNEVICTABLE_LRU=y
EOF
make ARCH=um allnoconfig KCONFIG_ALLCONFIG=mini.conf make ARCH=um -j 3
./linux rw init=/bin/bash rootfstype=hostfs
The result panics (twice) and exits, instead of giving me a shell prompt. Built and run on stock Ubuntu 8.10. (I posted about it on tuesday, but nobody replied...)

Quoted 7 lines

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

Jeff Dike

2009-01-19 15:21 UTC #5 lore raw

Quoted 1 line · Daolong Wang

I can confirm this link error.

In what environment? I see no problems here.

Quoted 1 line

And this patch works for me.

Maybe it fixes the link failure. But I really doubt that sigprocmask works.

Jeff

Signature · 11 lines

Work email - jdike at linux dot intel dot com

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Daolong Wang

2009-01-20 01:46 UTC #6 lore raw

Quoted 5 lines · Jeff Dike

Quoted 1 line · Daolong Wang
I can confirm this link error.
In what environment? I see no problems here.

Ubuntu 8.04. Gcc is 4.2.4. Sorry I don't have the access to the machine now.

Quoted 4 lines

Quoted 1 line
And this patch works for me.
Maybe it fixes the link failure. But I really doubt that sigprocmask works.

not sure. compile test only!

Quoted 5 lines

Jeff
--
Work email - jdike at linux dot intel dot com

Shane Hathaway

2009-01-20 02:01 UTC #7 lore raw

Quoted 4 lines · Daolong Wang

Quoted 3 lines · Jeff Dike
Quoted 1 line · Daolong Wang
I can confirm this link error.
In what environment? I see no problems here.

I can also confirm this link error. The problem occurs when compiling either 2.6.28.1 or 2.6.27.12; I didn't try anything earlier. The patch suggested at this beginning of this thread did solve the link problem and the resulting kernel ran for several hours. However, I think the patch is still probably incorrect.

I'm going to repost what I said in another message I sent today, this time with a wider audience:

The problem is that the name "sigprocmask" is getting renamed to "kernel_sigprocmask" by a compiler directive in arch/um/Makefile, then that name gets mangled into "sys_kernel_sigprocmask" by the SYSCALL_DEFINE3(sigprocmask, ...) macro in kernel/signal.c.

So, instead of the patch suggested earlier, I added the following line to arch/um/sys-i386/sys_call_table.S:

#define sys_sigprocmask sys_kernel_sigprocmask

This made it compile and link correctly. Look at the symbols generated by the compile of signal.c to see what I mean:

# nm kernel/signal.o | grep sigprocmask
0000008f r __kstrtab_kernel_sigprocmask
00000040 r __ksymtab_kernel_sigprocmask
00001ea6 T kernel_sigprocmask
00002d67 T sys_kernel_sigprocmask
00001faf T sys_rt_sigprocmask

Unfortunately, it's a mystery to me that others haven't run into this before. My host environment is RHEL 4 inside some kind of chroot.

Shane

Al Viro

2009-01-27 09:23 UTC #8 lore raw

Quoted 9 lines · Shane Hathaway

The problem is that the name "sigprocmask" is getting renamed to "kernel_sigprocmask" by a compiler directive in arch/um/Makefile, then that name gets mangled into "sys_kernel_sigprocmask" by the SYSCALL_DEFINE3(sigprocmask, ...) macro in kernel/signal.c.
So, instead of the patch suggested earlier, I added the following line to arch/um/sys-i386/sys_call_table.S:
#define sys_sigprocmask sys_kernel_sigprocmask

Interesting... Everything else aside, we have difference in e.g. SYSCALL_DEFINE0 and SYSCALL_DEFINE3 behaviours: SYSCALL_DEFINE0(name) will *not* do macro expansion in name and SYSCALL_DEFINE3(name, blah, ...) will.

The reason is that we have name carried through extra layer of macros in the latter case. Argument is *NOT* a subject to expansion when it is used with ##; however, passing it to another macro will expand it just fine.

Regardless of the kludge with -D used by uml, I'd say that we want consistency here; keeping the original behaviour would also be nice.

How about
#define SYSCALL_DEFINE1(name,...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)
etc.
with

#define SYSCALL_DEFINEx(x, name, ...)                                   \
        asmlinkage long sys##name(__SC_DECL##x(__VA_ARGS__))

That gives consistent behaviour in all cases and avoids the insane side effects like this one.

Geert Uytterhoeven

2009-02-04 17:26 UTC #9 lore raw

In reply to Shane Hathaway

Quoted 35 lines · Shane Hathaway

Quoted 4 lines · Daolong Wang
Quoted 3 lines · Jeff Dike
Quoted 1 line · Daolong Wang
I can confirm this link error.
In what environment? I see no problems here.
I can also confirm this link error. The problem occurs when compiling either 2.6.28.1 or 2.6.27.12; I didn't try anything earlier. The patch suggested at this beginning of this thread did solve the link problem and the resulting kernel ran for several hours. However, I think the patch is still probably incorrect.
I'm going to repost what I said in another message I sent today, this time with a wider audience:
The problem is that the name "sigprocmask" is getting renamed to "kernel_sigprocmask" by a compiler directive in arch/um/Makefile, then that name gets mangled into "sys_kernel_sigprocmask" by the SYSCALL_DEFINE3(sigprocmask, ...) macro in kernel/signal.c.
So, instead of the patch suggested earlier, I added the following line to arch/um/sys-i386/sys_call_table.S:
#define sys_sigprocmask sys_kernel_sigprocmask
This made it compile and link correctly. Look at the symbols generated by the compile of signal.c to see what I mean:
# nm kernel/signal.o | grep sigprocmask
0000008f r __kstrtab_kernel_sigprocmask
00000040 r __ksymtab_kernel_sigprocmask
00001ea6 T kernel_sigprocmask
00002d67 T sys_kernel_sigprocmask
00001faf T sys_rt_sigprocmask

Quoted 2 lines

Unfortunately, it's a mystery to me that others haven't run into this before. My host environment is RHEL 4 inside some kind of chroot.

I've just started seeing this problem with some 2.6.29-rc3 kernel...

Before, I did not have this problem with various 2.6.28-rc8 and 2.6.29-rc1 kernels (and several older versions I don't remember).

Given 2.6.29-rc1 works for me and 2.6.28.1 fails for you, I'm inclined to believe 2.6.28 is OK. I'll give it a try...

BTW, I'm using CentOS 5.2.

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   [email protected]
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Geert Uytterhoeven

2009-02-04 20:33 UTC #10 lore raw

Quoted 41 lines · Geert Uytterhoeven

Quoted 35 lines · Shane Hathaway
Quoted 4 lines · Daolong Wang
Quoted 3 lines · Jeff Dike
Quoted 1 line · Daolong Wang
I can confirm this link error.
In what environment? I see no problems here.
I can also confirm this link error. The problem occurs when compiling either 2.6.28.1 or 2.6.27.12; I didn't try anything earlier. The patch suggested at this beginning of this thread did solve the link problem and the resulting kernel ran for several hours. However, I think the patch is still probably incorrect.
I'm going to repost what I said in another message I sent today, this time with a wider audience:
The problem is that the name "sigprocmask" is getting renamed to "kernel_sigprocmask" by a compiler directive in arch/um/Makefile, then that name gets mangled into "sys_kernel_sigprocmask" by the SYSCALL_DEFINE3(sigprocmask, ...) macro in kernel/signal.c.
So, instead of the patch suggested earlier, I added the following line to arch/um/sys-i386/sys_call_table.S:
#define sys_sigprocmask sys_kernel_sigprocmask
This made it compile and link correctly. Look at the symbols generated by the compile of signal.c to see what I mean:
# nm kernel/signal.o | grep sigprocmask
0000008f r __kstrtab_kernel_sigprocmask
00000040 r __ksymtab_kernel_sigprocmask
00001ea6 T kernel_sigprocmask
00002d67 T sys_kernel_sigprocmask
00001faf T sys_rt_sigprocmask
Quoted 2 lines
Unfortunately, it's a mystery to me that others haven't run into this before. My host environment is RHEL 4 inside some kind of chroot.
I've just started seeing this problem with some 2.6.29-rc3 kernel...

Quoted 7 lines

Before, I did not have this problem with various 2.6.28-rc8 and 2.6.29-rc1 kernels (and several older versions I don't remember).
Given 2.6.29-rc1 works for me and 2.6.28.1 fails for you, I'm inclined to believe 2.6.28 is OK. I'll give it a try...
BTW, I'm using CentOS 5.2.

Following up from home...

Indeed, 2.6.28 works, 2.6.28.1 doesn't.

According to git bisect, it got introduced by the system call security fixes (CVE-2009-0029), more specifically by this part:

| commit fe7c0d987fb2cce464d29eec9dfcca6296b5eed7
| Author: Heiko Carstens <[email protected]>
| Date:   Wed Jan 14 14:14:06 2009 +0100
| 
|     System call wrappers part 04
|     
|     commit b290ebe2c46d01b742b948ce03f09e8a3efb9a92 upstream.
|     
|     Signed-off-by: Heiko Carstens <[email protected]>
|     Signed-off-by: Greg Kroah-Hartman <[email protected]>
| 
| --- a/kernel/signal.c
| +++ b/kernel/signal.c
| @@ -2425,8 +2424,8 @@ sys_sigpending(old_sigset_t __user *set)
|  /* Some platforms have their own version with special arguments others
|     support only sys_rt_sigprocmask.  */
|  
| -asmlinkage long
| -sys_sigprocmask(int how, old_sigset_t __user *set, old_sigset_t __user *oset)
   ^^^^^^^^^^^^^^^
| +SYSCALL_DEFINE3(sigprocmask, int, how, old_sigset_t __user *, set,
                   ^^^^^^^^^^^
| +		old_sigset_t __user *, oset)
|  {
|  	int error;
|  	old_sigset_t old_set, new_set;

Hence it allows sigprocmask to be redefined to kernel_sigprocmask by the C preprocessor...

This got backported to 2.6.27.12 as well, confusing people who ran post-2.6.27 development kernels and never noticed the problem (including Jeff and me)...

It showed up in a "development" kernel in 2.6.29-rc2 only.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

Greg KH

2009-02-04 20:42 UTC #11 lore raw

Quoted 84 lines · Geert Uytterhoeven

Quoted 41 lines · Geert Uytterhoeven
Quoted 35 lines · Shane Hathaway
Quoted 4 lines · Daolong Wang
Quoted 3 lines · Jeff Dike
Quoted 1 line · Daolong Wang
I can confirm this link error.
In what environment? I see no problems here.
I can also confirm this link error. The problem occurs when compiling either 2.6.28.1 or 2.6.27.12; I didn't try anything earlier. The patch suggested at this beginning of this thread did solve the link problem and the resulting kernel ran for several hours. However, I think the patch is still probably incorrect.
I'm going to repost what I said in another message I sent today, this time with a wider audience:
The problem is that the name "sigprocmask" is getting renamed to "kernel_sigprocmask" by a compiler directive in arch/um/Makefile, then that name gets mangled into "sys_kernel_sigprocmask" by the SYSCALL_DEFINE3(sigprocmask, ...) macro in kernel/signal.c.
So, instead of the patch suggested earlier, I added the following line to arch/um/sys-i386/sys_call_table.S:
#define sys_sigprocmask sys_kernel_sigprocmask
This made it compile and link correctly. Look at the symbols generated by the compile of signal.c to see what I mean:
# nm kernel/signal.o | grep sigprocmask
0000008f r __kstrtab_kernel_sigprocmask
00000040 r __ksymtab_kernel_sigprocmask
00001ea6 T kernel_sigprocmask
00002d67 T sys_kernel_sigprocmask
00001faf T sys_rt_sigprocmask
Quoted 2 lines
Unfortunately, it's a mystery to me that others haven't run into this before. My host environment is RHEL 4 inside some kind of chroot.
I've just started seeing this problem with some 2.6.29-rc3 kernel...
Quoted 7 lines
Before, I did not have this problem with various 2.6.28-rc8 and 2.6.29-rc1 kernels (and several older versions I don't remember).
Given 2.6.29-rc1 works for me and 2.6.28.1 fails for you, I'm inclined to believe 2.6.28 is OK. I'll give it a try...
BTW, I'm using CentOS 5.2.
Following up from home...
Indeed, 2.6.28 works, 2.6.28.1 doesn't.
According to git bisect, it got introduced by the system call security fixes (CVE-2009-0029), more specifically by this part:
| commit fe7c0d987fb2cce464d29eec9dfcca6296b5eed7
| Author: Heiko Carstens <[email protected]>
| Date:   Wed Jan 14 14:14:06 2009 +0100
| 
|     System call wrappers part 04
|     
|     commit b290ebe2c46d01b742b948ce03f09e8a3efb9a92 upstream.
|     
|     Signed-off-by: Heiko Carstens <[email protected]>
|     Signed-off-by: Greg Kroah-Hartman <[email protected]>
| 
| --- a/kernel/signal.c
| +++ b/kernel/signal.c
| @@ -2425,8 +2424,8 @@ sys_sigpending(old_sigset_t __user *set)
|  /* Some platforms have their own version with special arguments others
|     support only sys_rt_sigprocmask.  */
|  
| -asmlinkage long
| -sys_sigprocmask(int how, old_sigset_t __user *set, old_sigset_t __user *oset)
   ^^^^^^^^^^^^^^^
| +SYSCALL_DEFINE3(sigprocmask, int, how, old_sigset_t __user *, set,
                   ^^^^^^^^^^^
| +		old_sigset_t __user *, oset)
|  {
|  	int error;
|  	old_sigset_t old_set, new_set;

Quoted 7 lines

Hence it allows sigprocmask to be redefined to kernel_sigprocmask by the C preprocessor...
This got backported to 2.6.27.12 as well, confusing people who ran post-2.6.27 development kernels and never noticed the problem (including Jeff and me)...
It showed up in a "development" kernel in 2.6.29-rc2 only.

Is there a real patch in Linus's tree for this fix that I can add to the .27 and .28 -stable kernel trees?

thanks,

greg k-h

Geert Uytterhoeven

2009-02-04 20:54 UTC #12 lore raw

Quoted 88 lines · Greg KH

Quoted 87 lines · Geert Uytterhoeven
Quoted 41 lines · Geert Uytterhoeven
Quoted 35 lines · Shane Hathaway
Quoted 4 lines · Daolong Wang
Quoted 3 lines · Jeff Dike
Quoted 1 line · Daolong Wang
I can confirm this link error.
In what environment? I see no problems here.
I can also confirm this link error. The problem occurs when compiling either 2.6.28.1 or 2.6.27.12; I didn't try anything earlier. The patch suggested at this beginning of this thread did solve the link problem and the resulting kernel ran for several hours. However, I think the patch is still probably incorrect.
I'm going to repost what I said in another message I sent today, this time with a wider audience:
The problem is that the name "sigprocmask" is getting renamed to "kernel_sigprocmask" by a compiler directive in arch/um/Makefile, then that name gets mangled into "sys_kernel_sigprocmask" by the SYSCALL_DEFINE3(sigprocmask, ...) macro in kernel/signal.c.
So, instead of the patch suggested earlier, I added the following line to arch/um/sys-i386/sys_call_table.S:
#define sys_sigprocmask sys_kernel_sigprocmask
This made it compile and link correctly. Look at the symbols generated by the compile of signal.c to see what I mean:
# nm kernel/signal.o | grep sigprocmask
0000008f r __kstrtab_kernel_sigprocmask
00000040 r __ksymtab_kernel_sigprocmask
00001ea6 T kernel_sigprocmask
00002d67 T sys_kernel_sigprocmask
00001faf T sys_rt_sigprocmask
Quoted 2 lines
Unfortunately, it's a mystery to me that others haven't run into this before. My host environment is RHEL 4 inside some kind of chroot.
I've just started seeing this problem with some 2.6.29-rc3 kernel...
Quoted 7 lines
Before, I did not have this problem with various 2.6.28-rc8 and 2.6.29-rc1 kernels (and several older versions I don't remember).
Given 2.6.29-rc1 works for me and 2.6.28.1 fails for you, I'm inclined to believe 2.6.28 is OK. I'll give it a try...
BTW, I'm using CentOS 5.2.
Following up from home...
Indeed, 2.6.28 works, 2.6.28.1 doesn't.
According to git bisect, it got introduced by the system call security fixes (CVE-2009-0029), more specifically by this part:
| commit fe7c0d987fb2cce464d29eec9dfcca6296b5eed7
| Author: Heiko Carstens <[email protected]>
| Date:   Wed Jan 14 14:14:06 2009 +0100
| 
|     System call wrappers part 04
|     
|     commit b290ebe2c46d01b742b948ce03f09e8a3efb9a92 upstream.
|     
|     Signed-off-by: Heiko Carstens <[email protected]>
|     Signed-off-by: Greg Kroah-Hartman <[email protected]>
| 
| --- a/kernel/signal.c
| +++ b/kernel/signal.c
| @@ -2425,8 +2424,8 @@ sys_sigpending(old_sigset_t __user *set)
|  /* Some platforms have their own version with special arguments others
|     support only sys_rt_sigprocmask.  */
|  
| -asmlinkage long
| -sys_sigprocmask(int how, old_sigset_t __user *set, old_sigset_t __user *oset)
   ^^^^^^^^^^^^^^^
| +SYSCALL_DEFINE3(sigprocmask, int, how, old_sigset_t __user *, set,
                   ^^^^^^^^^^^
| +		old_sigset_t __user *, oset)
|  {
|  	int error;
|  	old_sigset_t old_set, new_set;
Hence it allows sigprocmask to be redefined to kernel_sigprocmask by the C preprocessor...

Quoted 7 lines

Quoted 4 lines
This got backported to 2.6.27.12 as well, confusing people who ran post-2.6.27 development kernels and never noticed the problem (including Jeff and me)...
It showed up in a "development" kernel in 2.6.29-rc2 only.
Is there a real patch in Linus's tree for this fix that I can add to the .27 and .28 -stable kernel trees?

No, not yet. I just wanted to let you know about this regression.

I verified that Shane's solution:

#define sys_sigprocmask sys_kernel_sigprocmask

works for me, but that's definitely not the cleanest way.

Al Viro also had a suggestion to rework the SYSCALL_DEFINE* macros, but I haven't tried it yet.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

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

Heiko Carstens

2009-02-07 12:00 UTC #13 lore raw

Quoted 8 lines · On Wed, 4 Feb 2009 21:54:12 +0100 (CET) Geert Uytterhoeven…

I verified that Shane's solution:
#define sys_sigprocmask sys_kernel_sigprocmask
works for me, but that's definitely not the cleanest way.
Al Viro also had a suggestion to rework the SYSCALL_DEFINE* macros, but I haven't tried it yet.

Patch below should fix it.

Subject: [PATCH] syscall define: fix uml compile bug

From: Heiko Carstens <[email protected]>

With the new system call defines we get this on uml:

arch/um/sys-i386/built-in.o: In function `sys_call_table':
(.rodata+0x308): undefined reference to `sys_sigprocmask'

Reason for this is that uml passes the preprocessor option -Dsigprocmask=kernel_sigprocmask to gcc when compiling the kernel. This causes SYSCALL_DEFINE3(sigprocmask, ...) to be expanded to SYSCALL_DEFINEx(3, kernel_sigprocmask, ...) and finally to a system call named sys_kernel_sigprocmask. However sys_sigprocmask is missing because of this.
To avoid macro expansion for the system call name just concatenate the name at first define instead of carrying it through severel levels. This was pointed out by Al Viro.

Signed-off-by Heiko Carstens <[email protected]>

---
 include/linux/syscalls.h |   28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

include/linux/syscalls.h +14 ~~-14~~

Index: linux-2.6/include/linux/syscalls.h
===================================================================
@@ -95,13 +95,13 @@ struct old_linux_dirent;
 #define __SC_TEST5(t5, a5, ...)	__SC_TEST(t5); __SC_TEST4(__VA_ARGS__)
 #define __SC_TEST6(t6, a6, ...)	__SC_TEST(t6); __SC_TEST5(__VA_ARGS__)
 
-#define SYSCALL_DEFINE0(name)   asmlinkage long sys_##name(void)
-#define SYSCALL_DEFINE1(...)    SYSCALL_DEFINEx(1, __VA_ARGS__)
-#define SYSCALL_DEFINE2(...)    SYSCALL_DEFINEx(2, __VA_ARGS__)
-#define SYSCALL_DEFINE3(...)    SYSCALL_DEFINEx(3, __VA_ARGS__)
-#define SYSCALL_DEFINE4(...)    SYSCALL_DEFINEx(4, __VA_ARGS__)
-#define SYSCALL_DEFINE5(...)    SYSCALL_DEFINEx(5, __VA_ARGS__)
-#define SYSCALL_DEFINE6(...)    SYSCALL_DEFINEx(6, __VA_ARGS__)
+#define SYSCALL_DEFINE0(name)	   asmlinkage long sys_##name(void)
+#define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)
+#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
+#define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)
+#define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)
+#define SYSCALL_DEFINE5(name, ...) SYSCALL_DEFINEx(5, _##name, __VA_ARGS__)
+#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
 
 #ifdef CONFIG_PPC64
 #define SYSCALL_ALIAS(alias, name)					\

@@ -121,21 +121,21 @@ struct old_linux_dirent;
 
 #define SYSCALL_DEFINE(name) static inline long SYSC_##name
 #define SYSCALL_DEFINEx(x, name, ...)					\
-	asmlinkage long sys_##name(__SC_DECL##x(__VA_ARGS__));		\
-	static inline long SYSC_##name(__SC_DECL##x(__VA_ARGS__));	\
-	asmlinkage long SyS_##name(__SC_LONG##x(__VA_ARGS__))		\
+	asmlinkage long sys##name(__SC_DECL##x(__VA_ARGS__));		\
+	static inline long SYSC##name(__SC_DECL##x(__VA_ARGS__));	\
+	asmlinkage long SyS##name(__SC_LONG##x(__VA_ARGS__))		\
 	{								\
 		__SC_TEST##x(__VA_ARGS__);				\
-		return (long) SYSC_##name(__SC_CAST##x(__VA_ARGS__));	\
+		return (long) SYSC##name(__SC_CAST##x(__VA_ARGS__));	\
 	}								\
-	SYSCALL_ALIAS(sys_##name, SyS_##name);				\
-	static inline long SYSC_##name(__SC_DECL##x(__VA_ARGS__))
+	SYSCALL_ALIAS(sys##name, SyS##name);				\
+	static inline long SYSC##name(__SC_DECL##x(__VA_ARGS__))
 
 #else /* CONFIG_HAVE_SYSCALL_WRAPPERS */
 
 #define SYSCALL_DEFINE(name) asmlinkage long sys_##name
 #define SYSCALL_DEFINEx(x, name, ...)					\
-	asmlinkage long sys_##name(__SC_DECL##x(__VA_ARGS__))
+	asmlinkage long sys##name(__SC_DECL##x(__VA_ARGS__))
 
 #endif /* CONFIG_HAVE_SYSCALL_WRAPPERS */

Américo Wang

author

2009-02-08 09:07 UTC #14 lore raw

I am sorry for the delay.

Quoted 24 lines · Heiko Carstens

Quoted 8 lines · On Wed, 4 Feb 2009 21:54:12 +0100 (CET) Geert Uytterhoeven…
I verified that Shane's solution:
#define sys_sigprocmask sys_kernel_sigprocmask
works for me, but that's definitely not the cleanest way.
Al Viro also had a suggestion to rework the SYSCALL_DEFINE* macros, but I haven't tried it yet.
Patch below should fix it.
Subject: [PATCH] syscall define: fix uml compile bug
From: Heiko Carstens <[email protected]>
With the new system call defines we get this on uml:
arch/um/sys-i386/built-in.o: In function `sys_call_table':
(.rodata+0x308): undefined reference to `sys_sigprocmask'

Quoted 6 lines

Reason for this is that uml passes the preprocessor option -Dsigprocmask=kernel_sigprocmask to gcc when compiling the kernel. This causes SYSCALL_DEFINE3(sigprocmask, ...) to be expanded to SYSCALL_DEFINEx(3, kernel_sigprocmask, ...) and finally to a system call named sys_kernel_sigprocmask. However sys_sigprocmask is missing because of this.

Hmmm, thanks for analysis this.

I found my mistake, I thought the Makefile invokes the 'strip' command to do replacement, but it is not, Makefile has a built-in command named strip. Sorry for this.

Then the problem is fully from preprocessing.

Quoted 4 lines

To avoid macro expansion for the system call name just concatenate the name at first define instead of carrying it through severel levels. This was pointed out by Al Viro.

Yes, indeed!

Quoted 1 line

Signed-off-by Heiko Carstens <[email protected]>

Your patch should fix this problem. But... see below.

include/linux/syscalls.h struct old_linux_dirent; · line 132

Quoted 5 lines

	}								\

include/linux/syscalls.h +2 -2

-	SYSCALL_ALIAS(sys_##name, SyS_##name);				\
-	static inline long SYSC_##name(__SC_DECL##x(__VA_ARGS__))
+	SYSCALL_ALIAS(sys##name, SyS##name);				\
+	static inline long SYSC##name(__SC_DECL##x(__VA_ARGS__))

So your final actual name for a syscall 'foo' will be 'sysfoo' instead of 'sys_foo', right?

But we have lots of explicit calls to something like sys_foo, won't your patch break them?

Signature · 13 lines

"Against stupidity, the gods themselves, contend in vain."


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Américo Wang

author Reviewed-by WANG Cong

2009-02-08 09:12 UTC #15 lore raw

Quoted 10 lines · Américo Wang

include/linux/syscalls.h struct old_linux_dirent; · line 132
Quoted 6 lines
	}								\
include/linux/syscalls.h +2 -2
-	SYSCALL_ALIAS(sys_##name, SyS_##name);				\
-	static inline long SYSC_##name(__SC_DECL##x(__VA_ARGS__))
+	SYSCALL_ALIAS(sys##name, SyS##name);				\
+	static inline long SYSC##name(__SC_DECL##x(__VA_ARGS__))
So your final actual name for a syscall 'foo' will be 'sysfoo' instead of 'sys_foo', right?

Oops, I misread the leading underscore! Sorry.

Looks good then,

Reviewed-by WANG Cong <[email protected]>

Signature · 13 lines

"Against stupidity, the gods themselves, contend in vain."


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Geert Uytterhoeven

Acked-by

2009-02-12 14:40 UTC #16 lore raw

In reply to Heiko Carstens

Quoted 6 lines · Heiko Carstens

Quoted 4 lines · On Wed, 4 Feb 2009 21:54:12 +0100 (CET) Geert Uytterhoeven…
I verified that Shane's solution:
#define sys_sigprocmask sys_kernel_sigprocmask

Quoted 7 lines

Quoted 4 lines
works for me, but that's definitely not the cleanest way.
Al Viro also had a suggestion to rework the SYSCALL_DEFINE* macros, but I haven't tried it yet.
Patch below should fix it.

Thanks! I only managed to try it a few minutes ago...

Quoted 19 lines

Subject: [PATCH] syscall define: fix uml compile bug
From: Heiko Carstens <[email protected]>
With the new system call defines we get this on uml:
arch/um/sys-i386/built-in.o: In function `sys_call_table':
(.rodata+0x308): undefined reference to `sys_sigprocmask'
Reason for this is that uml passes the preprocessor option -Dsigprocmask=kernel_sigprocmask to gcc when compiling the kernel. This causes SYSCALL_DEFINE3(sigprocmask, ...) to be expanded to SYSCALL_DEFINEx(3, kernel_sigprocmask, ...) and finally to a system call named sys_kernel_sigprocmask. However sys_sigprocmask is missing because of this.
To avoid macro expansion for the system call name just concatenate the name at first define instead of carrying it through severel levels. This was pointed out by Al Viro.

Quoted 1 line

Signed-off-by Heiko Carstens <[email protected]>

For the record:

Acked-by Geert Uytterhoeven <[email protected]>

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   [email protected]
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010

Américo Wang

author

2009-01-18 08:33 UTC #17 lore raw

In reply to Rob Landley

Quoted 43 lines · Rob Landley

Quoted 10 lines · On Friday 16 January 2009 14:41:58 Andrew Morton wrote:
Quoted 10 lines
(quoted diff) +0 -0
b/arch/um/sys-i386/sys_call_table.S index 00e5f52..04147dc 100644
arch/um/sys-i386/sys_call_table.S +1 -0
@@ -6,6 +6,7 @@
 
 #define sys_vm86old sys_ni_syscall
 #define sys_vm86 sys_ni_syscall
+#define sys_sigprocmask sigprocmask
 
Quoted 5 lines
arch/um/sys-i386/sys_call_table.S line 11
Quoted 1 line
arch/um/sys-i386/sys_call_table.S +0 -0
 #define old_mmap old_mmap_i386
For how long has this problem been present?
Why aren't lots of other people reporting it?
I'm not sure User Mode Linux still has a lot of users regularly testing the latest and greatest version. (QEMU and KVM kinda took the wind out of its sails.)
I still find it useful to be able to stick printfs into the code and debug stuff even when the console isn't working, but I haven't been able to build a version of 2.6.28 that works for me at all:
cat > mini.conf << EOF
CONFIG_BINFMT_ELF=y
CONFIG_HOSTFS=y
CONFIG_LBD=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_LOOP=y CONFIG_STDERR_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_STATIC_LINK=y
CONFIG_NO_HZ=y
CONFIG_UNEVICTABLE_LRU=y
EOF
make ARCH=um allnoconfig KCONFIG_ALLCONFIG=mini.conf make ARCH=um -j 3
./linux rw init=/bin/bash rootfstype=hostfs

Quoted 3 lines

The result panics (twice) and exits, instead of giving me a shell prompt. Built and run on stock Ubuntu 8.10. (I posted about it on tuesday, but nobody replied...)

Hi, Rob.

I tried what you said, it works very fine here, on my Fedora 10. Could you please tell us which kernel your host is using? and the guest?

Thanks for your feedback.

Signature · 12 lines

"Against stupidity, the gods themselves, contend in vain."


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Rob Landley

2009-01-18 23:29 UTC #18 lore raw

Quoted 8 lines · On Sunday 18 January 2009 02:32:37 Américo Wang wrote:

Quoted 3 lines
The result panics (twice) and exits, instead of giving me a shell prompt. Built and run on stock Ubuntu 8.10. (I posted about it on tuesday, but nobody replied...)
Hi, Rob.
I tried what you said, it works very fine here, on my Fedora 10. Could you please tell us which kernel your host is using?

Ubuntu 8.10 stock kernel, calls itself "2.6.27-9-generic".

Quoted 1 line

and the guest?

Quoted 2 lines · it

Linux version 2.6.28 (landley@driftwood) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) ) #6 Tue Jan 13 01:54:34 CST 2009

It's the vanilla tarball (albeit extracted from source control according to the v2.6.28 tag rather than downloaded).

Possibly a gcc 4.3 issue?

Rob

Américo Wang

author

2009-01-22 16:13 UTC #19 lore raw

Quoted 14 lines · Rob Landley

Quoted 8 lines · On Sunday 18 January 2009 02:32:37 Américo Wang wrote:
Quoted 3 lines
The result panics (twice) and exits, instead of giving me a shell prompt. Built and run on stock Ubuntu 8.10. (I posted about it on tuesday, but nobody replied...)
Hi, Rob.
I tried what you said, it works very fine here, on my Fedora 10. Could you please tell us which kernel your host is using?
Ubuntu 8.10 stock kernel, calls itself "2.6.27-9-generic".
Quoted 1 line
and the guest?

Quoted 7 lines

Quoted 2 lines · it
Linux version 2.6.28 (landley@driftwood) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) ) #6 Tue Jan 13 01:54:34 CST 2009
It's the vanilla tarball (albeit extracted from source control according to the v2.6.28 tag rather than downloaded).

I will try 2.6.28.

Quoted 2 lines

Possibly a gcc 4.3 issue?

I don't know. :)

Signature · 12 lines

"Against stupidity, the gods themselves, contend in vain."


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel