lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 19 Jan 2009 19:01:07 -0700
From:	Shane Hathaway <shane@...hawaymix.org>
To:	Daolong Wang <ahlongxp@...il.com>
CC:	Jeff Dike <jdike@...toit.com>, Rob Landley <rob@...dley.net>,
	user-mode-linux-devel@...ts.sourceforge.net,
	Andrew Morton <akpm@...ux-foundation.org>,
	Am?rico Wang <xiyou.wangcong@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [uml-devel] [Patch] uml: fix a link error

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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ