<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
As far as I can tell the walk does not go over the pids. proc_perms_start</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
uses proc_next_recursive, which only follows the de->subdir rb tree of</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
proc_dir_entry nodes. The /proc/<pid> dirs are not in that tree, they have</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
no proc_dir_entry and are created on demand by proc_pid_lookup and</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
proc_pid_readdir, so the walk only visits the registered proc entries.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
To be sure I also measured it on a test node. I traced proc_perms_start</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
while reading ve.proc_permissions, first with about 1300 processes and then</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
with about 6300, and the work stayed about the same and did not touch any</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
pid code, so at least in my test it did not scale with the number of</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
processes.</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
That said you may well be seeing something I am not. Could you tell me what</div>
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
you looked at? I would like to compare so we can reconcile.</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Vladimir Riabchun <vladimir.riabchun@virtuozzo.com><br>
<b>Sent:</b> Monday, July 6, 2026 10:14 PM<br>
<b>To:</b> Mirian Shilakadze <mirian.shilakadze@virtuozzo.com>; Konstantin Khorenko <khorenko@virtuozzo.com>; Pavel Tikhomirov <ptikhomirov@virtuozzo.com><br>
<b>Cc:</b> devel@openvz.org <devel@openvz.org><br>
<b>Subject:</b> Re: [Devel] [PATCH vz10 0/7] per-VE ve.proc_permissions and sysfs permission fixes</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText"><br>
<br>
On 7/6/26 06:49, Mirian Shilakadze wrote:<br>
> Thanks, and fair point.<br>
> <br>
> First the bound: the walk in proc_perms_start is over the registered proc tree<br>
> (the proc_dir_entry nodes under proc_root), not the per task /proc/<pid> dirs, so<br>
> it does not grow with the number of processes. Per node it is cheap too,<br>
> proc_perms_shown returns right away when the node has no map, which is the common<br>
> case, and kmapset_lookup only runs on nodes that have one and walks just that<br>
> node's own entries, sorted so it stops early. It is not a scan of all keys.<br>
<br>
Agree, also all process entries are skipped and not checked at all, so it's fine.<br>
<br>
> <br>
> I did not expect a container to read ve.proc_permissions at all, these are host<br>
> side cgroup control files, so I expected only the host to trigger this walk and<br>
> thought the atomic hold was fine. But while digging into it I discovered that a<br>
> container can read its own ve.proc_permissions and trigger the same walk, and the<br>
> existing ve.sysfs_permissions is the same. There is already a task to hide these ve<br>
> cgroup files inside containers, <a href="https://virtuozzo.atlassian.net/browse/VSTOR-120574">
https://virtuozzo.atlassian.net/browse/VSTOR-120574</a>,<br>
> which would take care of it. I discussed this with Pavel and we agreed to note it<br>
> as a known limitation for now.<br>
> <br>
> If you think the atomic section is a problem even when only the host can reach it, I<br>
> am happy to rewrite proc_perms_start and proc_perms_next to drop and retake<br>
> proc_subdir_lock on each step, the way proc_readdir_de does, so the held section is<br>
> one node at a time.<br>
> <br>
<br>
It might be a problem - I checked what is happening in proc_perms_start and it does<br>
iterate over all /proc entries (including all CT PIDs) trying to find the first<br>
entry added in a map. This might be time-consuming for containers with many processes.<br>
<br>
-- <br>
Best regards, Riabchun Vladimir<br>
Linux Kernel Developer, Virtuozzo<br>
<br>
</div>
</span></font></div>
</body>
</html>