This is a discussion on Kernel BUG reported - Linux ; I'm not going to post the bug. It's most likely a bug in my code so I would first like to ask for your opinion I'm writing this filesystem that contains virtual inodes as well as physical ones. That is, ...
I'm not going to post the bug. It's most likely a bug in my code so I
would first like to ask for your opinion
I'm writing this filesystem that contains virtual inodes as well as
physical ones. That is, there can be directories that are created on
the fly and have no physical backup.
This comes into play when VFS does lookup on a path. In the path I have
filenames corresponding to logical inodes (they don't exist) and
physical ones. I allocate the logical inodes with
iget_locked and then unlock_new_inode.
All goes well, I add the inode to the dentry, but after that, error,
panic, all is lost! Kernel reports a bug in the dget function.
Searching through the code, I figured that after I give him my
"logical" dentry, he adds it to the cache.
But then, when he gets to the next element in the path, he will try to
allocate a dentry that has for parent the logical dentry. That's when
he calls dget to increment the reference count to the parent. When he
tries to read the dentry->d_count field, inside dget, it fails. As far
as I could read from the BUG report, I figured that he sees the field
as NULL. Which is stupid, because that is set to 1 when the logical
dentry is allocated in the first place.
The problem is that all works fine with the dentrys that have physical
inodes. So the only difference is in the inode attached to the dentry.
Is there some special issue with the dentry structure that I'm not
aware of, or is it really a BUG? I should mention that I'm using