As far as I can tell the walk does not go over the pids. proc_perms_start uses proc_next_recursive, which only follows the de->subdir rb tree of proc_dir_entry nodes. The /proc/<pid> dirs are not in that tree, they have no proc_dir_entry and are created on demand by proc_pid_lookup and proc_pid_readdir, so the walk only visits the registered proc entries.
To be sure I also measured it on a test node. I traced proc_perms_start while reading ve.proc_permissions, first with about 1300 processes and then with about 6300, and the work stayed about the same and did not touch any pid code, so at least in my test it did not scale with the number of processes. That said you may well be seeing something I am not. Could you tell me what you looked at? I would like to compare so we can reconcile. ________________________________ From: Vladimir Riabchun <[email protected]> Sent: Monday, July 6, 2026 10:14 PM To: Mirian Shilakadze <[email protected]>; Konstantin Khorenko <[email protected]>; Pavel Tikhomirov <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [Devel] [PATCH vz10 0/7] per-VE ve.proc_permissions and sysfs permission fixes 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
_______________________________________________ Devel mailing list [email protected] https://lists.openvz.org/mailman/listinfo/devel
