Back to Home / #uml / 2007 / 10 / Prev Day | Next Day
#uml IRC Logs for 2007-10-02

---Logopened Tue Oct 02 00:00:06 2007
00:01|-|Magotari [] has joined #uml
00:05|-|JDLSpeedy [] has quit [Ping timeout: 480 seconds]
01:36|-|florin-not-here [] has quit [Quit: Leaving]
01:52|-|magotari_school [~d4b631fa@] has joined #uml
03:02|-|magotari_school [~d4b631fa@] has quit [Quit: CGI:IRC (Ping timeout)]
03:02|-|tyler29 [] has joined #uml
03:06|-|Ancalagon [] has joined #uml
03:07|-|Ancalagon [] has left #uml []
03:37|-|tyler29 [] has quit [Ping timeout: 480 seconds]
04:33|-|tyler29 [] has joined #uml
04:53|-|tyler29 [] has quit [Ping timeout: 480 seconds]
05:06|-|tyler29 [] has joined #uml
05:19|-|huslu_ [] has joined #uml
05:21|-|huslu [] has quit [Ping timeout: 480 seconds]
06:15|-|tyler29 [] has quit [Ping timeout: 480 seconds]
06:28|-|tyler29 [] has joined #uml
07:07|-|tyler29 [] has quit [Ping timeout: 480 seconds]
07:22|-|tyler29 [] has joined #uml
07:43|-|dang [] has quit [Quit: Leaving.]
08:14|-|dang [] has joined #uml
08:28|-|tyler29 [] has quit [Ping timeout: 480 seconds]
08:45|-|tyler29 [] has joined #uml
09:45|-|kokoko1 [~Slacker@] has joined #uml
09:48<Magotari>Greetings, kokoko1.
09:54|-|jdike [] has joined #uml
09:54<jdike>Hi guys
09:58<Magotari>I think I found a very minor bug in UML, confirmed with the FC5 image from the UML website and the -mm kernel. I doubt it is worth bothering with though.
09:59<jdike>which is what?
09:59<Magotari>swapon /dev/kmem causes a SIGSEGV
10:00<Magotari>Does not crash the host though.
10:00<jdike>how did you find that?
10:00<Magotari>I was bored. I was trying things which every person sometimes wants to do.
10:00<Magotari>cat /dev/urandom > /dev/mem
10:00<Magotari>And so on.
10:00<Magotari>But that one did not crash the host.
10:01<Magotari>just cat /dev/kmem also crashes things.
10:01<Magotari>Want backtrace from gdb?
10:02<Magotari>Gonna post it, sec.
10:09<dgraves>Magotari: that's awesome. :)
10:10<Magotari>There is nothing better than making the kernel memory into swapspace. :)
10:10<Magotari>I thought about how I could contribute to this project a bit more, and I had an idea. I don't know C, but I do know how to make an image.
10:10<Magotari>I could create a debug-oriented root_fs.
10:10<Magotari>With strace, gdb, tcc and some benchmarks.
10:11<Magotari>I think it could be useful.
10:11<jdike>it just hangs here
10:12<Magotari>jdike: Run it in gdb.
10:12<Magotari>It does hang to me too, unless run in gdb.
10:12<Magotari>When I do 'c' in gdb it keeps on reporting new and new SIGSEGVs.
10:13<jdike>the segv is actually OK
10:13<jdike>that's a page fault
10:15<Magotari>Hmm. I see.
10:16<Magotari>Does anyone need /dev/kmem anyway?
10:16<dang>Heh. It's trying to fault in the swap that's in /dev/kmem...
10:17<dgraves>and probably wondering where its memory went in the meantime. :)
10:17<Magotari>Could someone explain this to me in simple language? This is my second week that I am studying the kernel and I am quite a bit behind on my vocabulary.
10:17<Magotari>Just curious.
10:19<dgraves>magotari: /dev/kmem is a window into the kernels reserved memory. you told it to use the device /dev/kmem as swap memory.
10:19<Magotari>Not quite. It dies on a cat too.
10:19<dgraves>so, when it needed swap, it page faulted, which means that the page wasn't in memory.
10:19<Magotari>cat /dev/kmem
10:19<dgraves>it then tried to bring in pages from /dev/kmem to fulfill your request to use it as swap.
10:19<dgraves>and probably was gonna try and write to there.
10:20<Magotari>I am actually laughing hard now.
10:20<dgraves>you can see in your stack trace that the call went to vfs_read
10:20<dgraves>which is the virtual file system that then hands the call off to the correct file system driver to read the file.
10:20<dgraves>in this case, read_kmem was told to read some memory.
10:21<dgraves>the rest of the functions deal with trying to read in 1 page from /dev/kmem.
10:21<Magotari>Funny that it did not crash the host when I did it on a real machine though...
10:22<dgraves>yeah, jdike will have to explain that one. :)
10:23<Magotari>I knew what kmem is, but thank you for explaining everything else. :)
10:23<jdike>it's confusing
10:24<jdike>it seems to have corrupted its stack
10:24<dgraves>like it overwrote it when it faulted in kmem?
10:24<dgraves>Magotari: np. i think its even mostly right. ;)
10:25<jdike>no, like it's on the interrupt stack and it takes a signal which starts at the top of that same stack
10:26[~]dgraves thought signals were off during interrupts.
10:26<jdike>let me see what -mm does
10:26<jdike>no, they get flipped on and off
10:26<dgraves>Magotari: what's your host running?
10:26<dgraves>jdike: ah, so it depends where in the interrupt we are?
10:27<Magotari>dgraves: Gentoo.
10:27<jdike>definitely getting stack corruption
10:28<dgraves>Magotari: uname -r?
10:28<Magotari>karol@BlackBox ~ $ uname -r
10:28<Magotari>karol@BlackBox ~ $
10:32<jdike>gdb-ing the wrong image can make a stack look corrupted
10:39<jdike>even with the correct image, it's still corrupted
10:41<dgraves>same way?
10:41<dgraves>or different?
10:41|-|tyler29 [] has quit [Ping timeout: 480 seconds]
10:43<jdike>hard to tell
10:44<Magotari>I am glad to say that this can be done only if you have the permissions to use /dev/kmem, in other words root.
10:44<Magotari>No one can hang a UML just by cat /dev/kmem.
10:44<jdike>but you generally have root access in your UML
10:44<jdike>that's kind of the piont
10:44<Magotari>Yeah, but some of them must be used with nonroot accounts too. Then it would become a security problem.
10:45<Magotari>Glad this is not the case.
10:56|-|tyler29 [] has joined #uml
11:05<jdike>there is a real problem here
11:17<jdike>I forgot that the page fault code can longjmp out of the segv handler
11:17<jdike>interrupts happen on their own stack, which requires some setup on entry, and teardown on exit
11:17<jdike>the longjmp avoids the teardown completely
11:29|-|anderiv [] has left #uml []
11:57|-|netdrake_ [] has quit [Remote host closed the connection]
12:05<dgraves>jdike: yucky!
12:12|-|Baltam [] has quit [Remote host closed the connection]
12:13|-|Baltam [] has joined #uml
12:23|-|silug_ [~steve@] has joined #uml
12:23|-|fo0bar_ [] has joined #uml
12:24|-|tasaro_ [] has joined #uml
12:24|-|Netsplit <-> quits: silug, fo0bar, alb, tasaro, kokoko1, linbot, krau, dgraves, tchan
12:24|-|tchan1 [] has joined #uml
12:25|-|Netsplit over, joins: linbot
12:25|-|albertito [] has joined #uml
12:25|-|the_hydra [~mulyadi@] has joined #uml
12:26<the_hydra>jdike: hello
12:26<Magotari>Hi, the_hydra. Nice to see you again. Thanks for that 2/2 memsplit tip.
12:27|-|Netsplit over, joins: kokoko1
12:27|-|tchan1 changed nick to tchan
12:28|-|Netsplit over, joins: krau
12:28|-|Netsplit over, joins: dgraves
12:29<jdike>that exposed a different bug, BTW
12:30<Magotari>The memsplit or the page fault things?
12:31<jdike>the memsplit
12:32<jdike>Of 62 declarations in kern_util.h, 26 are actually used
12:38<the_hydra>Magotari: you're welcome
12:39<the_hydra>jdike: i was just trying to give Magotari a workaround...I am sure you know the real quirk
12:40<Magotari>Yeah, he fixed it yesterday, sent in to Andrew Morton.
12:40<the_hydra>Magotari: impressive!
12:40<Magotari>Yeah. It is.
12:40<the_hydra>jdike: may I know what was wrong?
12:40<jdike>there was only partial support for the host vmsplits
12:40<jdike>only 3/1 and 2/2 really worked
12:41<the_hydra>jdike: hmm
12:41<Magotari>The right values were calculated and then discarded in the config.
12:41<Magotari>Something like that.
12:43<the_hydra>jdike: so actually the correct offset is known, but some places still use wrong offset?
12:43<jdike>the correct part was a 4 (or 5)-way case correctly calculating the highest valid userspace address
12:44<jdike>the incorrect part was further down saying, let's forget that we know the top of the address space and calculate CONFIG_STUB_CODE and CONFIG_STUB_DATA in only two cases
12:45<the_hydra>hm, got it
12:45<the_hydra>jdike: anyway, glad I could contribute tiny piece of workaround
12:45<jdike>gotta disappear for a bit
12:45<the_hydra>jdike: cya
12:58|-|tyler29 [] has quit [Remote host closed the connection]
13:04|-|tyler29 [] has joined #uml
13:12|-|besonen_mobile_ [] has quit [Read error: Connection reset by peer]
13:31<Magotari>God, using -mm UML is a pain. It might be just me, but everything feels just "muddy". Slow and unresponsive.
13:33<the_hydra>Magotari: well, jdike probably "pushed" out some experimental patches
13:34<Magotari>Yeah, the tickless thing for instance.
13:34<Magotari>I know.
13:34<Magotari>But I don't think it is the fault of that, I think it might be some other -mm stuff
13:34<the_hydra>very likely
13:35<Magotari>I am creating an image for debugging and benchmarking UML, so I can quantify any changes.
13:36|-|mgross [] has joined #uml
13:48|-|tyler29 [] has quit [Quit: ++]
13:59<the_hydra>wb jeff
14:00<the_hydra>jdike: user space question. any idea how can I pause a program right when it quits? my best trial is by using gdb and put breakpoint on exit()
14:00<jdike>what's wrong with that?
14:01<the_hydra>with what?
14:01<the_hydra>my gdb method, you meant?
14:01<jdike>breakpoint on exit?
14:01<the_hydra>not sure, programs like hackbench somehow silenty ignores it
14:02<the_hydra>i mean, it exits "strangely"
14:02<jdike>there's an _exit, I think
14:02<jdike>that's closer to the actual system call
14:03<the_hydra>i was talking about hackbench program written by Rusty Russel...usually used as kernel scheduler benchmark
14:03<the_hydra>jdike: thanks...testing
14:03<the_hydra>so far so good
14:04<jdike>if the thing dies from a signal, then you have to catch the signal with gdb
14:05|-|besonen_mobile [] has joined #uml
14:07|-|dang [] has quit [Quit: Leaving.]
14:09<the_hydra>jdike: you mean, setting signal handler in gdb? sorry.. haven't done anything beyond "break" and "run" using gdb :)
14:09<jdike>look at help handle
14:10<the_hydra>jdike: quick code check reveals that the parent wait() for the children..that probably means I need to treatt SIGCHLD?
14:11<Magotari>Whoever made the gentoo 2006.1 image on nagafix ought to be hurt and educated.
14:12<Magotari>-fomit-frame-pointer on by default, and that is just the tip of the iceberg...
14:13<peterz>Magotari: you seem not to understand the gentoo spirit
14:13<peterz>Magotari: speed (or even the illusion thereof) over everything
14:13<Magotari>I think I do. I run it myself. Yes, with -fomit-frame-pointer in everything. Including glibc.
14:13<Magotari>But I don't think the default is right to be it.
14:14<peterz>quite a wrong default indeed
14:14<Magotari>Nor is march=athlon-xp.
14:14<Magotari>That is great for someone's system, yeah. But not by damn default.
14:17<jdike>not if you're looking for the child exiting
14:17<dgraves>Magotari: but that's gentoo. make it run (seemingly) fast for everyone!
14:17<dgraves>even though the defaults generally work pretty well for binary distors.
14:18<the_hydra>jdike: hm
14:18<Magotari>So far all binary distros I tried were a disaster. Slackware and Arch got pretty close to working, but Arch is damn bizzare in some ways and Slackware has a problem with my video card.
14:28|-|mgross [] has quit [Quit: Leaving]
14:32|-|kokoko1 [~Slacker@] has quit [Ping timeout: 480 seconds]
14:32|-|tyler29 [] has joined #uml
14:39|-|mgross [] has joined #uml
14:47|-|tyler29 [] has quit [Ping timeout: 480 seconds]
14:57|-|tyler29 [] has joined #uml
15:05|-|kokoko1 [~Slacker@] has joined #uml
15:13<the_hydra>jdike: somebody suggest me to use atexit()..somehow it works
15:13|-|kokoko1 [~Slacker@] has quit [Ping timeout: 480 seconds]
15:17|-|krau [~cktakahas@] has quit [Ping timeout: 480 seconds]
15:26|-|krau [~cktakahas@] has joined #uml
15:28|-|krau [~cktakahas@] has quit []
15:28|-|krau [~cktakahas@] has joined #uml
15:34|-|the_hydra [~mulyadi@] has quit [Quit: using sirc version 2.211+KSIRC/1.3.10]
15:37|-|jdike [] has quit [Quit: Leaving]
15:45|-|kokoko1 [~Slacker@] has joined #uml
15:47|-|kos_tom [] has joined #uml
15:55<dgraves>Magotari: whereas i gave up gentoo when it broke every time i updated.
15:55<dgraves>sles is working very nicely now. ;)
15:58<Magotari>I see. Yeah, Gentoo did break a few times. Since then I learned not to upgrade until I really want to.
15:58<Magotari>I would not touch Suse with a long stick, Novell just freaks me out.
16:07<dgraves>Magotari: i had that philosophy as well, but then it took even longer every time i tried ot upgrade openoffice or some essential app for a bug fix or feature i needed.
16:08|-|mgross [] has quit [Remote host closed the connection]
16:08<dgraves>its a great idea, and works well, for instance, on the alpha where you needed to be able to customize stuff, but doesn't seem to be a sustainable model for non geeks.
16:09<Magotari>Right now I am creating a debug rootfs for UML testing, just for myself. And I must say, I am falling in love with Slackware.
16:10<dgraves>i've heard some good things about that one.
16:10<Magotari>Me too. Does not work on my real hardware, but on fake hardware it work EXCELLENT.
16:13|-|mgross [] has joined #uml
16:25|-|SNy [] has quit [Ping timeout: 480 seconds]
16:28|-|netdrake [] has joined #uml
17:03|-|kos_tom [] has quit [Quit: I like core dumps]
17:40|-|tyler29 [] has quit [Ping timeout: 480 seconds]
18:03|-|mgross [] has quit [Quit: Leaving]
18:55|-|Netsplit <-> quits: netdrake
19:00|-|netdrake [] has joined #uml
20:03|-|tasaro_ changed nick to tasaro
22:58|-|VS_ChanLog [] has left #uml [Rotating Logs]
22:59|-|VS_ChanLog [] has joined #uml
23:57|-|silug_ [~steve@] has quit [Ping timeout: 480 seconds]
---Logclosed Wed Oct 03 00:00:47 2007