graphene icon indicating copy to clipboard operation
graphene copied to clipboard

Filesystem code should not reuse dentries

Open pwmarcz opened this issue 3 years ago • 0 comments

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.

pwmarcz avatar Jul 05 '21 12:07 pwmarcz