[Bug 339743] Re: Jaunty i386 popen() misbehaves on x86_64 kernel 2.6.26
Bug Watch Updater
339743 at bugs.launchpad.net
Fri Oct 27 10:20:41 UTC 2017
Launchpad has imported 7 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=484871.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2009-02-10T12:46:07+00:00 Vitaly wrote:
+++ This bug was initially created as a clone of Bug #481682 +++
Created an attachment (id=330051)
proposed fix
in kernel-2.6.18-128.el5 and prior versions, arch/x86_64/ia32/ia32entry.S hunk of the linux-2.6-misc-utrace-update.patch contains incorrect optimization.
As result, out-of-table 32-bit syscalls on the x86_64 kernel do not return ENOSYS (unless the caller is being ptraced).
For example, glibc-2.9+ popen() goes mad when pipe2 syscall returns its number 331 instead of fail with ENOSYS.
As result, FC10+ 32-bit processes on RHEL5 x86_64 kernel break once popen(3) is called.
--- Additional comment from kir at sacred.ru on 2009-01-27 04:29:59 EDT ---
The issue was found while running Fedora 10 containers on an
RHEL5+OpenVZ kernel.
Relative OpenVZ bug: http://bugzilla.openvz.org/show_bug.cgi?id=1150
--- Additional comment from roland at redhat.com on 2009-02-06 20:59:52 EDT
---
Created an attachment (id=331182)
test case source
Simple test case, compile with -m32 and run on x86-64 kernel.
The RHEL5 code is the same (broken) as upstream. I'll fix it upstream
and then RHEL5 should backport the change so it continues to match
upstream.
--- Additional comment from roland at redhat.com on 2009-02-06 21:02:48 EDT
---
Created an attachment (id=331183)
test case source
Test case fixed to exit 0 for correct and nonzero for bug.
Also, I forgot to note that to reproduce you have to have auditd disabled:
/sbin/chkconfig auditd off; reboot
--- Additional comment from roland at redhat.com on 2009-02-06 21:34:13 EDT
---
Created an attachment (id=331187)
fix posted upstream
Wait to see if upstream takes this as is, but almost certain they will.
With s,/x86/,/x86_64/,g this same patch applies to RHEL5 fine.
--- Additional comment from vmayatsk at redhat.com on 2009-02-07 04:57:47
EDT ---
> The RHEL5 code is the same (broken) as upstream.
RHEL5 is not broken, I wasn't able to reproduce it. As I understood,
this is due to this check:
testl $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP),threadinfo_flags(%r10)
jnz ia32_tracesys
And we have TIF_SYSCALL_AUDIT set.
Also, it's possible to make the patch shorter:
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -417,6 +417,7 @@ ENTRY(ia32_syscall)
GET_THREAD_INFO(%r10)
orl $TS_COMPAT,TI_status(%r10)
testl $_TIF_WORK_SYSCALL_ENTRY,TI_flags(%r10)
+ movq $-ENOSYS,RAX-ARGOFFSET(%rsp)
jnz ia32_tracesys
ia32_do_syscall:
cmpl $(IA32_NR_syscalls-1),%eax
I've tested it yesterday, but didn't post upstream yet.
--- Additional comment from roland at redhat.com on 2009-02-07 17:21:41 EDT
---
It is broken. See comment#3 on how to reproduce it.
Shorter patch does not mean shorter code path, which is what matters.
Anyway, I've already posted upstream.
--- Additional comment from roland at redhat.com on 2009-02-07 17:25:55 EDT
---
Upstream fix was merged:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c09249f8d1b84344eca882547afdbffee8c09d14
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/339743/comments/0
------------------------------------------------------------------------
On 2009-02-10T20:15:14+00:00 Roland wrote:
I don't know what the point of this bug report is. The fix is already
in upstream, and rawhide rebases from upstream daily.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/339743/comments/1
------------------------------------------------------------------------
On 2009-02-10T21:34:21+00:00 Chuck wrote:
I think you want to file this bug against Fedora 10 ??
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/339743/comments/2
------------------------------------------------------------------------
On 2009-02-12T15:28:24+00:00 Vitaly wrote:
(In reply to comment #2)
> I think you want to file this bug against Fedora 10 ??
Yes. I don't know if this will be backported to 2.6.27.x
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/339743/comments/3
------------------------------------------------------------------------
On 2009-02-18T07:57:17+00:00 Chuck wrote:
Fixed in 2.6.27.18-170.2.28 and will send to -stable.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/339743/comments/4
------------------------------------------------------------------------
On 2009-02-24T20:53:34+00:00 Fedora wrote:
kernel-2.6.27.19-170.2.35.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2003
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/339743/comments/5
------------------------------------------------------------------------
On 2009-03-02T16:56:38+00:00 Fedora wrote:
kernel-2.6.27.19-170.2.35.fc10 has been pushed to the Fedora 10 stable
repository. If problems still persist, please make note of it in this
bug report.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/339743/comments/6
** Changed in: fedora
Importance: Unknown => Medium
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/339743
Title:
Jaunty i386 popen() misbehaves on x86_64 kernel 2.6.26
Status in OpenVZ kernel:
Fix Released
Status in glibc package in Ubuntu:
Invalid
Status in linux package in Ubuntu:
Fix Released
Status in glibc source package in Intrepid:
Invalid
Status in linux source package in Intrepid:
Fix Released
Status in glibc source package in Jaunty:
Invalid
Status in linux source package in Jaunty:
Fix Released
Status in linux-2.6 package in Debian:
Fix Released
Status in Fedora:
Fix Released
Bug description:
SRU justification:
Impact: A bug in the syscall implementation can cause incorrect
behavior when trying to use syscalls that are not implemented.
Fix: Cherry pick from upstream to correctly return an error code in
that situation.
Testcase: see test below.
---
There is something very wrong with the popen() implementation in
Jaunty on i386. It works fine when run on the Jaunty kernel, but when
run on the Lenny 2.6.26-1-amd64 kernel, it misbehaves as follows. The
output of the subcommand, instead of being fed to the pipe, is fed
directly to stdout; the pipe either returns errors or hangs forever.
This causes weird errors in many programs running in a Jaunty i386
chroot on our Lenny build server.
Attached is a small 5-line test program. Run
gcc -static popen-test.c -o popen-test
and then copy popen-test to a Lenny machine to see the problem.
Correct output:
$ uname -r
2.6.28-8-generic
$ ./popen-test
popen returned 0x1ec6400
ferror returned 0
fread returned 19
ferror returned 0
pclose returned 0
Incorrect output:
$ uname -r
2.6.26-1-amd64
$ ./popen-test
popen returned 0x935f688
ferror returned 0
SHOULD NOT DISPLAY
This has been reproduced independently by two of us with two different
Jaunty i386 installs and two different Lenny installs.
To manage notifications about this bug go to:
https://bugs.launchpad.net/openvz-kernel/+bug/339743/+subscriptions
More information about the foundations-bugs
mailing list