debugfs oddity

debugfs oddity

[Johannes Berg]

Recently, I observed (in bcm43xx) that debugfs seems to keep things
alive when userspace still has a directory open. Consider the following
sequence of events:
 (a) kernel code creates a directory in debugfs
 (b) user changes current directory to that
 (c) kernel code removes that directory in debugfs

Now, consider the equivalent sequence in a regular filesystem (or
tmpfs):
 (a') user creates directory
 (b') user cd's into it
 (c') user deletes directory from a different shell

The same thing should happen, in both cases the directory is kept around
in a way until the process that has the current dir in the dead
directory gives it up.

Now, however, consider
 (d') user creates directory with the same name

This works fine, and the old process sees nothing that happens in the
new directory, as expected. However,
 (d) kernel code tries to create a debugfs directory with the same name

does not work at all.

Is this expected behaviour? It seems that once a driver requested that a
directory is removed it can rightfully expect to be able to recreate it
afterwards even if there's still the need to keep it lingering around
for a bit.

Similar things can probably happen when attributes are kept open, but I
haven't tested this. I have also not tested sysfs or configfs.

johannes

Re: debugfs oddity

[Greg KH]

On Mon, Oct 02, 2006 at 11:25:04AM +0200, Johannes Berg wrote:
> Recently, I observed (in bcm43xx) that debugfs seems to keep things
> alive when userspace still has a directory open. Consider the following
> sequence of events:
>  (a) kernel code creates a directory in debugfs
>  (b) user changes current directory to that
>  (c) kernel code removes that directory in debugfs
> 
> Now, consider the equivalent sequence in a regular filesystem (or
> tmpfs):
>  (a') user creates directory
>  (b') user cd's into it
>  (c') user deletes directory from a different shell
> 
> The same thing should happen, in both cases the directory is kept around
> in a way until the process that has the current dir in the dead
> directory gives it up.
> 
> Now, however, consider
>  (d') user creates directory with the same name
> 
> This works fine, and the old process sees nothing that happens in the
> new directory, as expected. However,
>  (d) kernel code tries to create a debugfs directory with the same name
> 
> does not work at all.

True, that is because the kernel thinks there is still an active dentry
with that name present in the system.

> Is this expected behaviour? It seems that once a driver requested that a
> directory is removed it can rightfully expect to be able to recreate it
> afterwards even if there's still the need to keep it lingering around
> for a bit.
> 
> Similar things can probably happen when attributes are kept open, but I
> haven't tested this. I have also not tested sysfs or configfs.

sysfs works much differently here, as does configfs.  debugfs just uses
the vfs layer's ramfs stack, so any potential problem here is probably
also present in ramfs.  Have you tried that out?

thanks,

greg k-h

Re: debugfs oddity

[Johannes Berg]

On Mon, 2006-10-02 at 22:28 -0700, Greg KH wrote:

> sysfs works much differently here, as does configfs.  debugfs just uses
> the vfs layer's ramfs stack, so any potential problem here is probably
> also present in ramfs.  Have you tried that out?

Just had a go -- ramfs works as expected, at least when I do the dance
from userspace as I had in (a')-(d').

johannes

Re: debugfs oddity

[Greg KH]

On Wed, Oct 04, 2006 at 09:20:46AM +0200, Johannes Berg wrote:
> On Mon, 2006-10-02 at 22:28 -0700, Greg KH wrote:
> 
> > sysfs works much differently here, as does configfs.  debugfs just uses
> > the vfs layer's ramfs stack, so any potential problem here is probably
> > also present in ramfs.  Have you tried that out?
> 
> Just had a go -- ramfs works as expected, at least when I do the dance
> from userspace as I had in (a')-(d').

I don't understand.  Does ramfs have the same issues you feel debugfs
has?  Or does it work like a disk based file system?

thanks,

greg k-h

Re: debugfs oddity

[Johannes Berg]

On Wed, 2006-10-04 at 01:12 -0700, Greg KH wrote:

> I don't understand.  Does ramfs have the same issues you feel debugfs
> has?  Or does it work like a disk based file system?

It works like tmpfs and disk based filesystems and allows re-creating a
removed directory.

johannes