| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 15 Jun 2018 17:26:04 +0300 From: Ivan Zahariev <famzah@...soft.com> To: Tejun Heo <tj@...nel.org> Cc: cgroups@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: Cgroups "pids" controller does not update "pids.current" count immediately On 14.6.2018 г. 18:06 ч., Tejun Heo wrote: > On Thu, Jun 14, 2018 at 02:56:00PM +0300, Ivan Zahariev wrote: >> I posted a kernel bug about this a month ago but it did not receive >> any attention: https://bugzilla.kernel.org/show_bug.cgi?id=199713 >> >> Here is a copy of the bug report and I hope that this is the correct >> place to discuss this: > Well, for now at least, that's the expected behavior. It's not > supposed to be able to account all changes immediately (the kernel > doesn't free a lot of things immediately for performance and other > reasons). The intended use is setting up a reasonable upperbound with > some buffer space. If that's by design, it's a bit disappointing and at least the docs should mention it. The standard RLIMIT_NPROC does not suffer from such accounting discrepancies at any time. The "memory" cgroups controller also does not suffer from any discrepancies -- it accounts memory usage in real time without any lag on process start or exit. The "tasks" file list is also always up-to-date. Is it really technically not possible to make "pids.current" do accounting properly like RLIMIT_NPROC does? We were hoping to replace RLIMIT_NPROC with the "pids" controller. --Ivan
Powered by blists - more mailing lists