| === karlheg [~karlheg@host-250-237.resnet.pdx.edu] has joined #ubuntu-toolchain | ||
| fabbione | morning | 05:44 |
|---|---|---|
| === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain | ||
| === jbailey [~jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-toolchain | ||
| === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain | ||
| === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain | ||
| desrt | fabbione; gamin issues still/again | 08:04 |
| fabbione | desrt: such as? | 08:05 |
| desrt | desktop not showing new files | 08:05 |
| fabbione | desrt: that's a gamin/nautilus problem | 08:05 |
| desrt | nod. | 08:05 |
| fabbione | if it works for a while and than stop working, blame userland | 08:06 |
| desrt | ah. gotcha. | 08:06 |
| fabbione | it's a flow in the way in which gamin handles the "locks" on dirs to monitor | 08:06 |
| fabbione | i told upstream | 08:06 |
| fabbione | he shitted on me | 08:06 |
| desrt | DV? | 08:06 |
| fabbione | and i am not going to pick up another discussion with him | 08:06 |
| fabbione | i think so yeahg | 08:07 |
| fabbione | it has been a while ago | 08:07 |
| desrt | he's really bad at being critisised | 08:07 |
| fabbione | i didn't criticise him | 08:07 |
| fabbione | i explained to him a problem | 08:07 |
| fabbione | with all the debugging info | 08:07 |
| desrt | bugs reports are critisism :) | 08:07 |
| fabbione | he didn't care | 08:07 |
| fabbione | there are no bugs | 08:07 |
| fabbione | and he did run out of arguments | 08:07 |
| desrt | sigh. | 08:07 |
| fabbione | so he started complaining about my non-perfect english | 08:07 |
| desrt | makes you wonder why we all switched from fam | 08:08 |
| desrt | oh crikey | 08:08 |
| fabbione | and yes, i know my english is not perfect | 08:08 |
| desrt | here's a neat question | 08:08 |
| desrt | what is the problem with applications using libnotify themselves, directly? | 08:08 |
| fabbione | as i told him.. and he suggest to go to a school | 08:08 |
| desrt | *inotify | 08:08 |
| fabbione | and i suggest him to remove a dildo from his $(where the sun doesn't shine" | 08:08 |
| fabbione | i don't know.. | 08:09 |
| fabbione | i didn't even know it existed such a lib | 08:09 |
| desrt | it doesn't. i made a mistake :) | 08:09 |
| desrt | i meant to say "inotify" but said "libnotify" instead | 08:09 |
| desrt | hmmmmm | 08:09 |
| desrt | you gotta figure that almost everything that uses fam uses it via the gnome-vfs | 08:10 |
| fabbione | gamin uses inotify directly | 08:10 |
| desrt | which means that you'd just need to add inotify support to gnome-vfs's file method | 08:10 |
| fabbione | the point is that it does it in a very stupid way | 08:10 |
| desrt | gamin would be cut out of the picture | 08:10 |
| fabbione | oh yeah | 08:10 |
| desrt | and all of its silly problems would go away automatically | 08:10 |
| fabbione | that would be awesome | 08:10 |
| desrt | (and hopefully not too many new silly problems are introduced) | 08:10 |
| desrt | i'm sufficiently intrigued to attempt this | 08:11 |
| fabbione | desrt: the main issue with gamin are: | 08:11 |
| desrt | i wonder if robert is around | 08:11 |
| fabbione | - it doesn't keep an association table between clients and monitored directories | 08:11 |
| fabbione | - it uses signals even if there is a BIG FAT WARNING TO NOT USE SIGNALS for that kind of thing | 08:12 |
| fabbione | so it is basically bad designed | 08:12 |
| fabbione | it is possible to rewrite the code without changing the API | 08:12 |
| desrt | but why bother? | 08:12 |
| fabbione | but i really have no interest in doing it | 08:12 |
| desrt | i mean.. why gam_server? | 08:12 |
| desrt | the kernel is the new gam_server ala inotify | 08:12 |
| fabbione | hmm no | 08:13 |
| desrt | and honestly, i trust the kernel to not screw up an awful lot more than i trust the gam_server | 08:13 |
| fabbione | there is a difference | 08:13 |
| fabbione | be careful | 08:13 |
| fabbione | the kernel provide the feature | 08:13 |
| fabbione | but you need a link layer between the kernel and the clients | 08:13 |
| fabbione | inotify has not been designed to be used directly by many clients afaik | 08:13 |
| fabbione | so you need a "collector" or server | 08:13 |
| desrt | what else in ubuntu uses libfam other than gnome-vfs? | 08:13 |
| desrt | ah | 08:14 |
| fabbione | apt-cache rdepends libfam ? | 08:14 |
| desrt | hm. that's an odd one. | 08:14 |
| fabbione | apt-cache rdepends libgamin0 | wc -l | 08:14 |
| fabbione | 174 | 08:15 |
| desrt | so you think the kernel will start to suffer if it has to notify several clients of updates to a inode? | 08:15 |
| fabbione | at least 174 pkgs | 08:15 |
| fabbione | the point is the info dispatcher | 08:15 |
| fabbione | example: | 08:15 |
| fabbione | you change something in dir foo | 08:15 |
| fabbione | the kernel sends a notification to gamin | 08:15 |
| fabbione | gamin redistribute it to the clients that are registerd to that dir | 08:16 |
| fabbione | the last step is clearly not a kernel job | 08:16 |
| desrt | i don't understand why it isn't | 08:16 |
| fabbione | the kernel has no need to know how many clients are monitoring a dir | 08:16 |
| desrt | each client can open inotify for itself | 08:16 |
| desrt | and the kernel can tell all of them | 08:16 |
| fabbione | yes, that's correct | 08:16 |
| desrt | it actually seems silly to me that we have the indirection at all | 08:16 |
| fabbione | but the point is that inotify will make the kernel suffer during that operation | 08:16 |
| desrt | it made more sense with dnotify simply because dnotify was such a pain to use | 08:17 |
| desrt | hmm | 08:17 |
| fabbione | because you are stalling on kernel execution time | 08:17 |
| fabbione | when that kind of processing can be done in userland | 08:17 |
| desrt | i can't imagine it's worse (or better) than O(n) | 08:17 |
| desrt | plus... we have preempt :) | 08:18 |
| desrt | oh. inotify is a syscall these days | 08:29 |
| desrt | weird. | 08:29 |
| desrt | that sort of seems a lot more reasonable.... | 08:30 |
| desrt | except that i don't know how you poll for a syscall | 08:30 |
| fabbione | check how gamin does it | 08:32 |
| fabbione | the connection between gamin and the kernel is "okish" | 08:32 |
| fabbione | the issue with gamin is the rest | 08:32 |
| desrt | i bet the syscall creates an fd | 08:32 |
| desrt | like socket() | 08:32 |
| fabbione | iirc they use sysfs | 08:33 |
| desrt | i can just picture the politics | 08:33 |
| desrt | <rml> include inotify in linus kernel! | 08:33 |
| desrt | <linus/andrew/whoever> over my dead body if it uses /dev/inotify. such a hack! | 08:33 |
| desrt | *weird solution* | 08:33 |
| fabbione | ehehhe | 08:34 |
| desrt | yup. | 08:35 |
| desrt | inotify_init is a new syscall which returns an fd | 08:35 |
| desrt | then instead of ioctling it you use inotify_add_watch, etc (also new syscalls) | 08:35 |
| fabbione | yes i saw the syscalls | 08:35 |
| fabbione | when backporting inotify from .13-rc | 08:36 |
| desrt | that's perfect | 08:36 |
| desrt | i really like this design | 08:36 |
| desrt | still lets you use standard poll/read io loop stuff with it | 08:36 |
| desrt | wow. something fantastically bad just happened | 08:45 |
| desrt | oh. it's an oops. | 08:45 |
| fabbione | doko: ping? | 08:58 |
| fabbione | doko: unping | 09:00 |
| === desrt tries to reproduce | ||
| desrt | something has gone terribly wrong inside the inotify code | 09:00 |
| === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain | ||
| desrt | http://bugzilla.ubuntu.com/show_bug.cgi?id=12987 | 09:01 |
| doko | fabbione: pong anyway | 09:02 |
| fabbione | doko: thanks i already solved | 09:02 |
| fabbione | desrt: NOTABUG | 09:03 |
| fabbione | # define __NR_inotify_init 291 | 09:03 |
| fabbione | # define __NR_inotify_add_watch 292 | 09:03 |
| fabbione | # define __NR_inotify_rm_watch 293 | 09:03 |
| fabbione | wrong syscalls | 09:03 |
| fabbione | kthxbyw | 09:03 |
| desrt | uhm | 09:03 |
| desrt | so userspace calling the wrong syscalls should generate oopses that take out the entire kernel? | 09:03 |
| fabbione | it is correctly OOPSING to tell you that you are calling the wrong syscall | 09:04 |
| fabbione | it's not crashing | 09:04 |
| fabbione | you need to use the inotify include or whatever defines the syscall | 09:04 |
| fabbione | no need to redifine them | 09:04 |
| desrt | no... the process goes into uninterruptable sleep | 09:04 |
| desrt | and then anything else that i try to open oopses from then on | 09:04 |
| desrt | at best that's a critical security flaw | 09:05 |
| fabbione | can you try do a syscall on another kernel that's not inotify related? | 09:06 |
| fabbione | calling syscall that way is delicate | 09:06 |
| desrt | i'm gonna figure out what actual syscall number causes it | 09:07 |
| desrt | btw: if i do it from the console, the virtual terminal stops working | 09:07 |
| fabbione | the 3 syscalls you are using are invalid | 09:07 |
| fabbione | that's as simple as it gets | 09:07 |
| desrt | it seems that whatever i am calling trashes the stdin/out/err/tty of the calling process | 09:07 |
| desrt | it's 291 | 09:08 |
| desrt | inotify_rm_watch ... | 09:10 |
| fabbione | what arch is that? | 09:10 |
| desrt | i386 | 09:10 |
| fabbione | asm/unistd.h:#define __NR_inotify_rm_watch 291 | 09:11 |
| fabbione | asm-i386/unistd.h:#define __NR_inotify_rm_watch 291 | 09:11 |
| desrt | nod. | 09:11 |
| fabbione | #define __NR_inotify_init 289 | 09:11 |
| fabbione | #define __NR_inotify_add_watch 290 | 09:11 |
| fabbione | #define __NR_inotify_rm_watch 291 | 09:11 |
| fabbione | #define NR_syscalls 292 | 09:11 |
| desrt | so i'm calling inotify_rm_watch as a void function | 09:11 |
| desrt | the inotify_rm_watch syscall doesn't do proper input validation | 09:11 |
| desrt | i really hope this isn't a problem in the upstream kernel...... | 09:12 |
| fabbione | it is probably | 09:12 |
| desrt | ok | 09:12 |
| fabbione | can you try to use another syscall to something completely different? | 09:12 |
| desrt | i'm gonna figure out exactly what registers i'm passing it and what's on the stack | 09:12 |
| fabbione | it can be a flaw in inotify | 09:12 |
| desrt | i think it is a flaw in inotify | 09:12 |
| fabbione | also.. to use syscalls include asm/unistd.h | 09:13 |
| desrt | nod. | 09:13 |
| fabbione | so you don't need to care about numbering | 09:13 |
| desrt | i just copied those out of gamin | 09:13 |
| fabbione | you will need kernel includes... | 09:13 |
| desrt | i have them. i was just being lazy | 09:13 |
| desrt | :/ | 09:13 |
| desrt | sort of glad i was though. found a nice bug :P | 09:13 |
| fabbione | does the kernel oops with gamin?= | 09:14 |
| fabbione | debian/patches/sth-fs_inotify.dpatch:+asmlinkage long sys_inotify_rm_watch(int fd, u32 wd) | 09:14 |
| fabbione | debian/patches/sth-fs_inotify.dpatch:+ int inotify_rm_watch (int fd, __u32 mask); | 09:14 |
| fabbione | debian/patches/sth-fs_inotify.dpatch:+cond_syscall(sys_inotify_rm_watch); | 09:14 |
| desrt | SYS_291(0, 0xbf993e00, 0x41111d8a, 0x8048438, 0x8049634) | 09:14 |
| desrt | ^^ this is the baddy. | 09:14 |
| fabbione | it's probably easier if i allign the numbers of our kernel | 09:15 |
| desrt | ya.. probably | 09:15 |
| desrt | is .13 out yet? | 09:15 |
| fabbione | desrt: i don't have much time right now | 09:15 |
| fabbione | i will send you a kernel to test | 09:15 |
| desrt | fabbione; it's ok. i'm gonna download and build a vanilla kernel | 09:15 |
| desrt | oh. ok. | 09:15 |
| fabbione | .13 is not out yet | 09:15 |
| desrt | well, i'll try vanilla too | 09:15 |
| desrt | this probably isn't ubuntu's fault | 09:15 |
| fabbione | ok that would be nice | 09:15 |
| fabbione | it might as well be .. but a double check will save me time | 09:16 |
| desrt | ok | 09:39 |
| desrt | problem appears to be in vanilla | 09:39 |
| desrt | and i've found the source of it | 09:39 |
| desrt | sys_inotify_rm_watch( int fd, u32 wd ) | 09:40 |
| desrt | struct file *filp; | 09:40 |
| desrt | struct inotify_device *dev; | 09:40 |
| desrt | filp = fget(fd); | 09:40 |
| desrt | if(!filp) return -EBADF; | 09:40 |
| desrt | /* no check to find out what type of fd filp is */ | 09:40 |
| desrt | dev = filp->private_data; /* assign unknown datatype to an inotify_device pointer */ | 09:41 |
| desrt | /* all downhill from hear */ | 09:41 |
| desrt | *here | 09:41 |
| fabbione | desrt: meh.... | 09:45 |
| desrt | should i email LKML or what? | 09:45 |
| fabbione | mail rlove first | 09:46 |
| desrt | ok | 09:46 |
| fabbione | just avoid the speech about different syscall nums | 09:46 |
| fabbione | use the vanilla one as reference | 09:46 |
| fabbione | otherwise we will start bouncing emails back and forward about ubuntu kernel being broken | 09:46 |
| fabbione | when the problem is in vanilla too | 09:46 |
| doko | fabbione, lamont: did the new curl 7.14 build on sparc and hppa? | 09:47 |
| desrt | :) | 09:47 |
| fabbione | doko: is it in universe or main=? | 09:48 |
| fabbione | well i guess until seb128 will learn to use versioned build-dep, it doesn't really matter.. | 09:49 |
| fabbione | all of gnome on sparc is broken | 09:49 |
| doko | fabbione: main | 09:49 |
| fabbione | because it keeps coming up with _XOPEN_SOURCE somewhere | 09:49 |
| fabbione | doko: it's probably queued | 09:50 |
| fabbione | curl_7.14.0-2ubuntu1 | 09:50 |
| fabbione | yeah it is | 09:50 |
| doko | ok, thanks | 10:01 |
| === desrt doesn't suppose there's any danger of 2.6.13 coming out tomorrow | ||
| fabbione | desrt: ehehhe | 10:02 |
| desrt | i don't really think there's a need to email andrew morton | 10:02 |
| fabbione | no i don't think so | 10:02 |
| desrt | btw | 10:02 |
| desrt | does 'UPSTREAM' mean upstream has been notified about the issue? | 10:03 |
| fabbione | desrt: yes | 10:03 |
| desrt | cool. | 10:03 |
| desrt | now that that's over and done with | 10:04 |
| === desrt goes back to playing with inotify :) | ||
| desrt | thanks for your help | 10:04 |
| desrt | as per usual :) | 10:04 |
| === chmj [~chmj@196.36.161.235] has joined #ubuntu-toolchain | ||
| fabbione | desrt: thanks to you for being so nice! | 10:07 |
| chmj | morning | 10:08 |
| chmj | O.O | 10:08 |
| fabbione | hey chmj | 10:35 |
| fabbione | doko: | 12:21 |
| fabbione | configure: error: jni.h could not be found. Mismatch between gcc and libgcj or libgcj-devel missing? | 12:21 |
| fabbione | (building OO2) | 12:21 |
| fabbione | what can cause that? | 12:21 |
| doko | strange. the build-deps are all there. which version do you build? | 12:22 |
| fabbione | 1.9.116-0.pre1ubuntu1 | 12:22 |
| fabbione | the one in the archive | 12:22 |
| fabbione | i will forward the build log | 12:25 |
| fabbione | it's only 300K | 12:25 |
| doko | ok | 12:26 |
| doko | ls -l /usr/lib/jvm/java-gcj/include | 12:29 |
| doko | ok, we need an update for java-gcj-compat | 12:29 |
| fabbione | ok :) | 12:29 |
| fabbione | good to know | 12:29 |
| fabbione | see.. sparc isn't completely useless :) | 12:29 |
| fabbione | doko | 12:29 |
| fabbione | any news about binutils? | 12:29 |
| doko | what did I forget? :( | 12:30 |
| fabbione | sparc starts to feel the pressure of building half of the desktop | 12:30 |
| fabbione | the linking problem? | 12:30 |
| fabbione | with -Wl,--as-needed? | 12:30 |
| fabbione | https://bugzilla.ubuntu.com/show_bug.cgi?id=12822 <- | 12:31 |
| doko | hmm, I thought that was a libtool/pkgconfig problem, which keybuk and jbailey would address? | 12:31 |
| fabbione | no no | 12:31 |
| fabbione | look at the bug | 12:31 |
| fabbione | there is a simple test case | 12:31 |
| fabbione | with hello world | 12:31 |
| doko | ok, I'll look | 12:32 |
| fabbione | the other bug you are talking about is to do in such a way that gnome doesn't need --as-needed | 12:32 |
| fabbione | but binutils is still buggy :) | 12:32 |
| fabbione | on sparc and alpha | 12:32 |
| fabbione | i need to grab something to eat | 12:33 |
| fabbione | later | 12:33 |
| === doko [~doko___@dsl-084-059-067-130.arcor-ip.net] has joined #ubuntu-toolchain | ||
| === jbailey [~jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-toolchain | ||
| === chmj [~chmj@196.36.161.235] has joined #ubuntu-toolchain | ||
| lamont | doko: several timeouts on hppa with defunct processes, during tests | 03:09 |
| fabbione | hey lamont | 03:09 |
| fabbione | lamont: any news about ia64? | 03:09 |
| doko | lamont: java? | 03:10 |
| lamont | doko: curl | 03:10 |
| lamont | fabbione: will have news either way in a few hours | 03:10 |
| fabbione | lamont: ok thanks | 03:10 |
| doko | lamont: hmm, I suspect, that is the buildd environment, I'll check here locally | 03:11 |
| lamont | doko: wouldn't terribly surprise me | 03:12 |
| === lamont__ [~lamont@15.238.5.126] has joined #ubuntu-toolchain | ||
| fabbione | desrt: there is a big bunch of patches in git for inotify | 05:32 |
| fabbione | one of them is the one we need | 05:32 |
| fabbione | they will be in for the next upload | 05:32 |
| desrt | fabbione; ya. i just got an email from robert :) | 05:50 |
| fabbione | desrt: i just finished the rediffing | 05:50 |
| fabbione | :) | 05:50 |
| desrt | that was my first kernel security vuln | 05:50 |
| desrt | i'm sort of disappointed that it was already fixed :P | 05:51 |
| fabbione | ehhee | 05:51 |
| fabbione | let see if it builds | 06:03 |
| fabbione | desrt: anyway we should seriously move our kernel talks to #ubuntu-kernel :) | 06:04 |
| desrt | heh. i swear i originally came here to talk about the toolchain :) | 06:05 |
| === Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-toolchain | ||
| jbailey | elmo: ping? Breezy-i386 chroot on concordia seems to have way out of date apt sources. | 06:16 |
| === doko [~doko___@dsl-084-059-085-139.arcor-ip.net] has joined #ubuntu-toolchain | ||
| === elmo_ [~james@83-216-156-21.jamest747.adsl.metronet.co.uk] has joined #ubuntu-toolchain | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!