[Patch] uml: fix a link error

[Patch] uml: fix a link error

[Américo Wang]

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 <wangcong@zeuux.org>
Cc: Jeff Dike <jdike@addtoit.com>

---
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
 

Re: [Patch] uml: fix a link error

[Andrew Morton]

On Thu, 15 Jan 2009 19:40:33 +0000
Am__rico Wang <xiyou.wangcong@gmail.com> 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 <wangcong@zeuux.org>
> Cc: Jeff Dike <jdike@addtoit.com>
> 
> ---
> 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?

Re: [Patch] uml: fix a link error

[Jeff Dike]

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 <xiyou.wangcong@gmail.com> 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

Re: [uml-devel] [Patch] uml: fix a link error

[Rob Landley]

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

Re: [uml-devel] [Patch] uml: fix a link error

[Daolong Wang]

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

On Sat, Jan 17, 2009 at 5:28 PM, Rob Landley <rob@landley.net> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [uml-devel] [Patch] uml: fix a link error

[Jeff Dike]

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

Re: [uml-devel] [Patch] uml: fix a link error

[Daolong Wang]

On Mon, Jan 19, 2009 at 11:21 PM, Jeff Dike <jdike@addtoit.com> 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
>

Re: [uml-devel] [Patch] uml: fix a link error

[Shane Hathaway]

Daolong Wang wrote:
> On Mon, Jan 19, 2009 at 11:21 PM, Jeff Dike <jdike@addtoit.com> 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

Re: [uml-devel] [Patch] uml: fix a link error

[Al Viro]

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.

Re: [uml-devel] [Patch] uml: fix a link error

[Geert Uytterhoeven]

On Mon, 19 Jan 2009, Shane Hathaway wrote:
> Daolong Wang wrote:
> > On Mon, Jan 19, 2009 at 11:21 PM, Jeff Dike <jdike@addtoit.com> 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:   Geert.Uytterhoeven@sonycom.com
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

Re: [uml-devel] [Patch] uml: fix a link error

[Geert Uytterhoeven]

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 <jdike@addtoit.com> 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 <heiko.carstens@de.ibm.com>
| Date:   Wed Jan 14 14:14:06 2009 +0100
| 
|     System call wrappers part 04
|     
|     commit b290ebe2c46d01b742b948ce03f09e8a3efb9a92 upstream.
|     
|     Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
|     Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| 
| --- 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 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [uml-devel] [Patch] uml: fix a link error

[Greg KH]

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 <jdike@addtoit.com> 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 <heiko.carstens@de.ibm.com>
> | Date:   Wed Jan 14 14:14:06 2009 +0100
> | 
> |     System call wrappers part 04
> |     
> |     commit b290ebe2c46d01b742b948ce03f09e8a3efb9a92 upstream.
> |     
> |     Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
> |     Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> | 
> | --- 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

Re: [uml-devel] [Patch] uml: fix a link error

[Geert Uytterhoeven]

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 <jdike@addtoit.com> 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 <heiko.carstens@de.ibm.com>
> > | Date:   Wed Jan 14 14:14:06 2009 +0100
> > | 
> > |     System call wrappers part 04
> > |     
> > |     commit b290ebe2c46d01b742b948ce03f09e8a3efb9a92 upstream.
> > |     
> > |     Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
> > |     Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > | 
> > | --- 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 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [uml-devel] [Patch] uml: fix a link error

[Heiko Carstens]

On Wed, 4 Feb 2009 21:54:12 +0100 (CET)
Geert Uytterhoeven <geert@linux-m68k.org> 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 <heiko.carstens@de.ibm.com>

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 <heiko.carstens@de.ibm.com>
---
 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 */
 

Re: [uml-devel] [Patch] uml: fix a link error

[Américo Wang]

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 <geert@linux-m68k.org> 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 <heiko.carstens@de.ibm.com>
>
>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 <heiko.carstens@de.ibm.com>


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."

Re: [uml-devel] [Patch] uml: fix a link error

[Américo Wang]

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 <wangcong@zeuux.org>


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

Re: [uml-devel] [Patch] uml: fix a link error

[Geert Uytterhoeven]

On Sat, 7 Feb 2009, Heiko Carstens wrote:
> On Wed, 4 Feb 2009 21:54:12 +0100 (CET)
> Geert Uytterhoeven <geert@linux-m68k.org> 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 <heiko.carstens@de.ibm.com>
> 
> 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 <heiko.carstens@de.ibm.com>

For the record:

Acked-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>

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:   Geert.Uytterhoeven@sonycom.com
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

Re: [uml-devel] [Patch] uml: fix a link error

[Américo Wang]

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."

Re: [uml-devel] [Patch] uml: fix a link error

[Rob Landley]

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

Re: [uml-devel] [Patch] uml: fix a link error

[Américo Wang]

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."