On 2/7/18 3:30 PM, Chet Ramey wrote:
>> Unfortunately, the proposed patch does not fix the case for 32 bit
>> architectures.
>
> That's interesting. It seems to me that the kernel should reject attempts
> to set the maximum number of processes larger than 2**(sizeof (pid_t)).
I looked at this on a 32-bit debian system and discovered that setting the
limit to anything above 2**32 - 1 will basically give you `unlimited'.
Setting it to anything below that but above 2**31 - 1 will give you a value
that `ulimit' will display, but sysconf() will return as negative, which
the code handles fine. It's when you have values between 2**30 and 2**31-1
where there's a problem in the code that calculates the max needed table
size.
However, when you correct that...
>> I think the proper fix may be re-enable the js.c_childmax capping. What
>> do you think?
>
> That's the wrong place. If your original patch identifies the issue
> correctly, we need to bound the size of bgpids.storage to something a
> pid_t (aliased to ps_index_t) variable can address.
>
> So instead of using js.c_childmax directly, we compute the maximum
> table size using js.c_childmax unless it exceeds TYPE_MAXIMUM(pid_t).
This is true, but doing that will probably result in the kernel killing
you when the code goes to malloc some 32 gig of memory, especially on a
32-bit system. So it seems appropriate to limit the table size to some
reasonable value, but the question is what constitutes `reasonable'. We
could start with some value like 32768 and see what happens.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
