[Devel] [PATCH vz10 0/7] per-VE ve.proc_permissions and sysfs permission fixes

[Vladimir Riabchun]

On 7/6/26 06:49, Mirian Shilakadze wrote:
> Thanks, and fair point.
> 
> First the bound: the walk in proc_perms_start is over the registered proc tree
> (the proc_dir_entry nodes under proc_root), not the per task /proc/<pid> dirs, so
> it does not grow with the number of processes. Per node it is cheap too,
> proc_perms_shown returns right away when the node has no map, which is the common
> case, and kmapset_lookup only runs on nodes that have one and walks just that
> node's own entries, sorted so it stops early. It is not a scan of all keys.

Agree, also all process entries are skipped and not checked at all, so it's fine.

> 
> I did not expect a container to read ve.proc_permissions at all, these are host
> side cgroup control files, so I expected only the host to trigger this walk and
> thought the atomic hold was fine. But while digging into it I discovered that a
> container can read its own ve.proc_permissions and trigger the same walk, and the
> existing ve.sysfs_permissions is the same. There is already a task to hide these ve
> cgroup files inside containers, https://virtuozzo.atlassian.net/browse/VSTOR-120574,
> which would take care of it. I discussed this with Pavel and we agreed to note it
> as a known limitation for now.
> 
> If you think the atomic section is a problem even when only the host can reach it, I
> am happy to rewrite proc_perms_start and proc_perms_next to drop and retake
> proc_subdir_lock on each step, the way proc_readdir_de does, so the held section is
> one node at a time.
> 

It might be a problem - I checked what is happening in proc_perms_start and it does
iterate over all /proc entries (including all CT PIDs) trying to find the first
entry added in a map. This might be time-consuming for containers with many processes.

-- 
Best regards, Riabchun Vladimir
Linux Kernel Developer, Virtuozzo