Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
|
[uml-devel] Problems about fork-not-clone (was: Re: [uml-user] UML exits after "tracing thread pid")
From: Blaisorblade <blaisorblade@ya...> - 2005-07-04 16:47:17
|
On Friday 24 June 2005 15:41, Jeff Dike wrote: > On Fri, Jun 24, 2005 at 02:02:24PM +0200, Bernhard Schauer wrote: > > Checking for host processor xmm support...No > > Checking that ptrace can change system call numbers...<0>Kernel panic - > > not syncing: Segfault with no mm > > Revert the fork-not-clone patch: > http://www.ussg.iu.edu/hypermail/linux/kernel/0506.1/0665.html > > The patch isn't wrong exactly - as far as I can see, the compiler is > compiling it slightly differently so that it hits the tt mode vs new libc > errno incompatibility. Ok, can you describe it a bit more detailedly? Also, are you going to drop this patch (or allow me to do this) for now? Since it isn't getting fixed, it seems me a good idea. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
|
From: Jeff Dike <jdike@ad...> - 2005-07-07 13:51:17
|
> Ok, can you describe it a bit more detailedly? > > Also, are you going to drop this patch (or allow me to do this) for now? > Since it isn't getting fixed, it seems me a good idea. I still think the patch is correct. Ben LaHaise sent me a UML binary which crashes, which I can send you if you want to look at it. This thing was looking at errno after the first call to fork even if it succeeded. This leads me to believe that this is a compiler oddity rather than a compiler bug, and that this is causing UML to hit the tt-specific errno crash with recent libcs. You understand that problem more than I do. So, I would say that skas0 is more a fix for this problem than reverting the fork-not-clone patch is. Jeff |
|
From: Blaisorblade <blaisorblade@ya...> - 2005-07-07 18:25:15
|
(Oleg, this is about your problem, and there are some questions for you too, marked with ////////////////////////////, please ACK me about this message). On Thursday 07 July 2005 13:59, Jeff Dike wrote: > > Ok, can you describe it a bit more detailedly? > > Also, are you going to drop this patch (or allow me to do this) for now? > > Since it isn't getting fixed, it seems me a good idea. > I still think the patch is correct. ... > So, I would say that skas0 is more a fix for this problem than > reverting the fork-not-clone patch is. For the question above, and from the "stability" point of view, this does not matter, even because this patch is not a bug-fix (Valgrind users can apply it manually). > Ben LaHaise sent me a UML binary > which crashes, which I can send you if you want to look at it. Ok, thanks. > This thing was looking at errno after the first call to fork even if > it succeeded. Were you debugging it? Was it using the "errno" variable or calling, as it should have done with normal glibc's, __errno_location()? > This leads me to believe that this is a compiler oddity > rather than a compiler bug, and that this is causing UML to hit the > tt-specific errno crash with recent libcs. Mmh, I've read "[uml-user] UML at Fedora Core 4 in TT mode: something wrong with errno." from Oleg, and it describes the problem well: errno remains forever at 0. But the return values are not altered, in that case, i.e. failure is failure and success is success, just errno is not updated. > You understand that > problem more than I do. Ok, I've never seen it on my own, but I guess I understand it anyway. The problem is that: a) .thread_private is ignored by NPTL b) so, while for UML (or at least parts of it) the errno is at one place, for the libraries (which are already linked) the real, thread-specific (TLS) value of errno is used... and using clone()/fork() interferes with this. I guess that in NPTL headers, instead of using __errno_location() the faster "__thread int errno;" is used; Oleg, can you verify this? //////////////////////////////////////////////////////////////////////////////////////////////////////////////// > So, I would say that skas0 is more a fix for this problem than > reverting the fork-not-clone patch is. Wait a moment, the "errno" problem is fixable and currently it should be fixed, for what I can see, the patch is in -rc1... though I have problems with this, which could stem from a SYSEMU bug (see other thread "Please test 2.6.13-rc2 in TT mode!"): is it possible that after calling mmap2(), the value stored in EBX (i.e. the first syscall param) is altered? In fact, this is what seems to happen inside switcheroo() to the "to" param, leading to the routine errouneously failing. This does not happen anywhere else in the UML kernel, it seems. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.beta.messenger.yahoo.com |
|
From: Bernhard Schauer <linux-kernel-list@ac...> - 2005-07-11 07:48:25
|
On Thu, 2005-07-07 at 07:59 -0400, Jeff Dike wrote: > So, I would say that skas0 is more a fix for this problem than > reverting the fork-not-clone patch is. No it isn't. Its an other method not a fix for anything. As long as skas0 is not in kernel mainline and enabled in main distributions, it has no relevance for corporate level (at least in my case). UML gives us the chance to build a compile and debug environment without a relevance on which distribution it runs. The image used to boot UML is a copy for each developer and each of them could compile applications having the same environment as on the target system. |
|
From: Blaisorblade <blaisorblade@ya...> - 2005-07-11 21:14:14
|
On Monday 11 July 2005 09:48, Bernhard Schauer wrote: > On Thu, 2005-07-07 at 07:59 -0400, Jeff Dike wrote: > > So, I would say that skas0 is more a fix for this problem than > > reverting the fork-not-clone patch is. > No it isn't. Its an other method not a fix for anything. I agree on this point, even because SKAS0 is not yet widely deployed / tested. > As long as > skas0 is not in kernel mainline and enabled in main distributions, it > has no relevance for corporate level (at least in my case). > UML gives us the chance to build a compile and debug environment without > a relevance on which distribution it runs. The image used to boot UML is > a copy for each developer and each of them could compile applications > having the same environment as on the target system. There's a bit of misunderstanding: SKAS0 is a patch for UML only, not an host patch. It's numbered "0" because it has "0" dependencies, or because it does not depend on host SKAS patch (nor SKAS1, nor SKAS2, nor SKAS3). -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
|
From: Rob Landley <rob@la...> - 2005-07-12 07:54:10
|
On Monday 11 July 2005 16:21, Blaisorblade wrote:
> > As long as
> > skas0 is not in kernel mainline and enabled in main distributions, it
> > has no relevance for corporate level (at least in my case).
> >
> > UML gives us the chance to build a compile and debug environment without
> > a relevance on which distribution it runs. The image used to boot UML is
> > a copy for each developer and each of them could compile applications
> > having the same environment as on the target system.
>
> There's a bit of misunderstanding: SKAS0 is a patch for UML only, not an
> host patch. It's numbered "0" because it has "0" dependencies, or because
> it does not depend on host SKAS patch (nor SKAS1, nor SKAS2, nor SKAS3).
But how do you trigger it?
I tried applying your "uml-2.6.12-bb2-skas0.patch.bz2" patch to 2.6.12.2,
doing "make ARCH=um allnoconfig", following to .config:
CONFIG_MODE_TT=y
CONFIG_LD_SCRIPT_STATIC=y
CONFIG_BINFMT_ELF=y
CONFIG_HOSTFS=y
CONFIG_SYSCTL=y
CONFIG_STDERR_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_LBD=y
CONFIG_EXT2_FS=y
CONFIG_PROC_FS=y
doing a "yes '' | make ARCH=um oldconfig", and then make ARCH=um.
Then I run the result with "./linux rootfstype=hostfs rootflags=/ mem=48M
init=/bin/sh"
And I get:
Checking for /proc/mm...not found
Checking for the skas3 patch in the host...not found
Checking PROT_EXEC mmap in /tmp...OK
Linux version 2.6.12.2-bb2-skas0 (landley@...) (gcc version 3.3.5
(Debian 1:3.3.5-8ubuntu2)) #2 Tue Jul 12 02:37:24 CDT 2005
Built 1 zonelists
Kernel command line: rootfstype=hostfs rootflags=/ mem=48M init=/bin/sh
root=98:0
PID hash table entries: 256 (order: 8, 4096 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 46720k available
Mount-cache hash table entries: 512
Checking for host processor cmov support...Yes
Checking for host processor xmm support...No
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...missing
Checking that host ptys support output SIGIO...Yes
Checking that host ptys support SIGIO on close...No, enabling workaround
Checking for /dev/anon on the host...Not available (open failed with errno 2)
Linux NoNET1.0 for Linux 2.6
io scheduler noop registered
loop: loaded (max 8 devices)
Initialized stdio console driver
Console initialized on /dev/tty0
VFS: Mounted root (hostfs filesystem) readonly.
Kernel panic - not syncing: get_skas_faultinfo : failed to wait for
SIGUSR1/SIGTRAP, pid = 15117, n = 15117, errno = 0, status = 0xb
EIP: 0073:[<40000c22>] CPU: 0 Not tainted ESP: 007b:bfbddd60 EFLAGS: 00210246
Not tainted
EAX: bfbddd60 EBX: 00000000 ECX: 00000000 EDX: 00000000
ESI: 00000000 EDI: 00000000 EBP: 00000000 DS: 007b ES: 007b
088e7bc0: [<0807ad9d>] notifier_call_chain+0x2d/0x50
088e7bd0: [<080e25e6>] bust_spinlocks+0x46/0x50
088e7be0: [<0806b911>] panic+0x71/0x120
088e7c00: [<0805e7e2>] wait_stub_done+0xa2/0xf0
088e7c30: [<0805e8aa>] get_skas_faultinfo+0x7a/0xa0
088e7c50: [<080602d2>] user_signal+0x82/0x90
088e7c70: [<0805ef60>] userspace+0x180/0x220
088e7cd4: [<08054e90>] init+0x0/0x110
088e7ce0: [<0805f8f2>] new_thread_handler+0xf2/0x130
|
|
From: Bernhard Schauer <schauer@ac...> - 2005-07-12 07:55:33
|
Blaisorblade wrote: > There's a bit of misunderstanding: SKAS0 is a patch for UML only, not an host > patch. It's numbered "0" because it has "0" dependencies, or because it does > not depend on host SKAS patch (nor SKAS1, nor SKAS2, nor SKAS3). Sorry for that, I should have read about it - especially before writing. _IMO:_ In any case it should be in the kernel mainline, or in other words: A mainline kernel should run without any patches required whether SKAS0 nor reverted fork-not-clone. If this specific failure is caught by reverted fork-not-clone patch this is THE correction and should also be in mainline kernel. If SKAS0 is better than TT mode, TT mode could be replaced with 2.6.14. |
|
From: Blaisorblade <blaisorblade@ya...> - 2005-07-12 16:09:34
|
On Tuesday 12 July 2005 09:55, Bernhard Schauer wrote: > Blaisorblade wrote: > > There's a bit of misunderstanding: SKAS0 is a patch for UML only, not an > > host patch. It's numbered "0" because it has "0" dependencies, or because > > it does not depend on host SKAS patch (nor SKAS1, nor SKAS2, nor SKAS3). > Sorry for that, I should have read about it - especially before writing. > _IMO:_ > In any case it should be in the kernel mainline, or in other words: > A mainline kernel should run without any patches required whether SKAS0 > nor reverted fork-not-clone. > If this specific failure is caught by reverted fork-not-clone patch this > is THE correction and should also be in mainline kernel. > If SKAS0 is better than TT mode, TT mode could be replaced with 2.6.14. Don't worry, I make the same kind of reasoning, so fork-not-clone will be reverted for now, until it's made to work on newer systems... and TT mode and SKAS0 mode are not incompatible, so SKAS0 will not be dropped so early (for now I consider 2.6.14 early, yes). There were some problems about TT mode which appeared unsolvable on newer distros, and that was a reason to drop TT mode, but I just solved them, so there's no hurry in dropping it. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
|
From: Michael Richardson <mcr@sa...> - 2005-07-15 04:41:13
Attachments:
application/pgp-signature
|
>>>>> "Paolo" == Blaisorblade <blaisorblade@...> writes:
Paolo> There were some problems about TT mode which appeared unsolvable
Paolo> on newer distros, and that was a reason to drop TT mode, but I
Paolo> just solved them, so there's no hurry in dropping it.
Good. I find that it is a LOT easier to debug in the TT mode.
I really prefer running GDB in a seperate window (under xemacs), and
attaching to the process. I haven't found a useful way to do this with SKAS.
One thing I'd also like is a way to completely turn off the scheduler when
debugging. It just gets in my way when I'm single stepping for 2 hours at a
time :-)
--
] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [
] mcr @ xelerance.com Now doing IPsec training, see |net architect[
] http://www.sandelman.ca/mcr/ http://www.xelerance.com/training/ |device driver[
] I'm a dad: http://www.sandelman.ca/lrmr/ [
|
|
From: Rob Landley <rob@la...> - 2005-07-12 08:05:27
|
On Tuesday 12 July 2005 02:53, Rob Landley wrote: > But how do you trigger it? > > I tried applying your "uml-2.6.12-bb2-skas0.patch.bz2" patch to 2.6.12.2, > doing "make ARCH=um allnoconfig", following to .config: > > CONFIG_MODE_TT=y Ahem. Obviously, I skipped a step. Those config entries (and the build process I was describing) are a cut and paste from my build process that uses UML to build a uclibc against more recent kernel headers that the host kernel it's running under (which would otherwise tend to cause segfaults). That uses tt mode. If I do what I just described, the result works just fine, but it's in tt mode. Which is odd, because stock 2.6.12.2 does NOT work for me in tt mode: it goes: Checking PROT_EXEC mmap in /tmp...OK tracing thread pid = 11687 And then exits with no further explanation or printout. (I get my shell prompt back but it's the host system's shell prompt.) But with Blaisorblade's -skas0 patch, tt mode works. (Go figure.) However, the point of the patch is to try -skas0 mode, so I went in to "make ARCH=um menuconfig", switched off tt mode, and switched on skas mode. (I did this instead of oldconfig.) Then I got the trace from last message. Sorry for the confusion. Rob |
|
From: Bernhard Schauer <linux-kernel-list@ac...> - 2005-07-12 09:33:42
|
> Checking PROT_EXEC mmap in /tmp...OK > tracing thread pid = 11687 > > And then exits with no further explanation or printout. That sounds like the behaviour described in the first message. If you apply the "uml-revert-fork-instead-of-clone.patch" posted by Blaisorblade in the same thread on 2nd July, everything should work as expected with TT mode only. |
|
From: Blaisorblade <blaisorblade@ya...> - 2005-07-12 15:50:43
|
On Tuesday 12 July 2005 11:33, Bernhard Schauer wrote: > > Checking PROT_EXEC mmap in /tmp...OK > > tracing thread pid = 11687 > > > > And then exits with no further explanation or printout. > > That sounds like the behaviour described in the first message. If you > apply the > "uml-revert-fork-instead-of-clone.patch" posted by Blaisorblade in the > same thread on 2nd July, everything should work as expected with TT mode > only. Exact, that's included in -bs which is included in the -skas0 patchset, so this is the explaination. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
|
From: Rob Landley <rob@la...> - 2005-07-12 18:54:46
|
On Tuesday 12 July 2005 04:33, Bernhard Schauer wrote: > > Checking PROT_EXEC mmap in /tmp...OK > > tracing thread pid = 11687 > > > > And then exits with no further explanation or printout. > > That sounds like the behaviour described in the first message. If you > apply the > "uml-revert-fork-instead-of-clone.patch" posted by Blaisorblade in the > same thread on 2nd July, everything should work as expected with TT mode > only. Cool. Thanks. Query; Now that UML has been merged and mainline is mostly caught up, is there some kind of "current-stable" URL out there where I can get a patch fixing known issues against the current stable linux kernel? I'd have tested it a couple weeks back, but I was fighting with my new laptop. (An unknown number of kbuntu reinstalls, three power supplies, and a lid replacement that gave me a new screen later, it seems to all be working. And thus, I'm trying to catch up...) Rob |
|
From: Blaisorblade <blaisorblade@ya...> - 2005-07-13 13:28:46
|
On Tuesday 12 July 2005 20:54, Rob Landley wrote: > On Tuesday 12 July 2005 04:33, Bernhard Schauer wrote: > > > Checking PROT_EXEC mmap in /tmp...OK > > > tracing thread pid = 11687 > > > > > > And then exits with no further explanation or printout. Btw, adding stderr=1 gives back a bit more output, in these situations. > > That sounds like the behaviour described in the first message. If you > > apply the > > "uml-revert-fork-instead-of-clone.patch" posted by Blaisorblade in the > > same thread on 2nd July, everything should work as expected with TT mode > > only. > Cool. Thanks. > Query; Now that UML has been merged and mainline is mostly caught up, is > there some kind of "current-stable" URL out there where I can get a patch > fixing known issues against the current stable linux kernel? -bs is intended to fill this need, and the community response seems quite satisfied. Trees named -bb are more "experimental" (bb stands for Blaisorblade, bs is Blaisorblade stable). In fact, the fix to this issue was in -bs1 and subsequent releases (and I'm trying now to merge it in the base -stable tree, i.e. I hope it'll be in 2.6.12.3; however requirements for inclusion there are much stricter, and the procedure is longer). > I'd have tested it a couple weeks back, but I was fighting with my new > laptop. (An unknown number of kbuntu reinstalls, three power supplies, and > a lid replacement that gave me a new screen later, it seems to all be > working. And thus, I'm trying to catch up...) -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |