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 <[email protected]> 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 <[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.
>
> 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
------------------------------------------------------------------------------
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
