Re: [uml-devel] SIGSEGV and SA_NODEFER
On Tuesday 25 January 2005 11:16, Rob Landley wrote: On Tuesday 25 January 2005 05:16 am, Blaisorblade wrote: I'm using stdin/stdout as the console. (And even though you put it into raw mode, I still can't ctrl-c out of the processs I'm running, either.) Hmm, ^C works perfectly fine for me. Usually I work with a virtual serial line as console (console=ttyS0 ssl0=fd:0,fd:1 con=pts), works better than the uml console as applications don't expect the linux vt ioctls work on these devices ;) About this, Rob: do you use /dev/console in the inittab line? If you do, then that's the problem - it should become a FAQ somewhere I guess. I'm not using init, I'm running my script as init. So I'd guess it's using /dev/console, yes. I know that /dev/console is funky. That's why I want the option to let ctrl-c kill the whole vmlinux instance. (Possibly as a command line option.) I'll look into that later... I'm still at 2.6.10 + patches though, not yet at 2.6.11-rc2. However, I'm not sure that patch is at fault... there is a locking problem which *could* maybe be responsible of this...; I actually wonder about why this locking problem has never shown up in reports or in testing (it exists, only it's a race condition)... there is a situation where it shows up with a side effect, indeed, so the problem exists... Heavy swapping (see other mail) and thus some stuff running _very_ slow might open such race windows wide enougth that one actually hits them. Yes, my only doubt was that he seemed to mean that the guest was swapping, and *this* different situation would have the opposite effect, probably. Host is swapping, client configured without even support for swap. (If I can get the darn client vmlinux down to 1 megabyte, I'd be thrilled. Didn't somebody once make the entire block layer configurable out once? With hostfs, I don't need it...) Do you trust hostfs so much? You don't need user IDs on your FS, I guess. I'm not at all happy with this, but I don't want someone using hostfs over its possibilities. NFS is much better, anyway. And somebody says it's also faster (and since hostfs does limited caching, it makes sense - hostfs must avoid having any inode cache, since it closes the host fd only when the inode is evicted from the cache; I don't think it's possible to cache data without an inode to link to, so it's clear it's slow). -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Fwd: Re: [uml-devel] SIGSEGV and SA_NODEFER
-- Forwarded Message -- Subject: Re: [uml-devel] SIGSEGV and SA_NODEFER Date: Tuesday 25 January 2005 09:45 From: Gerd Knorr [EMAIL PROTECTED] To: Blaisorblade [EMAIL PROTECTED] binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.dd binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.rd binutils-2.14/ld/testsuite/lde/ld-/ld-sld-spd-spa-sparsparcparc/arc/trc/t lc /tls/tlsstlssulssunssunbsunbiunbinnbin6bin64in64.n64.s64.s4.s.ss binubinutinutinutilutilstils-ils-2ls-2.s-2.1-2.142.14/.14/l14/ld4/ld//ld/ tl d/ted/tes/testtestsestsustsuitsuitsuiteuite/ite/lte/lde/ld-/ld-sld-spd-sp a-s parsparcparc/arc/trc/tlc/tls/tlsstlssulssunssunbsunbiunbinnbin6bin64in64. n64 .s64.sd4.sd.sdsd binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.td binutils-2.14/ld/testsuite/ld-sparc/tlssunbinpic32.s binutils-2.14/ld/testsuite/ld-sparc/tlssunbinpic64.s binutils-2.14/ld/testsuite/ld-sparc/tlssunnopic32.dd I had all that output piped to tee, which output it to out.txt, and the corresponding line of out.txt isn't glitched, so it seems to just be a cosmetic bug in the display code. But I thought I'd report it anyway. Good thing, thanks... I remember having seen a comment (and patch?) on one of the lists for the tty line buffering, because of data loss in case the buffers are full. Don't remember the details but this could be related. I'm using stdin/stdout as the console. (And even though you put it into raw mode, I still can't ctrl-c out of the processs I'm running, either.) Hmm, ^C works perfectly fine for me. Usually I work with a virtual serial line as console (console=ttyS0 ssl0=fd:0,fd:1 con=pts), works better than the uml console as applications don't expect the linux vt ioctls work on these devices ;) I'm still at 2.6.10 + patches though, not yet at 2.6.11-rc2. However, I'm not sure that patch is at fault... there is a locking problem which *could* maybe be responsible of this...; I actually wonder about why this locking problem has never shown up in reports or in testing (it exists, only it's a race condition)... there is a situation where it shows up with a side effect, indeed, so the problem exists... Heavy swapping (see other mail) and thus some stuff running _very_ slow might open such race windows wide enougth that one actually hits them. The uml-terminal-cleanup patch doesn't touch how the uml terminal lines output (xterm, pty, ...) works, it's more the input side which has been reworked a bit, especially the console handling (console meaning the device the kernel sends the printk messages to, not the linux vt subsystem). Gerd -- #define printk(args...) fprintf(stderr, ## args) --- -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] SIGSEGV and SA_NODEFER
On Monday 24 January 2005 02:45 pm, Blaisorblade wrote: On Saturday 22 January 2005 17:34, Rob Landley wrote: On Friday 21 January 2005 02:58 pm, Blaisorblade wrote: That is -mm1, I've already looked at both... the patches listed below are minor fixes / improvements... The name of the 2.6.11-rc1-mm2 patch which probably fixed your issue is: uml-fix-a-stack-corruption-crash.patch I reverted that patch, rebuilt vmlinux, tried again, and it's happily halfway through the binutils build as I type. That fix doesn't seem to be it. (Makes a certain amount of sense, since I wasn't seeing a crash, I was seeing a hang.) Hmm, and so what is fixing your problem? It's difficult to tell in this case... I know. I can try a binary search, but the work week has returned, and with it the dreaded day job... Another interesting point is that with -mm2 (patched or unpatched), I'm seeing output hiccups when the system swaps. Host or guest? If it's the host system, then my idea about it (a locking problem) is a good explaination, but if it's the guest system to swap I haven't clear why it works (not investigated well yet, through). The host system is swapping. The guest is configured without swap support. I'm using stdin/stdout as the console. (And even though you put it into raw mode, I still can't ctrl-c out of the processs I'm running, either.) Does this happen in -bb4 too? Also, does it happen even if you use a xterm console? I didn't see it in -bb4 (doesn't prove it didn't happen, but it's pretty noticeable in -rc1-mm2). I haven't tried an xterm console yet. By the way, just confirming: file I/O support is now compiled in all the time, right? (I noticed that there's no longer a config option for them, but setting console to fd0/fd1 seems to be working. Well, run as root anyway, there's some kind of permissions problem if I fire up hostfs as a normal user that makes the console refuse to open. I'm off completely rewriting busybox mount now that UML revealed that --bind and --move mounts don't work with busybox mount if /proc/filesystems consists entirely of nodev filesystems, so it'll take me a bit to come back to thumping on this...) Rob Well, am I right if I suppose the other version you tested (with success) is only 2.6.9-bb4, for this console issue? I didn't see it on -bb4. I could try again and stress the system a bit, but I suspect it wasn't there. There is a patch which was merged in 2.6.10-mm1 (IIRC), which changes heavily the I/O core... I'm CC:ing the author for more investigation. However, I'm not sure that patch is at fault... there is a locking problem which *could* maybe be responsible of this...; I actually wonder about why this locking problem has never shown up in reports or in testing (it exists, only it's a race condition)... there is a situation where it shows up with a side effect, indeed, so the problem exists... Okay, a little about me. I am the linux on the desktop nightmare scenario. I buy cheap used hardware (currently using a thinkpad with 128 megs of ram which I got for $400), and then stress it way beyond its limits. For example, I use Konqueror for my web browsing, which is very nice from a user perspective but has a couple of really HORRIBLE internal design issues to do with opening lots of windows/tabs at once. (Which I do.) It cycles through all the open windows/tabs for various things, swapping through memory round-robin. Opening a new window has been known to make the VM sit there and swap for 30 seconds, so badly that the mouse cursor doesn't move at all. Currently, konqueror only has 17 tabs open, in only one window, which is actually fairly light for me. (I'm fairly certain konqueror pins memory somehow, and I know it never actually frees any until you exit the darn thing.) On top of that, kmail is up. I have over 10,000 threaded messages in the linux-kernel mailing list alone. (I have to catch up soon and delete the excess, kmail used to corrupt its indexing if you deleted messages from a mbox folder with over about 20,000 of them. And, of course, I have xmms up to play mp3's.) Strangely enough, compiling software in a background window adds negligible load, it's all the desktop stuff I'm doing that makes it swap its brains out. Back under the 2.4.4 kernel or so, it took me about 15 seconds to make the system swap so badly I could go to lunch and come back with it still frozen and swapping. Now in the 2.6 series, the swap is _much_ better, it's never completely frozen for longer than about 45 seconds. The early releases of XFree86 4.something had a bug where if an internal wait timed out the X server would exit back to text mode. I used to hit that _daily_. So if there are any weird latency bugs lurking where inserting a second or three delay somewhere causes something to hiccup, I bump into them as a matter of course. :) Rob
Re: [uml-devel] SIGSEGV and SA_NODEFER
On Tuesday 25 January 2005 06:40 am, Blaisorblade wrote: Host is swapping, client configured without even support for swap. (If I can get the darn client vmlinux down to 1 megabyte, I'd be thrilled. Didn't somebody once make the entire block layer configurable out once? With hostfs, I don't need it...) Do you trust hostfs so much? You don't need user IDs on your FS, I guess. Once I get /dev on ramfs managed by udev? Not really, no. I need the permissions to be right, but just about everything else should belong to root. (Yeah, there are a couple fun tricks where files change their ownership to some variant of nobody to do chroot jails and stuff, but they do that at runtime...) I've probably missed one or two instances, but I expect I can work around 'em... I'm not at all happy with this, but I don't want someone using hostfs over its possibilities. NFS is much better, anyway. NFS gives me hives (a stateless fileserver: okay, spot the contradiction in terms here), although I must admit I haven't tried the new TCP/IP based version (V4?) yet because it wasn't finished last time I tried. And somebody says it's also faster (and since hostfs does limited caching, it makes sense - hostfs must avoid having any inode cache, since it closes the host fd only when the inode is evicted from the cache; I don't think it's possible to cache data without an inode to link to, so it's clear it's slow). Since the host is cacheing the data for us, not having a redundant cache sounds like a good idea to me. Admittedly, it's more syscalls, but less memory consumption... Rob --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] SIGSEGV and SA_NODEFER
On Tuesday 25 January 2005 18:30, Rob Landley wrote: On Tuesday 25 January 2005 06:40 am, Blaisorblade wrote: Host is swapping, client configured without even support for swap. (If I can get the darn client vmlinux down to 1 megabyte, I'd be thrilled. Didn't somebody once make the entire block layer configurable out once? With hostfs, I don't need it...) Do you trust hostfs so much? You don't need user IDs on your FS, I guess. Once I get /dev on ramfs managed by udev? Not really, no. I need the permissions to be right, but just about everything else should belong to root. (Yeah, there are a couple fun tricks where files change their ownership to some variant of nobody to do chroot jails and stuff, but they do that at runtime...) I don't expect chown to work at all - i.e. it's not it forgets it at reboot, it's it forgets it immediately... If you see it working, maybe you are seeing the more precise behaviour it forgets it As Soon as the file is closed. I've probably missed one or two instances, but I expect I can work around 'em... I'm not at all happy with this, but I don't want someone using hostfs over its possibilities. NFS is much better, anyway. NFS gives me hives ?? What's hives? (a stateless fileserver: okay, spot the contradiction in terms here), although I must admit I haven't tried the new TCP/IP based version (V4?) yet because it wasn't finished last time I tried. And somebody says it's also faster (and since hostfs does limited caching, it makes sense - hostfs must avoid having any inode cache, since it closes the host fd only when the inode is evicted from the cache; I don't think it's possible to cache data without an inode to link to, so it's clear it's slow). Since the host is cacheing the data for us, not having a redundant cache sounds like a good idea to me. Admittedly, it's more syscalls, but less memory consumption... The problem is that its slower than NFS! -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] SIGSEGV and SA_NODEFER
On Tuesday 25 January 2005 20:30, Rob Landley wrote: On Tuesday 25 January 2005 02:34 pm, Blaisorblade wrote: Once I get /dev on ramfs managed by udev? Not really, no. I need the permissions to be right, but just about everything else should belong to root. (Yeah, there are a couple fun tricks where files change their ownership to some variant of nobody to do chroot jails and stuff, but they do that at runtime...) I don't expect chown to work at all - i.e. it's not it forgets it at reboot, it's it forgets it immediately... If you see it working, maybe you are seeing the more precise behaviour it forgets it As Soon as the file is closed. Actually, I don't think I've tried to do a chown on UML at all. As I said, the files I care about the ownership of being right (the /dev directory) are all in a ramfs. Everything else should belong to root, I just care that the permissions are right. (A user can set the suid bit on their own files, right?) Theoretically yes... however, sadly, chmod 4777 /mnt/host/bin/dash works and is a suitable exploit... with other shells, it depends (bash refuses to work as setuid)... And what I meant to say earlier is that some programs chuser (like bind and httpd and such), which they do at runtime You mean they call setuid() / setgid() or such, which should be ok... but you get Still, good point. I'm doing a rebuild without UML and I'll run find . -not -uid 0 on the result to see what comes up... I'm not at all happy with this, but I don't want someone using hostfs over its possibilities. NFS is much better, anyway. NFS gives me hives ?? What's hives? I've searched for it - is not hive the place for bees? I understand you mean something like issues... An NFS server can't be exposed to the internet securely. Agreed... you cannot rely on root access on the host, otherwise what you would do likely is to add some firewall rules (and to ask it to listen on the lo interface only, if possible). (To add insult to injury, for _years_ Red Hat exposed portmap and such to the outside world and there was absolutely no way to tell it not to install/run that crud, and you had to go in by hand and rip them out of each new install if you wanted it on the net.) NFS was designed to be a stateless protocol, yet the point of a filesystem is to maintain state. It DIDN'T just do a TCP/IP connection to a client, instead it did weird UDP stuff so the server doesn't have to know which files the client has open and 8 gazillion other strange corner cases that I stopped trying to pay attention to more than 5 years ago. I'm told the most recent version of NFS has been redesigned to work like Samba: a client that mounts one of these things opens a TCP/IP session, and if it gets closed the client re-opens it. I should look into that, but the last time I did support for the new way of doing it it wasn't in the kernel yet. Well, IIRC NFS over TCP/IP exists and works also for NFSv3 (maybe EXPERIMENTAL, but it's included since some time, even in 2.4 I think, and probably is more reliable than hostfs). NFSv4 is the only real secure-thought protocol, and it's experimental like you say. And somebody says it's also faster (and since hostfs does limited caching, it makes sense - hostfs must avoid having any inode cache, since it closes the host fd only when the inode is evicted from the cache; I don't think it's possible to cache data without an inode to link to, so it's clear it's slow). Since the host is cacheing the data for us, not having a redundant cache sounds like a good idea to me. Admittedly, it's more syscalls, but less memory consumption... The problem is that its slower than NFS! Okay, remember how my build process is designed to be packaged up, exported to some random Linux system out there, and run as a normal user without root access? HostFS is exactly what I need. Even assuming an NFS server is installed on the target system, a normal user can't run nfsd if it isn't already running on the system, and can't control what it exports if it is. Maybe I'll profile it and look at speeding it up later, but not anytime soon... In that case, you could maybe see humfs ready (which is a hostfs with an added support for storing metadatas on the host filesystem). I guess it won't be before 2.6.13. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net
Re: [uml-devel] SIGSEGV and SA_NODEFER
On Tuesday 25 January 2005 02:34 pm, Blaisorblade wrote: Once I get /dev on ramfs managed by udev? Not really, no. I need the permissions to be right, but just about everything else should belong to root. (Yeah, there are a couple fun tricks where files change their ownership to some variant of nobody to do chroot jails and stuff, but they do that at runtime...) I don't expect chown to work at all - i.e. it's not it forgets it at reboot, it's it forgets it immediately... If you see it working, maybe you are seeing the more precise behaviour it forgets it As Soon as the file is closed. Actually, I don't think I've tried to do a chown on UML at all. As I said, the files I care about the ownership of being right (the /dev directory) are all in a ramfs. Everything else should belong to root, I just care that the permissions are right. (A user can set the suid bit on their own files, right?) And what I meant to say earlier is that some programs chuser (like bind and httpd and such), which they do at runtime Still, good point. I'm doing a rebuild without UML and I'll run find . -not -uid 0 on the result to see what comes up... I've probably missed one or two instances, but I expect I can work around 'em... I'm not at all happy with this, but I don't want someone using hostfs over its possibilities. NFS is much better, anyway. NFS gives me hives ?? What's hives? An NFS server can't be exposed to the internet securely. (To add insult to injury, for _years_ Red Hat exposed portmap and such to the outside world and there was absolutely no way to tell it not to install/run that crud, and you had to go in by hand and rip them out of each new install if you wanted it on the net.) NFS was designed to be a stateless protocol, yet the point of a filesystem is to maintain state. It DIDN'T just do a TCP/IP connection to a client, instead it did weird UDP stuff so the server doesn't have to know which files the client has open and 8 gazillion other strange corner cases that I stopped trying to pay attention to more than 5 years ago. I'm told the most recent version of NFS has been redesigned to work like Samba: a client that mounts one of these things opens a TCP/IP session, and if it gets closed the client re-opens it. I should look into that, but the last time I did support for the new way of doing it it wasn't in the kernel yet. And somebody says it's also faster (and since hostfs does limited caching, it makes sense - hostfs must avoid having any inode cache, since it closes the host fd only when the inode is evicted from the cache; I don't think it's possible to cache data without an inode to link to, so it's clear it's slow). Since the host is cacheing the data for us, not having a redundant cache sounds like a good idea to me. Admittedly, it's more syscalls, but less memory consumption... The problem is that its slower than NFS! Okay, remember how my build process is designed to be packaged up, exported to some random Linux system out there, and run as a normal user without root access? HostFS is exactly what I need. Even assuming an NFS server is installed on the target system, a normal user can't run nfsd if it isn't already running on the system, and can't control what it exports if it is. Maybe I'll profile it and look at speeding it up later, but not anytime soon... Rob --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] SIGSEGV and SA_NODEFER
On Tuesday 25 January 2005 03:50 pm, Blaisorblade wrote: Actually, I don't think I've tried to do a chown on UML at all. As I said, the files I care about the ownership of being right (the /dev directory) are all in a ramfs. Everything else should belong to root, I just care that the permissions are right. (A user can set the suid bit on their own files, right?) Theoretically yes... however, sadly, chmod 4777 /mnt/host/bin/dash works and is a suitable exploit... with other shells, it depends (bash refuses to work as setuid)... I was thinking more along the lines of installing the su binary and such correctly and having the permissions retained long enough to make the squashfs image out of it. I'm not worried about security within the UML instance. It's running as a normal user, and it's running a build script. When the script exits, the VM exits. It's not a server or anything, it's basically an runtime for a batch file. And what I meant to say earlier is that some programs chuser (like bind and httpd and such), which they do at runtime You mean they call setuid() / setgid() or such, which should be ok... but you get Still, good point. I'm doing a rebuild without UML and I'll run find . -not -uid 0 on the result to see what comes up... Speaking of which, I did this and there wasn't anything that didn't belong to root. (Okay, /proc and /dev/pts showed plenty of stuff, but that's because I forgot and left them mounted after the build. And several group ids were nonzero in /dev, but I expected that...) I'm not at all happy with this, but I don't want someone using hostfs over its possibilities. NFS is much better, anyway. NFS gives me hives ?? What's hives? I've searched for it - is not hive the place for bees? I understand you mean something like issues... American colloquialism. gives me hives also means it makes you break out in a rash, and the meaning's wandered a bit towards makes my skin crawl... An NFS server can't be exposed to the internet securely. Agreed... you cannot rely on root access on the host, otherwise what you would do likely is to add some firewall rules (and to ask it to listen on the lo interface only, if possible). I could beat it into submission, but it's not worth the performance boost or the conceptual complexity. One advantage of UML is that I have to build the linux kernel _anyway_, so it's not an extra package I need to include in the build process and make sure I keep up to date. I'll happily milk that for all it's worth. I'm told the most recent version of NFS has been redesigned to work like Samba: a client that mounts one of these things opens a TCP/IP session, and if it gets closed the client re-opens it. I should look into that, but the last time I did support for the new way of doing it it wasn't in the kernel yet. Well, IIRC NFS over TCP/IP exists and works also for NFSv3 (maybe EXPERIMENTAL, but it's included since some time, even in 2.4 I think, and probably is more reliable than hostfs). NFSv4 is the only real secure-thought protocol, and it's experimental like you say. I think v3 was the one I looked at, and it didn't do what I was looking for, and the NFS guys I talked to told me that how I _wanted_ it to work was pretty close to a description of NVSv4. The problem is that its slower than NFS! Okay, remember how my build process is designed to be packaged up, exported to some random Linux system out there, and run as a normal user without root access? HostFS is exactly what I need. Even assuming an NFS server is installed on the target system, a normal user can't run nfsd if it isn't already running on the system, and can't control what it exports if it is. Maybe I'll profile it and look at speeding it up later, but not anytime soon... In that case, you could maybe see humfs ready (which is a hostfs with an added support for storing metadatas on the host filesystem). I guess it won't be before 2.6.13. Sounds like fun. When you've got something for me to test, I'll be here. :) Rob --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] SIGSEGV and SA_NODEFER
On Tuesday 25 January 2005 05:16 am, Blaisorblade wrote: I'm using stdin/stdout as the console. (And even though you put it into raw mode, I still can't ctrl-c out of the processs I'm running, either.) Hmm, ^C works perfectly fine for me. Usually I work with a virtual serial line as console (console=ttyS0 ssl0=fd:0,fd:1 con=pts), works better than the uml console as applications don't expect the linux vt ioctls work on these devices ;) About this, Rob: do you use /dev/console in the inittab line? If you do, then that's the problem - it should become a FAQ somewhere I guess. I'm not using init, I'm running my script as init. So I'd guess it's using /dev/console, yes. I know that /dev/console is funky. That's why I want the option to let ctrl-c kill the whole vmlinux instance. (Possibly as a command line option.) I'll look into that later... I'm still at 2.6.10 + patches though, not yet at 2.6.11-rc2. However, I'm not sure that patch is at fault... there is a locking problem which *could* maybe be responsible of this...; I actually wonder about why this locking problem has never shown up in reports or in testing (it exists, only it's a race condition)... there is a situation where it shows up with a side effect, indeed, so the problem exists... Heavy swapping (see other mail) and thus some stuff running _very_ slow might open such race windows wide enougth that one actually hits them. Yes, my only doubt was that he seemed to mean that the guest was swapping, and *this* different situation would have the opposite effect, probably. Host is swapping, client configured without even support for swap. (If I can get the darn client vmlinux down to 1 megabyte, I'd be thrilled. Didn't somebody once make the entire block layer configurable out once? With hostfs, I don't need it...) Rob --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] SIGSEGV and SA_NODEFER
On Friday 21 January 2005 02:58 pm, Blaisorblade wrote: That is -mm1, I've already looked at both... the patches listed below are minor fixes / improvements... The name of the 2.6.11-rc1-mm2 patch which probably fixed your issue is: uml-fix-a-stack-corruption-crash.patch I reverted that patch, rebuilt vmlinux, tried again, and it's happily halfway through the binutils build as I type. That fix doesn't seem to be it. (Makes a certain amount of sense, since I wasn't seeing a crash, I was seeing a hang.) If it's not a problem, try removing it from -mm2 and recompiling, and test if you get the crash with the new kernel (which is what I expect)... More later, lunch is over... Here, now, I must go to dinner... bye! Another interesting point is that with -mm2 (patched or unpatched), I'm seeing output hiccups when the system swaps. Here's a cut and paste of a section where it was extracting the binutils tarball: binutils-2.14/gas/testsuite/gas/hppa/unsorted/common.s binutils-2.14/gas/testsuite/gas/hppa/unsorted/fragbug.s binutils-2.14/gas/testsuite/gas/hppa/unsorteortedrted/ted/ged/gld/glo/globglobalobalobalbbalbualbuglbug.bug.sug.sg.s.ss binutils-2.14/gas/testsuite/gas/hppa/unsorted/importbug.s And later on... binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.dd binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.rd binutils-2.14/ld/testsuite/lde/ld-/ld-sld-spd-spa-sparsparcparc/arc/trc/tlc/tls/tlsstlssulssunssunbsunbiunbinnbin6bin64in64.n64.s64.s4.s.ss binubinutinutinutilutilstils-ils-2ls-2.s-2.1-2.142.14/.14/l14/ld4/ld//ld/tld/ted/tes/testtestsestsustsuitsuitsuiteuite/ite/lte/lde/ld-/ld-sld-spd-spa-sparsparcparc/arc/trc/tlc/tls/tlsstlssulssunssunbsunbiunbinnbin6bin64in64.n64.s64.sd4.sd.sdsd binutils-2.14/ld/testsuite/ld-sparc/tlssunbin64.td binutils-2.14/ld/testsuite/ld-sparc/tlssunbinpic32.s binutils-2.14/ld/testsuite/ld-sparc/tlssunbinpic64.s binutils-2.14/ld/testsuite/ld-sparc/tlssunnopic32.dd It did it about five or six times, that I noticed. (And it did it before I reverted the stack fix patch, so that's not it.) I had all that output piped to tee, which output it to out.txt, and the corresponding line of out.txt isn't glitched, so it seems to just be a cosmetic bug in the display code. But I thought I'd report it anyway. I'm using stdin/stdout as the console. (And even though you put it into raw mode, I still can't ctrl-c out of the processs I'm running, either.) Rob --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] SIGSEGV and SA_NODEFER
On Thursday 20 January 2005 01:07, you wrote: On Tuesday 18 January 2005 22:28, Jeff Dike wrote: It turns out that caker's crashes were being caused by the lack of SA_NODEFER in the SIGSEGV handler registration. As Jeff explained me on IRC, the previous patch sent about the same subject, actually, was correct, but not related to the caker's problem. Since Jeff explained everything on IRC (#uml) I'm just explaining it here for the archives. I know I fixed this, and I have no idea where the fix went. Do you have any clue what happened to it? The SA_NODEFER flag was dropped from that call in 2.6.7-2um in the random patch, in 2.4.24-2um, and finally in uml-let-page-faults-always-be-delivered-immediately.patch in 2.6.9-rc2-mm1. That was compensated by adding the addition of this hunk for TT mode in sig_handler_common_tt() : Are we sure it is a compensation? I started having the doubt that enabling the signal inside the handler is not the same thing... because otherwise we don't understand why the patch in 2.4 makes difference in TT mode. Indeed, the blocking is done in the same way, but probably the timing is different - i.e. we unblock the signal only after unprotect_kernel_mem() in the new code, which somehow *makes* a difference. I'm going to choose the SA_NODEFER instead of adding the explicit check, at least for 2.4. I'd do it for 2.6 too, only that I'm not too sure. Jeff, what is your suggestion? /* This is done because to allow SIGSEGV to be delivered inside a SEGV * handler. This can happen in copy_user, and if SEGV is disabled, * the process will die. */ if(sig == SIGSEGV) change_sig(SIGSEGV, 1); The relation is obviously hidden somehow... however I sent on the uml-devel list a couple of patches from after 2.4.24-1um: without them UML does not suffer from the Debian/hwclock crash, while it happens with them. What's strange is that the crash happens within TT mode, not within SKAS mode. And rather than a crash, it's a hang, due to an infinite number of received SIGSEGVs. Inside the couple of patches, there is exactly this problematic change. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] SIGSEGV and SA_NODEFER
[EMAIL PROTECTED] said: Are we sure it is a compensation? I started having the doubt that enabling the signal inside the handler is not the same thing... because otherwise we don't understand why the patch in 2.4 makes difference in TT mode. Well, it clearly does something very close to SA_NODEFER, so it's compensation in that sense. Indeed, the blocking is done in the same way, but probably the timing is different - i.e. we unblock the signal only after unprotect_kernel_mem() in the new code, which somehow *makes* a difference. Maybe. If unprotect_kernel_mem has anything to do with it, then it can only affect jail mode in tt, which I'm planning on doing away with anyway at some point. I'm going to choose the SA_NODEFER instead of adding the explicit check, at least for 2.4. I'd do it for 2.6 too, only that I'm not too sure. My preference would be SA_NODEFER. Do we know who was having problems that were fixed by this? Maybe we could see what exactly SA_NODEFER does there. Jeff --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] SIGSEGV and SA_NODEFER
On Friday 21 January 2005 07:35 am, Blaisorblade wrote: Ooh, ooh! Hang in TT mode is what I'm seeing with my makefile hang. (sh -x dosn't help if the makefile doesn't call out to stuff with it.) If the previous patch doesn't address it, is there a new patch I could try? Well, you solved this problem with the 2.6.11-rc1-mm2, right (from the message below)? With 2.6.11-rc1-mm2, my toolchain build runs through to completion under UML. (Very very slowly, but it does. Tested on a 1.6 ghz 2 meg cache computer, which runs it under UML at about the speed of my 700 mhz 128k cache laptop without UML. But hey, it's using tt mode, and completing correctly. That's the important thing...) The patch which was merged there is the one posted with title [uml-devel] [PATCH] Fix stack corruption on this list..., I guess... it will be in 2.6.9-bs6 and 2.6.10-bb1 (both to release) - are you willing to test one of them, when I do the release? I'd be very thankful to accept your help... I'll happily try out 2.6.10-bb1, sure. The mm2 changelog says it has: -uml-avoid-null-dereference-in-linec.patch -uml-readd-config_magic_sysrq-for-uml.patch -uml-commentary-addition-to-recent-sysemu-fix.patch -uml-drop-unused-buffer_headh-header-from-hostfs.patch -uml-delete-unused-header-umnh.patch -uml-commentary-about-sigwinch-handling-for-consoles.patch -uml-fail-xterm_open-when-we-have-no-display.patch -uml-depend-on-usermode-in-drivers-block-kconfig-and-drop-arch-um-kconfig_block.patch -uml-makefile-simplification-and-correction.patch -uml-fix-compilation-for-missing-headers.patch -uml-fix-some-uml-own-initcall-macros.patch -uml-refuse-to-run-without-skas-if-no-tt-mode-in.patch -uml-for-ubd-cmdline-param-use-colon-as-delimiter.patch -uml-allow-free-ubd-flag-ordering.patch -uml-move-code-from-ubd_user-to-ubd_kern.patch -uml-fix-and-cleanup-code-in-ubd_kernc-coming-from-ubd_userc.patch -uml-add-stack-content-to-dumps.patch -uml-add-stack-addresses-to-dumps.patch -uml-update-ld-scripts-to-newer-binutils.patch More later, lunch is over... Rob --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] SIGSEGV and SA_NODEFER
On Friday 21 January 2005 19:18, Rob Landley wrote: On Friday 21 January 2005 07:35 am, Blaisorblade wrote: Ooh, ooh! Hang in TT mode is what I'm seeing with my makefile hang. (sh -x dosn't help if the makefile doesn't call out to stuff with it.) If the previous patch doesn't address it, is there a new patch I could try? Well, you solved this problem with the 2.6.11-rc1-mm2, right (from the message below)? With 2.6.11-rc1-mm2, my toolchain build runs through to completion under UML. (Very very slowly, but it does. Tested on a 1.6 ghz 2 meg cache computer, which runs it under UML at about the speed of my 700 mhz 128k cache laptop without UML. But hey, it's using tt mode, and completing correctly. That's the important thing...) The patch which was merged there is the one posted with title [uml-devel] [PATCH] Fix stack corruption on this list..., I guess... it will be in 2.6.9-bs6 and 2.6.10-bb1 (both to release) - are you willing to test one of them, when I do the release? I'd be very thankful to accept your help... I'll happily try out 2.6.10-bb1, sure. The mm2 changelog says it has: That is -mm1, I've already looked at both... the patches listed below are minor fixes / improvements... The name of the 2.6.11-rc1-mm2 patch which probably fixed your issue is: uml-fix-a-stack-corruption-crash.patch If it's not a problem, try removing it from -mm2 and recompiling, and test if you get the crash with the new kernel (which is what I expect)... More later, lunch is over... Here, now, I must go to dinner... bye! -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
