[Devel] [PATCH vz10] fs/kernfs, ve: pin the VE that mounted a kernfs instance

[Mirian Shilakadze]

On 9/28/26 8:41 PM, Konstantin Khorenko wrote:
> kernfs_get_tree() stores a bare get_exec_env() pointer in
> kernfs_super_info, and since commit 8d1abf587552 ("fs/kernfs, ve:
> hide entries from a VE without invalidating the dentry")
> kernfs_dop_revalidate() compares it against the caller's VE to decide
> between dropping the dentry and answering -ENOENT. Nothing backs that
> pointer with a reference: if the mount is pinned from outside - the
> host bind-mounted a Container's sysfs, or holds an fd inside it - the
> superblock outlives the Container, info->ve dangles, and a later
> Container whose ve_struct is allocated at the same address is mistaken
> for the creator of the instance. Its lookups then take the
> d_invalidate() path on the dead instance and detach the mounts placed
> on top of it.
> 
> Take a css reference on the VE for the lifetime of the superblock, so
> the comparison always names the VE that really created the instance.
> 
> The assignment in kernfs_set_ve_perms() is dropped instead of
> converted: it runs right after kernfs_get_tree() in the same mount
> context, so it always rewrites the field with the same value.
> 
> Fixes: 8d1abf587552 ("fs/kernfs, ve: hide entries from a VE without invalidating the dentry")
> https://virtuozzo.atlassian.net/browse/VSTOR-142552
> 
> Feature: kernfs: per-CT entries visibility and permissions configuration
> Signed-off-by: Konstantin Khorenko <khorenko at virtuozzo.com>
> ---
> kernfs_get_tree() stores a bare get_exec_env() pointer in
> kernfs_super_info, and since commit 8d1abf587552 ("fs/kernfs, ve:
> hide entries from a VE without invalidating the dentry")
> kernfs_dop_revalidate() compares it against the caller's VE to decide
> between dropping the dentry and answering -ENOENT. Nothing backs that
> pointer with a reference: if the mount is pinned from outside - the
> host bind-mounted a Container's sysfs, or holds an fd inside it - the
> superblock outlives the Container, info->ve dangles, and a later
> Container whose ve_struct is allocated at the same address is mistaken
> for the creator of the instance. Its lookups then take the
> d_invalidate() path on the dead instance and detach the mounts placed
> on top of it.
> 
> Take a css reference on the VE for the lifetime of the superblock, so
> the comparison always names the VE that really created the instance.

Nit: in the subject, "mounted" would better as "created". A later mount 
of an existing instance reuses the superblock, so only the creator's VE 
is pinned.

FWIW, the comparison was never needed for the fix. v1 returned -ENOENT 
for every hidden entry and fixed the container start on its own. The 
comparison came in v2, after Pavel suggested in review keeping the old 
invalidate inside the CT. He later wrote on the v1 cover letter that 
invalidating isn't really needed. It's the only reader of info->ve, so 
dropping it would also close this.

Reviewed-by: Mirian Shilakadze <mirian.shilakadze at virtuozzo.com>

-- 
Best regards, Mirian Shilakadze
Linux C Virtualization Developer, Virtuozzo.