Bug 728379 - Kernel 2.6.40 breaks UserModeLinux
Kernel 2.6.40 breaks UserModeLinux
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
15
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-04 17:10 EDT by Richard Weinberger
Modified: 2011-08-22 10:51 EDT (History)
10 users (show)

See Also:
Fixed In Version: kernel-3.0.1-3.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-17 13:05:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Richard Weinberger 2011-08-04 17:10:54 EDT
FC15's kernel 2.6.40 breaks UML.

Starting linux fails very early with this error message:

---cut---
Locating the bottom of the address space ... 0x10000
Locating the top of the address space ... 0xffffd000
Core dump limits :
      soft - 0
      hard - NONE
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...check_sysemu : expected SIGTRAP, got status = 2943
---cut---

UML works fine on a vanilla 3.0 kernel.
Maybe 2.6.40 contains some ptrace() related patches?

How reproducible:
Always.

Steps to Reproduce:
1. make defconfig ARCH=um
2. make linux ARCH=um
3. ./linux rootfstype=hostfs init=/bin/sh
Comment 1 Josh Boyer 2011-08-04 21:09:33 EDT
(In reply to comment #0)
> FC15's kernel 2.6.40 breaks UML.
> 
> Starting linux fails very early with this error message:
> 
> ---cut---
> Locating the bottom of the address space ... 0x10000
> Locating the top of the address space ... 0xffffd000
> Core dump limits :
>       soft - 0
>       hard - NONE
> Checking that ptrace can change system call numbers...OK
> Checking syscall emulation patch for ptrace...check_sysemu : expected SIGTRAP,
> got status = 2943
> ---cut---
> 
> UML works fine on a vanilla 3.0 kernel.
> Maybe 2.6.40 contains some ptrace() related patches?

2.6.40 has the utrace patches applied.

Oleg, do you know if utrace could cause such issues with UML?
Comment 2 Oleg Nesterov 2011-08-05 10:14:14 EDT
(In reply to comment #1)
> (In reply to comment #0)
>
> > Checking syscall emulation patch for ptrace...check_sysemu : expected SIGTRAP,
> > got status = 2943
> > ---cut---
> > 
> > UML works fine on a vanilla 3.0 kernel.
> > Maybe 2.6.40 contains some ptrace() related patches?
> 
> 2.6.40 has the utrace patches applied.
> 
> Oleg, do you know if utrace could cause such issues with UML?

Yes, looks like this is utrace problem...

I never used uml and know nothing about it. I guess, this is
arch/um/os-Linux/start_up.c ? perhaps I can make the simple
user-space test-case...

I'll try to fix. Or at least understand what is the problem ;)
Comment 3 Richard Weinberger 2011-08-05 10:29:03 EDT
Yes, arch/um/os-Linux/start_up.c does some checks on ptrace(), you can use it as test case.

Feel free to ask me whenever you need some help with UML.
Comment 4 Oleg Nesterov 2011-08-05 13:05:59 EDT
(In reply to comment #3)
> Yes, arch/um/os-Linux/start_up.c does some checks on ptrace(), you can use it
> as test case.

I am puzzled. The code in start_up.c is quite understandable,
and the related kernel code is simple. I don't understand what
happens.

And. According to the messages from #1 it fails very quickly,
after the first PTRACE_SYSEMU, so this simple test-case

	int main(void)
	{
		int status;
		int pid = fork();

		if (!pid) {
			assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
			kill(getpid(), SIGSTOP);

			pid = getppid();

			return 23;
		}

		assert(wait(&status) == pid);
		assert(status = 0x137f);

		assert(ptrace(PTRACE_SYSEMU, pid, 0,0) == 0);
		assert(wait(&status) == pid);

		if (status != 0x57f)
			printf("ERR!! status=%x\n", status);

		kill(pid, SIGKILL);
		return 0;
	}

should also fail.

But it doesn't! (tested on 3.0 + utrace under kvm)

I am reserving the testing machine with FC15. Meanwhile, any chance
you can run the test-case above?
Comment 5 Gordon Russell 2011-08-05 14:06:38 EDT
(In reply to comment #4)
> 
> I am reserving the testing machine with FC15. Meanwhile, any chance
> you can run the test-case above?

Assuming that the following code is the right things to include at the start of your code to allow it to compile:


#include <stdio.h>
#include <stdlib.h>
#include <sys/ptrace.h>
#include <unistd.h>
#include <sys/types.h>
#include <signal.h>
#include <assert.h>
#include <sys/types.h>
#include <sys/wait.h>
#define PTRACE_SYSEMU 31


And then compile with:
  g++ test.c -fpermissive

Then the output for me on fc15 with latest updates and kernel 2.6.40-4.fc15.x86_64 is for me:
  ERR!! status=b7f

I hope thats useful.
Comment 6 Gordon Russell 2011-08-05 14:35:50 EDT
Note I am not a big user of "assert" but should the line:
  assert(status = 0x137f);
not be
  assert(status == 0x137f);

Note this makes no difference, as this part of the test is fine.

If it helps b7f seems to correspond to SIGSEGV rather than SIGTRAP.
Comment 7 Oleg Nesterov 2011-08-05 14:39:14 EDT
> But it doesn't! (tested on 3.0 + utrace under kvm)

However, it does fail on FC15.

Heh. it turns out, utrace.patch which comes with
kernel-2.6.40-4.fc15.src.rpm is wrong (at least incomplete).
In particular it doesn't include this patch:

    http://git.kernel.org/?p=linux/kernel/git/oleg/misc.git;a=commit;h=e2c09b0cfcf0fc65b72937f1dac7e601ef2480e9

from urace for 3.0 branch. This explains the problem.
I'll contact the maintainers.
Comment 8 Oleg Nesterov 2011-08-05 14:51:25 EDT
(In reply to comment #5)
>
> Then the output for me on fc15 with latest updates and kernel
> 2.6.40-4.fc15.x86_64 is for me:
>   ERR!! status=b7f
> 
> I hope thats useful.

It is, thanks. This matches my testing. Please see #7

> should the line:
> assert(status = 0x137f);
> not be
> assert(status == 0x137f);

indeed, this check is buggy ;)
Comment 9 Richard Weinberger 2011-08-05 17:42:24 EDT
(In reply to comment #7)
> > But it doesn't! (tested on 3.0 + utrace under kvm)
> 
> However, it does fail on FC15.
> 
> Heh. it turns out, utrace.patch which comes with
> kernel-2.6.40-4.fc15.src.rpm is wrong (at least incomplete).
> In particular it doesn't include this patch:
> 
>    
> http://git.kernel.org/?p=linux/kernel/git/oleg/misc.git;a=commit;h=e2c09b0cfcf0fc65b72937f1dac7e601ef2480e9
> 
> from urace for 3.0 branch. This explains the problem.
> I'll contact the maintainers.

Oleg,

Thanks for looking the the issue!

BTW: Where can I find the most current utrace patch set?
I'm interested how utrace affects UML's performance.
A fast ptrace() implies also a fast UML. :-)
Comment 10 Oleg Nesterov 2011-08-07 15:26:28 EDT
(In reply to comment #9)
>
> BTW: Where can I find the most current utrace patch set?

git://git.kernel.org/pub/scm/linux/kernel/git/oleg/misc.git utrace-3.1

> I'm interested how utrace affects UML's performance.
> A fast ptrace() implies also a fast UML. :-)

Unfortunately, utrace can't make ptrace faster. It doesn't even try,
this was never a goal.

Most probably uml could use utrace directly to speed up.
Comment 11 Fedora Update System 2011-08-08 20:05:12 EDT
kernel-3.0.1-3.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/kernel-3.0.1-3.fc16
Comment 12 Fedora Update System 2011-08-08 22:53:39 EDT
Package kernel-3.0.1-3.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kernel-3.0.1-3.fc16'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/kernel-3.0.1-3.fc16
then log in and leave karma (feedback).
Comment 13 Gordon Russell 2011-08-09 04:05:26 EDT
This bug is with 2.6.40 in fc15. 
But this update to fix the bug is to fc16. 
Can we not have this as an update for fc15?
Comment 14 Josh Boyer 2011-08-09 07:33:55 EDT
(In reply to comment #13)
> This bug is with 2.6.40 in fc15. 
> But this update to fix the bug is to fc16. 
> Can we not have this as an update for fc15?

It's already committed to the f15 branch.  The next build that is submitted should have it fixed.
Comment 15 Boaz Harrosh 2011-08-11 18:52:04 EDT
We need this very urgent in f15, since currently the latest Kernel is not usable and the kmode-nvidia package tries to pull it in. (And the nouveau driver has bad bugs with my video card)

Can't we push this fix ASAP, like in a few days? When is the "next build" scheduled to be released?

Thanks
Boaz
Comment 16 Fedora Update System 2011-08-16 08:46:34 EDT
kernel-2.6.40.3-0.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/kernel-2.6.40.3-0.fc15
Comment 17 Gordon Russell 2011-08-17 05:13:11 EDT
kernel-2.6.40.3-0.fc15 in testing seems do fix this UML problem for me.
Thanks
Comment 18 Fedora Update System 2011-08-17 22:29:29 EDT
kernel-2.6.40.3-0.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 19 Fedora Update System 2011-08-22 10:50:40 EDT
kernel-3.0.1-3.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.