[05:44] <fabbione> morning
[08:04] <desrt> fabbione; gamin issues still/again
[08:05] <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:06] <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:07] <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:08] <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:09] <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:10] <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:11] <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:12] <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:13] <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:14] <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:15] <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:16] <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:17] <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:18] <desrt> plus... we have preempt :)
[08:29] <desrt> oh.  inotify is a syscall these days
[08:29] <desrt> weird.
[08:30] <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:32] <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:33] <fabbione> iirc they use sysfs
[08:33] <desrt> i can just picture the politics
 include inotify in linus kernel!
 over my dead body if it uses /dev/inotify.  such a hack!
[08:33] <desrt> *weird solution*
[08:34] <fabbione> ehehhe
[08:35] <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:36] <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:45] <desrt> wow.  something fantastically bad just happened
[08:45] <desrt> oh.  it's an oops.
[08:58] <fabbione> doko: ping?
[09:00] <fabbione> doko: unping
[09:00] <desrt> something has gone terribly wrong inside the inotify code
[09:01] <desrt> http://bugzilla.ubuntu.com/show_bug.cgi?id=12987
[09:02] <doko> fabbione: pong anyway
[09:02] <fabbione> doko: thanks i already solved
[09:03] <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:04] <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:05] <desrt> at best that's a critical security flaw
[09:06] <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:07] <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:08] <desrt> it's 291
[09:10] <desrt> inotify_rm_watch ...
[09:10] <fabbione> what arch is that?
[09:10] <desrt> i386
[09:11] <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:12] <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:13] <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:14] <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:15] <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:16] <fabbione> it might as well be .. but a double check will save me time
[09:39] <desrt> ok
[09:39] <desrt> problem appears to be in vanilla
[09:39] <desrt> and i've found the source of it
[09:40] <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:41] <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:45] <fabbione> desrt: meh....
[09:45] <desrt> should i email LKML or what?
[09:46] <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:47] <doko> fabbione, lamont: did the new curl 7.14 build on sparc and hppa?
[09:47] <desrt> :)
[09:48] <fabbione> doko: is it in universe or main=?
[09:49] <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:50] <fabbione> doko: it's probably queued
[09:50] <fabbione>   curl_7.14.0-2ubuntu1
[09:50] <fabbione> yeah it is
[10:01] <doko> ok, thanks
[10:02] <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:03] <desrt> does 'UPSTREAM' mean upstream has been notified about the issue?
[10:03] <fabbione> desrt: yes
[10:03] <desrt> cool.
[10:04] <desrt> now that that's over and done with
[10:04] <desrt> thanks for your help
[10:04] <desrt> as per usual :)
[10:07] <fabbione> desrt: thanks to you for being so nice!
[10:08] <chmj> morning 
[10:08] <chmj> O.O
[10:35] <fabbione> hey chmj 
[12:21] <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:22] <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:25] <fabbione> i will forward the build log
[12:25] <fabbione> it's only 300K
[12:26] <doko> ok
[12:29] <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:30] <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:31] <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:32] <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:33] <fabbione> i need to grab something to eat
[12:33] <fabbione> later
[03:09] <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:10] <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:11] <doko> lamont: hmm, I suspect, that is the buildd environment, I'll check here locally
[03:12] <lamont> doko: wouldn't terribly surprise me
[05:32] <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:50] <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:51] <desrt> i'm sort of disappointed that it was already fixed :P
[05:51] <fabbione> ehhee
[06:03] <fabbione> let see if it builds
[06:04] <fabbione> desrt: anyway we should seriously move our kernel talks to #ubuntu-kernel :)
[06:05] <desrt> heh.  i swear i originally came here to talk about the toolchain :)
[06:16] <jbailey> elmo: ping?   Breezy-i386 chroot on concordia seems to have way out of date apt sources.