a problem with dget

a problem with dget

[Nir Tzachar]

hello all.

i encountered a strange problem, involving the reference count of
dentries.

first, let me describe my file system (i'll be brief.. ):
im implementing a file system which is supposed to emulate an object
storage device. i use a wrapper like file system (much like wrapfs,
and actually based on it) to store files on an underlying f/s as objects.

i hope someone can help me, i've been tackling this problem for more than
a week: when i create a file(say "tmp"), all is fine.
the problem arises when i umount and then remount the file system.
after im done with lookup (inode->i_op->lookup), dentry->d_count.counter
==1, as should be. but, when i enter the unlink function
(inode->i_op->unlink ) its dentry->d_count.counter == 0 . why is that?
nowhere in the vfs code does anyone decreases the counter b4
inode->i_op->unlink is called . am i right?

the problem happens every time i try to do a dget an any dentry.

anyway, im sure the problem is in my code, but maybe someone has a hunch
which could help.

thank you all.


========================================================================
nir.

Re: a problem with dget

[Jan Hudec]

On Tue, Mar 25, 2003 at 06:47:00PM +0200, Nir Tzachar wrote:
> hello all.
> 
> i encountered a strange problem, involving the reference count of
> dentries.
> 
> first, let me describe my file system (i'll be brief.. ):
> im implementing a file system which is supposed to emulate an object
> storage device. i use a wrapper like file system (much like wrapfs,
> and actually based on it) to store files on an underlying f/s as objects.
> 
> i hope someone can help me, i've been tackling this problem for more than
> a week: when i create a file(say "tmp"), all is fine.
> the problem arises when i umount and then remount the file system.
> after im done with lookup (inode->i_op->lookup), dentry->d_count.counter
> ==1, as should be. but, when i enter the unlink function
> (inode->i_op->unlink ) its dentry->d_count.counter == 0 . why is that?
> nowhere in the vfs code does anyone decreases the counter b4
> inode->i_op->unlink is called . am i right?

Isn't that the little confusing semantics of lookup that's biting you?
When ->lookup returns non-NULL, real_lookup (the caller) puts the dentry
passed to ->lookup. So if you fill it in, you must return NULL and *NOT*
the dentry you recieved!

> the problem happens every time i try to do a dget an any dentry.

Yes, because you need to hold a reference to do dget.

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

Re: a problem with dget

[Nir Tzachar]

> Isn't that the little confusing semanticsof lookup that's biting you?
> When ->lookup returns non-NULL, real_lookup (the caller) puts the dentry
> passed to ->lookup. So if you fill it in, you must return NULL and *NOT*
> the dentry you recieved!
>
> > the problem happens every time i try to do a dget an any dentry.
>
> Yes, because you need to hold a reference to do dget.
>

thanks, this was my problem exactly.

anyway, who uses these semantics? which f/s needs to reallocate a dentry
and discards the one supplied to it? and why?



========================================================================
nir.

Re: a problem with dget

[Jan Hudec]

On Wed, Mar 26, 2003 at 11:45:22AM +0200, Nir Tzachar wrote:
> > Isn't that the little confusing semanticsof lookup that's biting you?
> > When ->lookup returns non-NULL, real_lookup (the caller) puts the dentry
> > passed to ->lookup. So if you fill it in, you must return NULL and *NOT*
> > the dentry you recieved!
> >
> > > the problem happens every time i try to do a dget an any dentry.
> >
> > Yes, because you need to hold a reference to do dget.
> >
> 
> thanks, this was my problem exactly.
> 
> anyway, who uses these semantics? which f/s needs to reallocate a dentry
> and discards the one supplied to it? and why?

I think NFS may cause any filesystem to need this. The problem is, that
when a partition is exported, disconnected entries may appear (created
by fh_to_dentry). When/if these entries are then looked up, they should
be connected. This semantics migh be used to do the connecting (it's not
necessary, but it's a useful optimization).

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

Re: [FiST] a problem with dget

[Jerome de Vivie]

Nir Tzachar wrote:
> 
> hello all.
> 
> i encountered a strange problem, involving the reference count of
> dentries.
> 
> first, let me describe my file system (i'll be brief.. ):
> im implementing a file system which is supposed to emulate an object
> storage device. i use a wrapper like file system (much like wrapfs,
> and actually based on it) to store files on an underlying f/s as objects.
> 
> i hope someone can help me, i've been tackling this problem for more than
> a week: when i create a file(say "tmp"), all is fine.
> the problem arises when i umount and then remount the file system.
> after im done with lookup (inode->i_op->lookup), dentry->d_count.counter
> ==1, as should be. but, when i enter the unlink function
> (inode->i_op->unlink ) its dentry->d_count.counter == 0 . why is that?
> nowhere in the vfs code does anyone decreases the counter b4
> inode->i_op->unlink is called . am i right?

This counter should at least be at 1. You should do a dget before each
lower level call and a dput after (in case the dentry is freed by
another process when you are inside unlink). Tracking usage count is not
easy, you can try this macro inside "lookup" and "d_release":

#if 1 /* for debugging dget/dput */
#define dcount(x) printk("(%s):%i  at %s:%i\n",(x)->d_name.name,
atomic_read(&(x)->d_count), __FILE__, __LINE__)
#else
#define dcount(x)
#endif

Try also to unmount the lower level fs. If there are pending dentries,
you will see this message:
"VFS: Busy inodes after unmount. Self-destruct in 5 seconds.  Have a
nice day..."

regards,

j.

-- 
Jérôme de Vivie
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [FiST] a problem with dget

[Nir Tzachar]

> Try also to unmount the lower level fs. If there are pending dentries,
> you will see this message:
> "VFS: Busy inodes afterunmount. Self-destruct in 5 seconds.Have a
> nice day..."
>

good morning (to me its morning ... )

well, i found my problem, and it was a combination of mistakes made by me:
1. i didnt understand the semantics of the inode->i_op->lookup function.
   ( i used wrong return codes.. )
2. i did not increase usage count of inodes upon creation, but did
   decrease it upon release (very dumb of me. )

anyway, i still get the "VFS: Busy inodes ... " msg after i umount my fs.
i dont know what im doing wrong, but the same msg also appears when im
umounting wrapfs.

any idea??





========================================================================
nir.

Re: [FiST] a problem with dget

[Erez Zadok]

In message <Pine.LNX.4.44_heb2.09.0303271006090.2260-100000@ruby>, Nir Tzachar writes:
> > Try also to unmount the lower level fs. If there are pending dentries,
> > you will see this message:
> > "VFS: Busy inodes afterunmount. Self-destruct in 5 seconds.Have a
> > nice day..."
> >
> 
> good morning (to me its morning ... )
> 
> well, i found my problem, and it was a combination of mistakes made by me:
> 1. i didnt understand the semantics of the inode->i_op->lookup function.
>    ( i used wrong return codes.. )
> 2. i did not increase usage count of inodes upon creation, but did
>    decrease it upon release (very dumb of me. )
> 
> anyway, i still get the "VFS: Busy inodes ... " msg after i umount my fs.
> i dont know what im doing wrong, but the same msg also appears when im
> umounting wrapfs.
> 
> any idea??

These kind of messages typically mean that you have neglected to decrement
the refcount for some objects (inodes, dentries).  So somewhere, you, or a
side-effect of some other VFS method, an object's refcnt is incremented, but
it's not decremented in the right place.

Erez.

Re: [FiST] a problem with dget

[Nir Tzachar]

> These kind of messages typically mean that you have neglected to decrement
> the refcount for some objects (inodes, dentries).  So somewhere, you, or a
> side-effect of some other VFS method, an object's refcnt is incremented, but
> it's not decremented in the right place.
> 

well, as i wrote, it happens when i use ur code without any modifications.
its version 0.0.6 .

-- 
========================================================================
nir.