linux-kernel - Re: [PATCH RFC 0/2] add nproc cgroup subsystem

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 2 Mar 2015 08:54:21 -0500
From:	Tejun Heo <tj@...nel.org>
To:	Aleksa Sarai <cyphar@...har.com>
Cc:	Austin S Hemmelgarn <ahferroin7@...il.com>,
	Tim Hockin <thockin@...kin.org>,
	Frederic Weisbecker <fweisbec@...il.com>, lizefan@...wei.com,
	richard@....at, mingo@...hat.com, cgroups@...r.kernel.org,
	peterz@...radead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 0/2] add nproc cgroup subsystem

On Tue, Mar 03, 2015 at 12:31:19AM +1100, Aleksa Sarai wrote:
> > If 16-bit PID's aren't a concern anymore, then why do we still default to
> > treating it like a 16-bit signed int (the default for
> > /proc/sys/kernel/pid_max is 32768)?
> 
> I just want to emphasise that *even if* we changed to another default
> limit, the mere existence of a system-wide pid_max makes PIDs a
> resource.

We seem to fail to communicate.  The primary reason why pid promotes
itself to a global resource status is because it's globally capped way
below its backing resource's (kernel memory) limit and it is very
difficult to make it not so due to direct userland dependencies on it.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/