Bug in current -git tree causing dbus and gnome to chew up cpu time

Bug in current -git tree causing dbus and gnome to chew up cpu time

[Greg KH]

Hi,

I've used 'git bisect' to track down a change in the latest git tree
that is causing dbus-daemon to sit and spin at the time GNOME launches,
preventing nautlius from ever running.

The bad commit is:
commit eb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1
Author: Andreas Gruenbacher <agruen@suse.de>
Date:   Mon Feb 12 00:51:47 2007 -0800

    [PATCH] Fix d_path for lazy unmounts

With that patch out, GNOME startup works just fine.  I have a strace of
the dbus process running showing the problem, if anyone thinks that will
help out any.

I'm running pretty new GNOME and dbus here:
	dbus 1.0.2
	gnome 2.16.2
	hal 0.5.7.1
	nautilus 2.16.3

Any ideas of things I can test?

thanks,

greg k-h

Re: Bug in current -git tree causing dbus and gnome to chew up cpu time

[Andreas Gruenbacher]

On Tuesday 13 February 2007 11:51, Greg KH wrote:
> Hi,
>
> I've used 'git bisect' to track down a change in the latest git tree
> that is causing dbus-daemon to sit and spin at the time GNOME launches,
> preventing nautlius from ever running.
>
> The bad commit is:
> commit eb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1
> Author: Andreas Gruenbacher <agruen@suse.de>
> Date:   Mon Feb 12 00:51:47 2007 -0800
>
>     [PATCH] Fix d_path for lazy unmounts
>
> With that patch out, GNOME startup works just fine.  I have a strace of
> the dbus process running showing the problem, if anyone thinks that will
> help out any.

I'd like to see that, please.

> I'm running pretty new GNOME and dbus here:
> 	dbus 1.0.2
> 	gnome 2.16.2
> 	hal 0.5.7.1
> 	nautilus 2.16.3
>
> Any ideas of things I can test?

Sorry for the breakage. Printk of the __d_path result may tell:

Index: b/fs/dcache.c
===================================================================
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1803,6 +1803,8 @@ char *__d_path(struct dentry *dentry, st

 out:
        spin_unlock(&dcache_lock);
+	printk(KERN_DEBUG "%s(%d): %s\n", current->comm, current->pid,
+	       IS_ERR(buffer) ? "failed" : buffer);
	return buffer;

 global_root:

Thanks,
Andreas

Re: Bug in current -git tree causing dbus and gnome to chew up cpu time

[Andreas Gruenbacher]

On Tuesday 13 February 2007 12:01, Greg KH wrote:
> Attached below.

I'm getting a CRC error on that file. Would you mind to resend?

Thanks,
Andreas

Re: Bug in current -git tree causing dbus and gnome to chew up cpu time

[Greg KH]

On Tue, Feb 13, 2007 at 11:58:02AM -0800, Andreas Gruenbacher wrote:
> > I'm running pretty new GNOME and dbus here:
> > 	dbus 1.0.2
> > 	gnome 2.16.2
> > 	hal 0.5.7.1
> > 	nautilus 2.16.3
> >
> > Any ideas of things I can test?
> 
> Sorry for the breakage. Printk of the __d_path result may tell:
> 
> Index: b/fs/dcache.c
> ===================================================================
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -1803,6 +1803,8 @@ char *__d_path(struct dentry *dentry, st
> 
>  out:
>         spin_unlock(&dcache_lock);
> +	printk(KERN_DEBUG "%s(%d): %s\n", current->comm, current->pid,
> +	       IS_ERR(buffer) ? "failed" : buffer);
> 	return buffer;
> 

This causes the following to just loop over and over, incrementing the
pid:

gnome-vfs-daemo(8914): 
gnome-vfs-daemo(8914): /
gnome-vfs-daemo(8914): /proc
gnome-vfs-daemo(8914): /sys
gnome-vfs-daemo(8914): /dev
gnome-vfs-daemo(8914): /dev/pts
gnome-vfs-daemo(8914): /dev/shm
gnome-vfs-daemo(8914): /proc/bus/usb
gnome-vfs-daemo(8914): /proc/sys/fs/binfmt_misc
gnome-vfs-daemo(8918): 
gnome-vfs-daemo(8918): /
gnome-vfs-daemo(8918): /proc
gnome-vfs-daemo(8918): /sys
gnome-vfs-daemo(8918): /dev
gnome-vfs-daemo(8918): /dev/pts
gnome-vfs-daemo(8918): /dev/shm
gnome-vfs-daemo(8918): /proc/bus/usb
gnome-vfs-daemo(8918): /proc/sys/fs/binfmt_misc

and so on...

I'm running gnome-vfs version 2.6.13 if that matters.

Anything else I can try?

thanks,

greg k-h

Re: Bug in current -git tree causing dbus and gnome to chew up cpu time

[Andreas Gruenbacher]

On Tuesday 13 February 2007 13:37, Greg KH wrote:
> On Tue, Feb 13, 2007 at 11:58:02AM -0800, Andreas Gruenbacher wrote:
> > > I'm running pretty new GNOME and dbus here:
> > > 	dbus 1.0.2
> > > 	gnome 2.16.2
> > > 	hal 0.5.7.1
> > > 	nautilus 2.16.3
> > >
> > > Any ideas of things I can test?
> >
> > Sorry for the breakage. Printk of the __d_path result may tell:
> >
> > Index: b/fs/dcache.c
> > ===================================================================
> > --- a/fs/dcache.c
> > +++ b/fs/dcache.c
> > @@ -1803,6 +1803,8 @@ char *__d_path(struct dentry *dentry, st
> >
> >  out:
> >         spin_unlock(&dcache_lock);
> > +	printk(KERN_DEBUG "%s(%d): %s\n", current->comm, current->pid,
> > +	       IS_ERR(buffer) ? "failed" : buffer);
> > 	return buffer;
>
> This causes the following to just loop over and over, incrementing the
> pid:
>
> gnome-vfs-daemo(8914):

That's the weird case, and it should only trigger if there's no path to be 
recovered from what gnome-vfs-deamon calls d_path on, like a lazily unmounted 
filesystem. (A bind mount wouldn't do.)

> I'm running gnome-vfs version 2.6.13 if that matters.
>
> Anything else I can try?

I guess I'll just have to check what gnome-vfs-deamon does, thanks.

Andreas

Re: Bug in current -git tree causing dbus and gnome to chew up cpu time

[Neil Brown]

On Tuesday February 13, greg@kroah.com wrote:
> 
> This causes the following to just loop over and over, incrementing the
> pid:
> 
> gnome-vfs-daemo(8914): 

That's odd.  getcwd returning an empty string.
I can only see that happening if you do the equivalent of
   chdir("/");
   chroot("/somewhere");
   getcwd(buf,sizeof(buf));

That would return an empty string with the new code but not with the
old.
But I cannot imagine gnome-vfs-daemon doing a chroot, as it does not
run as root.

You could try removing the
		if (*buffer == '/') {
			buffer++;
			buflen++;
		}
from the new __d_path.  But that still wouldn't really explain what
was happening.

Maybe also put a WARN_ON(! *buffer) just before the return to find out
exactly what is going on when the empty string is returned.

NeilBrown

Re: Bug in current -git tree causing dbus and gnome to chew up cpu time

[Andreas Gruenbacher]

On Tuesday 13 February 2007 14:39, Neil Brown wrote:
> On Tuesday February 13, greg@kroah.com wrote:
> > This causes the following to just loop over and over, incrementing the
> > pid:
> >
> > gnome-vfs-daemo(8914):
>
> That's odd.  getcwd returning an empty string.
> I can only see that happening if you do the equivalent of
>    chdir("/");
>    chroot("/somewhere");
>    getcwd(buf,sizeof(buf));

The other case I'm aware of is this:

  $ mount -o loop image /mnt
  $ cd /mnt
  $ umount -l /mnt
  $ /bin/pwd

Andreas

Re: Bug in current -git tree causing dbus and gnome to chew up cpu time

[Alessandro Suardi]

On 2/13/07, Greg KH <greg@kroah.com> wrote:
> Hi,
>
> I've used 'git bisect' to track down a change in the latest git tree
> that is causing dbus-daemon to sit and spin at the time GNOME launches,
> preventing nautlius from ever running.
>
> The bad commit is:
> commit eb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1
> Author: Andreas Gruenbacher <agruen@suse.de>
> Date:   Mon Feb 12 00:51:47 2007 -0800
>
>     [PATCH] Fix d_path for lazy unmounts
>
> With that patch out, GNOME startup works just fine.  I have a strace of
> the dbus process running showing the problem, if anyone thinks that will
> help out any.
>
> I'm running pretty new GNOME and dbus here:
>         dbus 1.0.2
>         gnome 2.16.2
>         hal 0.5.7.1
>         nautilus 2.16.3
>
> Any ideas of things I can test?

Just to add a data point, I see the same problem (startx never
 completes, gnome-vfs-daemon keeps getting forked by dbus
 to no end) on 2.6.20-git9 while -git7 is fine, and my pieces are
 from FC6 updates as of two days ago or so:

[asuardi@sandman ~]$ rpm -q dbus gnome-vfs2 hal nautilus
dbus-1.0.1-9.fc6
gnome-vfs2-2.16.2-2.fc6
hal-0.5.8.1-6.fc6
nautilus-2.16.2-7.fc6

Since the patch breaks userspace in a deadly way, I guess
 it should be reverted until an usable version of the fix can
 be found. And yes, I'm up for testing of course.

--alessandro

 "but I thought that I should let you know
  the things that I don't always show
  might not be worth the time it took"

     (Steve Wynn, 'If My Life Was An Open Book')

Re: Bug in current -git tree causing dbus and gnome to chew up cpu time

[Andreas Gruenbacher]

Hi,

I've described the problem and possible fixes in the "Re: [PATCH] Fix d_path 
for lazy unmounts" thread, Message-Id: 200702140019.36378.agruen@suse.de.

Thanks,
Andreas

Re: Bug in current -git tree causing dbus and gnome to chew up cpu time

[Alessandro Suardi]

On 2/14/07, Andreas Gruenbacher <agruen@suse.de> wrote:
> Hi,
>
> I've described the problem and possible fixes in the "Re: [PATCH] Fix d_path
> for lazy unmounts" thread, Message-Id: 200702140019.36378.agruen@suse.de.

Yes, I saw that. But there isn't any patch for me to test, and my
 userspace remains broken. Please don't get me wrong - I'm
 not bitching about this, but I will effectively not be able to test
 newer snapshots until either a fix for this new bug gets in, or
 the commit that introduced the bug gets reverted.

Thanks,

--alessandro

 "but I thought that I should let you know
  the things that I don't always show
  might not be worth the time it took"

     (Steve Wynn, 'If My Life Was An Open Book')

Re: Bug in current -git tree causing dbus and gnome to chew up cpu time

[Greg KH]

On Wed, Feb 14, 2007 at 12:13:52PM +0100, Alessandro Suardi wrote:
> On 2/14/07, Andreas Gruenbacher <agruen@suse.de> wrote:
> >Hi,
> >
> >I've described the problem and possible fixes in the "Re: [PATCH] Fix 
> >d_path
> >for lazy unmounts" thread, Message-Id: 200702140019.36378.agruen@suse.de.
> 
> Yes, I saw that. But there isn't any patch for me to test, and my
> userspace remains broken. Please don't get me wrong - I'm
> not bitching about this, but I will effectively not be able to test
> newer snapshots until either a fix for this new bug gets in, or
> the commit that introduced the bug gets reverted.

The commit was reverted, the latest git tree should work just fine.

thanks,

greg k-h