Description of problem:

There is a good chance that, the inode on which unref came has already been
zero refed and added to the purge list. This can happen when inode table is
being destroyed (glfs_fini is something which destroys the inode table).

Consider a directory 'a' which has a file 'b'. Now as part of inode table destruction
zero refing of inodes does not happen from leaf to the root. It happens in the order
inodes are present in the list. So, in this example, the dentry of 'b' would have its
parent set to the inode of 'a'. So if 'a' gets zero refed first (as part of
inode table cleanup) and then 'b' has to zero refed, then dentry_unset is called on
the dentry of 'b' and it further goes on to call inode_unref on b's parent which is
'a'. In this situation, GF_ASSERT would be called as the refcount of 'a' has been
already set to zero.

So, return the inode (in the function inode_unref without doing anything) if the
inode table cleanup has already started and inode's refcount is zero.


Version-Release number of selected component (if applicable):


How reproducible:

This might happen when glfs_fini is called from a gfapi based process.

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info: