linux-kernel - PID_MAX_LIMIT limit on ia32?

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

Message-ID: <1290630157.14831.226.camel@ubuntu>
Date:	Wed, 24 Nov 2010 14:22:37 -0600
From:	Davy Durham <ddurham@...yandbeth.com>
To:	linux-kernel@...r.kernel.org
Subject: PID_MAX_LIMIT limit on ia32?

I have searched around without a definitive answer to my question.

PID_MAX_LIMIT is currently defined as:

        /*
         * A maximum of 4 million PIDs should be enough for a while.
         * [NOTE: PID/TIDs are limited to 2^29 ~= 500+ million, see
futex.h.]
         */
        #define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 :
(sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))

And PID_MAX_DEFAULT is normally 32k.

I found a comment on the net:

        “When recycling PID numbers, the kernel must manage a
        pidmap_array bitmap that denotes which are the PIDs currently
        assigned and which are the free ones. Because a page frame
        contains 32,768 bits, in 32-bit architectures the pidmap_array
        bitmap is stored in a single page. In 64-bit architectures,
        however, additional pages can be added to the bitmap when the
        kernel assigns a PID number too large for the current bitmap
        size. These pages are never released.”

Which may seem to indicate that PID_MAX_DEFAULT cannot be more than 1
memory page on 32bit archs.

Can the PID_MAX_LIMIT #define be increased safely on the ia32 arch which
would cause pidmap_array to use more than one memory page?  (say 4 pages
or so).

I thought about just compiling it and testing things, but was unsure if
I would run into problems long-term.

[Please CC me on the response as I'm not currently subscribed]

TIA,
  Davy

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