lkml.org 
[lkml]   [2000]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Linux 2.3.39 has 32bit uid. What about 32bit pid?
In <20000114090227.C15153@metastasis.f00f.org> Chris Wedgwood (cw@f00f.org) wrote:
>> I think we should change __kernel_pid_t now that we are changing
>> __kernel_uid_t.

> I agree -- I also want to take a look at the padding and size of
> other values passed to/from the kernel. I don't think we want to do
> another ABI again anytime soon.

>> a) It is easy - easier than the change to larger uid.
>> Roughly speaking the only change is in the ipc structs.
>> (The other part of the change is in /proc.)

> we can make libc5 work with in a 32-bit uid_t system, by being
> careful. no amount of care will mkae most libc5 programs work with a
> 32-bit pid_t kernel after a period of time

Only few libc5 programs are affected in fact (one with IPC usage).

>> b) The reuse of pids causes security problems.

> I don't think this is really an issue

If program is created that way it's broken already :-)

>> c) 32000 processes is not enough.

> Right _now_ it is for most people, later on, there may be cases when
> it is not. You need a big machine, 32K processes requires 256M of
> non-swappable kernel memory. Ouch.

It CAN be enough right now for everyone. But it's clear that in just few short
years it'll not be enough for lots of big servers (right now servers with
NR_TASKS=512 are useless and even NR_TASKS=1024 is often not enough; 4000
usually works... but 32000 is just 8 times more then 4000 ! and will be not
enough LONG before 32bit processors will be obsoleted).

> In reality, I don't know how well the scheduler will handle many
> processes either.

Then it should be fixed. And it'll be fixed. Epsecially since each THREAD in
linux need unique PID 32000 is not much...

>> get_pid() {
>> return ++last_pid;
>> }

> You have to be a little more careful than this. DaveM a while back
> mentioned one of the sparc platforms can fork 10,000 times a second
> (I think). This means you can wrap this in under a week...

get_pid() and sheduler should be fixed of course. But they can be fixed later.
It does not require ABI change :-)

>> suffices. Even when reuse occurs, the current get_pid() will
>> be much more efficient when a larger pid-space is available.

> OK

>> In fact, I like high uptimes, and a system in which the same pid is never
>> used again. But this means that 32 bits may not be enough. That again
>> means that I would like to see padding in places like

> Gover over 32-bits on x86 is _not_ a good idea, in fact, its a really
> bad idea.

> I think 32-bits with a lesser amount of reuse is acceptable.
> What would be nice is to see 64-bit platforms have a 64-bit pid_t,
> even if initially it does wrap and 2^32.

IMO it's way to go. We do not need more then 2000000000 processes even on
64bit platforms but who knows what will be done in next 20 years+ ?





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.234 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site