Re: [PATCH 6/6] efivarfs: fix error on write to new variable leaving remnants

[Al Viro <viro@zeniv.linux.org.uk>]

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...