On Mon, Dec 23, 2024 at 05:56:04PM -0500, James Bottomley wrote: > > Let me look into that area... > > I thought about this some more. I could see a twisted container use > case where something like this might happen (expose some but not all > efi variables to the container). > > So, help me understand the subtleties here. If it's the target of a > bind mount, that's all OK, because you are allowed to delete the > target. If something is bind mounted on to an efivarfs object, the > is_local_mountpoint() check in vfs_unlink would usually trip and > prevent deletion (so the subtree doesn't become unreachable). If I > were to duplicate that, I think the best way would be simply to do a > d_put() in the file->release function and implement drop_nlink() in > d_prune (since last put will always call __dentry_kill)? Refcounting is not an issue. At all. Inability to find and evict the mount, OTOH, very much is. And after your blind d_delete() that's precisely what will happen. You are steadily moving towards more and more convoluted crap, in places where it really does not belong. If anything, simple_recursive_removal() should be used for that, instead of trying to open-code bizarre subsets of its functionality...
