Skip to content
This repository has been archived by the owner on Jan 20, 2022. It is now read-only.

Filesystem code should not reuse dentries #2507

Open
pwmarcz opened this issue Jul 5, 2021 · 0 comments
Open

Filesystem code should not reuse dentries #2507

pwmarcz opened this issue Jul 5, 2021 · 0 comments
Assignees

Comments

@pwmarcz
Copy link
Contributor

pwmarcz commented Jul 5, 2021

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants