ll_d_iput() can sometimes clear i_nlink for an inode used by a dentry alias in use.
The dentry can be either for a different path, but hard linked to the same inode. Or it can be a dentry for the same path, but marked invalid/unhashed. The latter can happen with e.g. 3.x kernels that use atomic_open, for which older server do not return MDS_INODELOCK_LOOKUP.
Spontaneous i_nlink clearing can cause stat(2) return invalid st_nlink, since i_nlink is used to transfer this value. Also, the kernel itself sometimes accesses i_nlink (see do_coredump() for instance).
The original intent for i_nlink clearing seems to be that unused inodes should be reclaimed instantly so that GFP_NOFS allocations (such as OBD_ALLOC()) would not face OOM. However, this piece of code seems to be either broken or completely wrong.
Firstly, although clearing nlink does make the VFS reclaim the inode immediately during final iput, there is also a dentry cache. So, in order to reclaim an inode its dentry should be released first. Closing a file will not lead to ll_d_iput(), even a blocking AST only marks dentries invalid and unhashes them. Dentry reclaim would normally happen via GFP_FS
dentry slab shrink.
Secondly, just because OBD_ALLOC() uses GFP_NOFS allocation does not mean that dcache shrink cannot happen if there is not enough memory. Slow path allocation wakes up kswapd and continues indefinitely (see should_alloc_retry()) for any allocation request below PAGE_ALLOC_COSTLY_ORDER. And PAGE_ALLOC_COSTLY_ORDER allocation is a separate issue, in many cases not related to running out of memory.
A test case and a patch that removes find_cbdata functionality completely will be uploaded shortly.