linux-kernel - Re: [Patch 1/1] init: Provide a kernel start parameter to increase pid

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 22 Apr 2010 10:28:52 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Greg KH <gregkh@...e.de>
Cc:	Rik van Riel <riel@...hat.com>, John Stoffel <john@...ffel.org>,
	Hedi Berriche <hedi@....com>, Mike Travis <travis@....com>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jack Steiner <steiner@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Robin Holt <holt@....com>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Patch 1/1] init: Provide a kernel start parameter to increase
 pid_max v2

> Distros don't want to take a patch that adds a new boot param that is
> not accepted upstream, otherwise they will be stuck forward porting it
> from now until, well, forever :)

So for an obscure IA64 specific problem you want the upstream kernel to
port it forward forever instead ?
> 
> As this solves a problem that people are having today, on the kernel.org
> kernel, on a known machine, and we really don't know when the "reduce
> the number of processes per cpu" work will be done, or if it really will
> solve this issue, then why can't we take it now?  If the work does solve
> the problem in the future, then we can take the command line option out,
> and everyone is happy.
> 
> Sound reasonable?

No - to start with it would be far saner for everything involved if the
4096 processor minority fixed it for the moment in their arch code by
doing something like

	if (max_pids < PIDS_PER_CPU * num_cpus) {
		max_pids = ...
		printk(something informative)
	}

in their __init marked code.

Because when Tejun's stuff is in the patch can go away, and also if it's
not sufficient then the patch above should keep it sane when they go to
32000 cpus or whatever is next.

Alan
--
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/