From: Américo W. <xiy...@gm...> - 2009-01-15 13:12:58
|
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 <wan...@ze...> Cc: Jeff Dike <jd...@ad...> --- diff --git a/arch/um/sys-i386/sys_call_table.S b/arch/um/sys-i386/sys_call_table.S index 00e5f52..04147dc 100644 --- a/arch/um/sys-i386/sys_call_table.S +++ b/arch/um/sys-i386/sys_call_table.S @@ -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 |
From: Andrew M. <ak...@li...> - 2009-01-16 20:42:11
|
On Thu, 15 Jan 2009 19:40:33 +0000 Am__rico Wang <xiy...@gm...> wrote: > > 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 <wan...@ze...> > Cc: Jeff Dike <jd...@ad...> > > --- > diff --git a/arch/um/sys-i386/sys_call_table.S b/arch/um/sys-i386/sys_call_table.S > index 00e5f52..04147dc 100644 > --- a/arch/um/sys-i386/sys_call_table.S > +++ b/arch/um/sys-i386/sys_call_table.S > @@ -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? |
From: Jeff D. <jd...@ad...> - 2009-01-16 22:49:28
|
On Fri, Jan 16, 2009 at 12:41:58PM -0800, Andrew Morton wrote: > On Thu, 15 Jan 2009 19:40:33 +0000 > Am__rico Wang <xiy...@gm...> wrote: > > #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? 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 |
From: Rob L. <ro...@la...> - 2009-01-17 20:46:50
|
On Friday 16 January 2009 14:41:58 Andrew Morton wrote: > > diff --git a/arch/um/sys-i386/sys_call_table.S > > b/arch/um/sys-i386/sys_call_table.S index 00e5f52..04147dc 100644 > > --- a/arch/um/sys-i386/sys_call_table.S > > +++ b/arch/um/sys-i386/sys_call_table.S > > @@ -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? 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 |
From: Daolong W. <ahl...@gm...> - 2009-01-18 06:23:56
|
I can confirm this link error. And this patch works for me. On Sat, Jan 17, 2009 at 5:28 PM, Rob Landley <ro...@la...> wrote: > On Friday 16 January 2009 14:41:58 Andrew Morton wrote: >> > diff --git a/arch/um/sys-i386/sys_call_table.S >> > b/arch/um/sys-i386/sys_call_table.S index 00e5f52..04147dc 100644 >> > --- a/arch/um/sys-i386/sys_call_table.S >> > +++ b/arch/um/sys-i386/sys_call_table.S >> > @@ -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? > > 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 > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to maj...@vg... > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > |
From: Américo W. <xiy...@gm...> - 2009-02-08 09:07:16
|
I am sorry for the delay. On Sat, Feb 07, 2009 at 12:59:56PM +0100, Heiko Carstens wrote: >On Wed, 4 Feb 2009 21:54:12 +0100 (CET) >Geert Uytterhoeven <ge...@li...> wrote: >> 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 <hei...@de...> > >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. 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. >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! >Signed-off-by: Heiko Carstens <hei...@de...> Your patch should fix this problem. But... see below. > } \ >- 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? -- "Against stupidity, the gods themselves, contend in vain." |
From: Américo W. <xiy...@gm...> - 2009-02-08 09:12:55
|
On Sun, Feb 08, 2009 at 05:07:10PM +0800, Américo Wang wrote: > >> } \ >>- 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 <wan...@ze...> -- "Against stupidity, the gods themselves, contend in vain." |
From: Américo W. <xiy...@gm...> - 2009-01-18 08:33:08
|
On Sat, Jan 17, 2009 at 03:28:14AM -0600, Rob Landley wrote: >On Friday 16 January 2009 14:41:58 Andrew Morton wrote: >> > diff --git a/arch/um/sys-i386/sys_call_table.S >> > b/arch/um/sys-i386/sys_call_table.S index 00e5f52..04147dc 100644 >> > --- a/arch/um/sys-i386/sys_call_table.S >> > +++ b/arch/um/sys-i386/sys_call_table.S >> > @@ -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? > >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...) 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. -- "Against stupidity, the gods themselves, contend in vain." |
From: Rob L. <ro...@la...> - 2009-01-18 23:29:46
|
On Sunday 18 January 2009 02:32:37 Américo Wang wrote: > >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". > and the guest? Checking tuesday's bug report, it said: > 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 |
From: Américo W. <xiy...@gm...> - 2009-01-22 16:13:19
|
On Sun, Jan 18, 2009 at 05:29:30PM -0600, Rob Landley wrote: >On Sunday 18 January 2009 02:32:37 Américo Wang wrote: >> >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". > >> and the guest? > >Checking tuesday's bug report, it said: > >> 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. > >Possibly a gcc 4.3 issue? I don't know. :) -- "Against stupidity, the gods themselves, contend in vain." |
From: Jeff D. <jd...@ad...> - 2009-01-19 15:21:54
|
On Sun, Jan 18, 2009 at 02:23:46PM +0800, Daolong Wang wrote: > I can confirm this link error. In what environment? I see no problems here. > And this patch works for me. Maybe it fixes the link failure. But I really doubt that sigprocmask works. Jeff -- Work email - jdike at linux dot intel dot com |
From: Daolong W. <ahl...@gm...> - 2009-01-20 02:18:05
|
On Mon, Jan 19, 2009 at 11:21 PM, Jeff Dike <jd...@ad...> wrote: > On Sun, Jan 18, 2009 at 02:23:46PM +0800, Daolong Wang wrote: >> 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. >> And this patch works for me. > > Maybe it fixes the link failure. But I really doubt that sigprocmask works. > not sure. compile test only! > Jeff > > -- > Work email - jdike at linux dot intel dot com > |
From: Shane H. <sh...@ha...> - 2009-01-20 03:53:41
|
Daolong Wang wrote: > On Mon, Jan 19, 2009 at 11:21 PM, Jeff Dike <jd...@ad...> wrote: >> On Sun, Jan 18, 2009 at 02:23:46PM +0800, Daolong Wang wrote: >>> 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 |
From: Al V. <viro@ZenIV.linux.org.uk> - 2009-01-27 10:39:59
|
On Mon, Jan 19, 2009 at 07:01:07PM -0700, Shane Hathaway wrote: > 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. |
From: Geert U. <Gee...@so...> - 2009-02-04 17:26:14
|
On Mon, 19 Jan 2009, Shane Hathaway wrote: > Daolong Wang wrote: > > On Mon, Jan 19, 2009 at 11:21 PM, Jeff Dike <jd...@ad...> wrote: > >> On Sun, Jan 18, 2009 at 02:23:46PM +0800, Daolong Wang wrote: > >>> 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. 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: Gee...@so... 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 |
From: Geert U. <ge...@li...> - 2009-02-04 20:33:12
|
On Wed, 4 Feb 2009, Geert Uytterhoeven wrote: > On Mon, 19 Jan 2009, Shane Hathaway wrote: > > Daolong Wang wrote: > > > On Mon, Jan 19, 2009 at 11:21 PM, Jeff Dike <jd...@ad...> wrote: > > >> On Sun, Jan 18, 2009 at 02:23:46PM +0800, Daolong Wang wrote: > > >>> 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. > > 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. 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 <hei...@de...> | Date: Wed Jan 14 14:14:06 2009 +0100 | | System call wrappers part 04 | | commit b290ebe2c46d01b742b948ce03f09e8a3efb9a92 upstream. | | Signed-off-by: Heiko Carstens <hei...@de...> | Signed-off-by: Greg Kroah-Hartman <gr...@su...> | | --- 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 -- ge...@li... 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 |
From: Greg KH <gr...@su...> - 2009-02-04 20:42:23
|
On Wed, Feb 04, 2009 at 09:32:51PM +0100, Geert Uytterhoeven wrote: > On Wed, 4 Feb 2009, Geert Uytterhoeven wrote: > > On Mon, 19 Jan 2009, Shane Hathaway wrote: > > > Daolong Wang wrote: > > > > On Mon, Jan 19, 2009 at 11:21 PM, Jeff Dike <jd...@ad...> wrote: > > > >> On Sun, Jan 18, 2009 at 02:23:46PM +0800, Daolong Wang wrote: > > > >>> 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. > > > > 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. > > 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 <hei...@de...> > | Date: Wed Jan 14 14:14:06 2009 +0100 > | > | System call wrappers part 04 > | > | commit b290ebe2c46d01b742b948ce03f09e8a3efb9a92 upstream. > | > | Signed-off-by: Heiko Carstens <hei...@de...> > | Signed-off-by: Greg Kroah-Hartman <gr...@su...> > | > | --- 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. 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 |
From: Geert U. <ge...@li...> - 2009-02-04 20:54:25
|
On Wed, 4 Feb 2009, Greg KH wrote: > On Wed, Feb 04, 2009 at 09:32:51PM +0100, Geert Uytterhoeven wrote: > > On Wed, 4 Feb 2009, Geert Uytterhoeven wrote: > > > On Mon, 19 Jan 2009, Shane Hathaway wrote: > > > > Daolong Wang wrote: > > > > > On Mon, Jan 19, 2009 at 11:21 PM, Jeff Dike <jd...@ad...> wrote: > > > > >> On Sun, Jan 18, 2009 at 02:23:46PM +0800, Daolong Wang wrote: > > > > >>> 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. > > > > > > 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. > > > > 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 <hei...@de...> > > | Date: Wed Jan 14 14:14:06 2009 +0100 > > | > > | System call wrappers part 04 > > | > > | commit b290ebe2c46d01b742b948ce03f09e8a3efb9a92 upstream. > > | > > | Signed-off-by: Heiko Carstens <hei...@de...> > > | Signed-off-by: Greg Kroah-Hartman <gr...@su...> > > | > > | --- 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. > > 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 -- ge...@li... 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 |
From: Heiko C. <hei...@de...> - 2009-02-07 12:01:19
|
On Wed, 4 Feb 2009 21:54:12 +0100 (CET) Geert Uytterhoeven <ge...@li...> wrote: > 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 <hei...@de...> 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 <hei...@de...> --- include/linux/syscalls.h | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) Index: linux-2.6/include/linux/syscalls.h =================================================================== --- linux-2.6.orig/include/linux/syscalls.h +++ 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 */ |
From: Geert U. <Gee...@so...> - 2009-02-12 14:40:33
|
On Sat, 7 Feb 2009, Heiko Carstens wrote: > On Wed, 4 Feb 2009 21:54:12 +0100 (CET) > Geert Uytterhoeven <ge...@li...> wrote: > > 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. Thanks! I only managed to try it a few minutes ago... > Subject: [PATCH] syscall define: fix uml compile bug > > From: Heiko Carstens <hei...@de...> > > 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 <hei...@de...> For the record: Acked-by: Geert Uytterhoeven <Gee...@so...> 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: Gee...@so... 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 |