graphene
graphene copied to clipboard
Filesystem code should not reuse dentries
Problem
The current code marks a dentry as DENTRY_NEGATIVE
when removing or renaming it. As a result, when we create a new file with the same name, the dentry is reused, even though it's no longer in a "fresh" state (various fields might have been changed).
This has already caused a bug related to the fs
field overriden for special files (see #2499, #2505).
Solution
- On file delete, mark a dentry as invalid. It will be destroyed (by
dentry_gc()
) when all external references to it are dropped. - On lookup, we should consider only valid dentries. This way, we can require the dentry to have a unique name as long as it's valid, but there can be many "ephemeral" invalid dentries with the same name.
This would also allow an open handle to a deleted file to work reasonably well.
I started coding this in #2505, but found out it would be good to refactor tmpfs/strfs first, as it does its own reference counting for dentry data that interferes with the refactoring.
Alternatives
Instead of creating new dentries, we could "wipe" dentries on reuse, but that sounds hacky and does not handle open handles to a dentry.
Instead of relaxing the "unique name" requirement, we could rename old dentries on delete? I'm not sure if that's any better, but it depends on what else we'll be using the name for.