Messages in this thread | | | Date | Wed, 18 Feb 2015 12:28:51 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH 1/1 v2] kernel/fork.c: avoid division by zero |
| |
On Wed, 18 Feb 2015 20:47:48 +0100 Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> Hello Andrew, > > thank you for your comments. Unfortunately there is no solution with > 32-bit calculus.
How would something along the lines of
if (PAGE_SIZE < THREAD_SIZE) ... else ...
look?
> Please, see my answers below. > > As fork_init is only called once there should be not performance issue > in using 64-bit calculus.
Sure, it's not a big issue. But please do address the code comments and no "temp"! > I think that my patch did not cover all problems connected to max_threads. > > I just had a look at the memory hotplugging code. > Shouldn't max_threads and init_task.signal->rlim[RLIMIT_NPROC] be > recalculated after adding or removing memory? > This could be done in a hotplug callback.
That sounds right. We've fixed some of these inaccuracies but there will be many more remaining. Searching for things like "mempages" and "nr_free_buffer_pages" shows them up. mem hotplug is an ongoing thing ;)
> max_threads can be set by writing to /proc/sys/kernel/threads-max. > Shouldn't the value be checked by the same routine
Probably.
> and shouldn't > init_task.signal->rlim[RLIMIT_NPROC] be updated?
Harder. By this time the system has all these processes which have inherited their rlimits from init.
| |