> No, it doesn't change the refcount of the dentry. The unlink does temporarily
> increment, and then decrement, the refcount. However, there is still another
> reference that's held by the bind mount. For that reason, the dentry's inode is
> not released yet; instead, the dentry is just made unavailable to lookups.
>
>You can't actually do that, because the unlink fails with EBUSY. And even if
> you could, it would be a different dentry (b instead of a).
Thanks for the correction!. I've said wrong sorry!
> If you have a reproducer for an actual crash, please provide it. (And if you do
> indeed have an actual crash, please consider that its root cause may be
> completely unrelated to the theory that you've described...)
What I describe doesn't cause any panic. but I've traced with crash in
live below situation.:
======================================================
/**
* NOT directory bind, file bind.
*/
1. mount --bind {original file} {bind file}
// original's inode->i_count = 1, inode->i_nlink =0, and ext4_inode
becomes orphaned,
// inode->i_no which managed by ext4 is freed and become reusable.
2. rm -f {original file}
=======================================================
It's not issued remove of bind itself. after step (2)
In the view of VFS, inode seems live, but in the view of EXT4, it
becomes "orphaned" and
its inode->i_no which managed by ext4. was removed and reuse by other
created file.
In that situation, if inode->i_no is reused, via bind fil,
It seems "arbitrary access" the data of new created one with same i_no.
(write, and read...)
What I wonder is that it's intended action or not.
IMHO, should it prohibit to unlink of original to prevent above
arbitrary access?
Thanks.
--
Sincerely,
Levi
