Summary: | fork: Time it takes to allocate random PID approach infinity as num_processes approach PID_MAX (related to: sysctl kern.randompid) | ||
---|---|---|---|
Product: | Base System | Reporter: | Marie Helene Kvello-Aune <freebsd> |
Component: | kern | Assignee: | Mateusz Guzik <mjg> |
Status: | Closed FIXED | ||
Severity: | Affects Only Me | CC: | cem, emaste, markj, mjoras |
Priority: | --- | ||
Version: | CURRENT | ||
Hardware: | Any | ||
OS: | Any |
Description
Marie Helene Kvello-Aune
2017-09-27 10:07:12 UTC
Correction: PID randomization picks a random PID as described, but if it's not available, it'll increment the attempted PID by 1 and check if it's available again. (In reply to Marie Helene Kvello-Aune from comment #0) > Prequisite: Change how PIDs are tracked and allocated. Implement a bitmap of PIDs > (I'm currently working on this) which is updated whenever anything in the PID > namespace changes (a new PID/session ID/etc is created, or a PID/session ID/etc > is considered available again). > The bitmap should be an array of 4096 uint32_t where each bit represents a PID. > A set (on) bit indicates an available PID. IIRC, there was some earlier effort to bitmap-ify PIDs. I'm not sure where that went. CC'ing Matt, who might remember if there is any work that can be reused (or if I am misremembering and the work got committed already). If not, we have some abstractions for bitmaps in the kernel already which should probably be used in place of a raw u32 array — see BITSET(9) (if fixed size is ok) or vmem(9) (which in spite of the name is actually a general purpose allocater of integers in some range). Apologies if you have already thought of this or discovered it since the 2017-09 description I responded to :-). I believe this was fixed in https://cgit.freebsd.org/src/commit/?id=34ebdceac09af3d4bc7ac7c16dd7cef2d6fc75f4 Please reopen if that's not the case. |