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

(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 ;)

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.

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

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

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.

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

(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 ;)

(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. :-)

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

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

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

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?

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

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

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

kernel-2.6.40.3-0.fc15 in testing seems do fix this UML problem for me.
Thanks

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.

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.