Re: PIDs limited to 15 significant bits
On Sun, Oct 01, 2000 at 10:48:41PM -0400, Albert D. Cahalan wrote: > I see you don't remember the original post. It argued in > favor of a large PID space "because the output of ps wouldn't > look nice otherwise"!!! (the poster wanted output sorted by > start time without using --sort=start to ask for it) Why not use 32-bit PIDs in the kernel, but make the number at which they wrap a configurable option? That way, most users can keep the numbers small for ease of management, and people who really need 100,000 processes can have them. -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Sun, Oct 01, 2000 at 10:48:41PM -0400, Albert D. Cahalan wrote: I see you don't remember the original post. It argued in favor of a large PID space "because the output of ps wouldn't look nice otherwise"!!! (the poster wanted output sorted by start time without using --sort=start to ask for it) Why not use 32-bit PIDs in the kernel, but make the number at which they wrap a configurable option? That way, most users can keep the numbers small for ease of management, and people who really need 100,000 processes can have them. -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
David Weinehall writes: > On Sun, Oct 01, 2000 at 01:10:50AM -0400, Albert D. Cahalan wrote: >> Andries Brouwer writes: >>> On Fri, Sep 29, 2000 at 03:57:10PM -0400, Albert D. Cahalan wrote: What do you think of "ps -efj" on a standard 80x24 screen? >>> >>> I never give such commands, but just tried: >>> >>> aeb 1198761 426 236 0 23:32 tty1 00:00:00 xterm >>> aeb 119877 119876 119877 119877 0 23:32 pts/9 00:00:00 -bash >>> aeb 119884 119877 119884 119877 0 23:33 pts/9 00:00:00 ps -efj >>> >>> as you see, the ps program here fails to align the columns, >>> but otherwise all is well. >> >> How are you going to like the output after some more uptime? >> The record is around 1200 days I think. With a faster machine >> doing a lot of work, you could just about lose the CMD column. > > So, let's see if I get this straight: you want us to limit PID's to > 15 bits rather than 31 bits because the output of ps wouldn't look nice > otherwise?! PLEASE... This reason is as good as any. Remember, nobody has yet actually run out of PID space. When that happens, then there is a legitimate need to increase PID space. I see you don't remember the original post. It argued in favor of a large PID space "because the output of ps wouldn't look nice otherwise"!!! (the poster wanted output sorted by start time without using --sort=start to ask for it) > Should we stick to 16 bit UID's because a simple > "ls -nal" might look ugly?! Oh, and du/df will probably start to look > ugly when having those 2 TB sized LV's. Oh my... Better return to non > LFS. If one really NEEDS large numbers, then the limit must go. I really don't want to see "ls -nal" spit out 10-digit numbers unless I really have a billion users. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Sun, Oct 01, 2000 at 01:10:50AM -0400, Albert D. Cahalan wrote: > Andries Brouwer writes: > > On Fri, Sep 29, 2000 at 03:57:10PM -0400, Albert D. Cahalan wrote: > > >>> My machines regularly see 6- or 7-digit PIDs. > > > >> Oh, the horror! > >> > >> Consider, do you like to type "kill 1234567890" more than > >> a simple "kill 1234"? > > > > Hmm. I double click on the ps output and single click to paste. > > The number of digits does not play a role. > > I have a real VT510 terminal w/o a mouse, but OK... > I still don't like to read and compare such numbers. Ever heard of grep?! Pipe the ps output through grep and then to kill. Still, it's cool you're doing real stuff with a real terminal. If more people did, they'd realise that their source-code shouldn't have 150 chars wide lines et al. > >> What do you think of "ps -efj" on a standard 80x24 screen? > > > > I never give such commands, but just tried: > > > > aeb 1198761 426 236 0 23:32 tty1 00:00:00 xterm > > aeb 119877 119876 119877 119877 0 23:32 pts/9 00:00:00 -bash > > aeb 119884 119877 119884 119877 0 23:33 pts/9 00:00:00 ps -efj > > > > as you see, the ps program here fails to align the columns, > > but otherwise all is well. > > How are you going to like the output after some more uptime? > The record is around 1200 days I think. With a faster machine > doing a lot of work, you could just about lose the CMD column. So, let's see if I get this straight: you want us to limit PID's to 15 bits rather than 31 bits because the output of ps wouldn't look nice otherwise?! PLEASE... Should we stick to 16 bit UID's because a simple "ls -nal" might look ugly?! Oh, and du/df will probably start to look ugly when having those 2 TB sized LV's. Oh my... Better return to non LFS. > >>> [The patch is available. There are a few security advantages. > >> > >> There should not be any significant security advantages. > >> One can easily wrap/predict in a 31-bit space. > > > > There are a few weaknesses that can be exploited using a wraparound. > > With 100 processes/sec that takes 497 days with a 32-bit pid > > and 5 minutes with a 16-bit pid. > > David Miller once posted a forks/second rate for SPARC that was > many thousands... these days, once might wrap once per second. I agree with this one, though. Hoping for security just by having more PID's is a bit naive. It might give some increased security, but having some form of random pid-calculation will give extra overhead on fork anyway, right?! Is it really worth it? When you have a 31-bit PID space and people start to manufacture programs to exploit the wraparound, you'd probably notice. > So the 31-bit space won't help you much. If you really want > this kind of security, you should make me an offer for my old PC. > I'll even pop out the OverDrive, getting you down to 25 MHz. Uhmmm. Of course, DOS attacks versus such a machine isn't very complicated anyway... /David _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
Andries Brouwer writes: > On Fri, Sep 29, 2000 at 03:57:10PM -0400, Albert D. Cahalan wrote: >>> My machines regularly see 6- or 7-digit PIDs. > >> Oh, the horror! >> >> Consider, do you like to type "kill 1234567890" more than >> a simple "kill 1234"? > > Hmm. I double click on the ps output and single click to paste. > The number of digits does not play a role. I have a real VT510 terminal w/o a mouse, but OK... I still don't like to read and compare such numbers. >> What do you think of "ps -efj" on a standard 80x24 screen? > > I never give such commands, but just tried: > > aeb 1198761 426 236 0 23:32 tty1 00:00:00 xterm > aeb 119877 119876 119877 119877 0 23:32 pts/9 00:00:00 -bash > aeb 119884 119877 119884 119877 0 23:33 pts/9 00:00:00 ps -efj > > as you see, the ps program here fails to align the columns, > but otherwise all is well. How are you going to like the output after some more uptime? The record is around 1200 days I think. With a faster machine doing a lot of work, you could just about lose the CMD column. >>> [The patch is available. There are a few security advantages. >> >> There should not be any significant security advantages. >> One can easily wrap/predict in a 31-bit space. > > There are a few weaknesses that can be exploited using a wraparound. > With 100 processes/sec that takes 497 days with a 32-bit pid > and 5 minutes with a 16-bit pid. David Miller once posted a forks/second rate for SPARC that was many thousands... these days, once might wrap once per second. So the 31-bit space won't help you much. If you really want this kind of security, you should make me an offer for my old PC. I'll even pop out the OverDrive, getting you down to 25 MHz. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
Andries Brouwer writes: On Fri, Sep 29, 2000 at 03:57:10PM -0400, Albert D. Cahalan wrote: My machines regularly see 6- or 7-digit PIDs. Oh, the horror! Consider, do you like to type "kill 1234567890" more than a simple "kill 1234"? Hmm. I double click on the ps output and single click to paste. The number of digits does not play a role. I have a real VT510 terminal w/o a mouse, but OK... I still don't like to read and compare such numbers. What do you think of "ps -efj" on a standard 80x24 screen? I never give such commands, but just tried: aeb 1198761 426 236 0 23:32 tty1 00:00:00 xterm aeb 119877 119876 119877 119877 0 23:32 pts/9 00:00:00 -bash aeb 119884 119877 119884 119877 0 23:33 pts/9 00:00:00 ps -efj as you see, the ps program here fails to align the columns, but otherwise all is well. How are you going to like the output after some more uptime? The record is around 1200 days I think. With a faster machine doing a lot of work, you could just about lose the CMD column. [The patch is available. There are a few security advantages. There should not be any significant security advantages. One can easily wrap/predict in a 31-bit space. There are a few weaknesses that can be exploited using a wraparound. With 100 processes/sec that takes 497 days with a 32-bit pid and 5 minutes with a 16-bit pid. David Miller once posted a forks/second rate for SPARC that was many thousands... these days, once might wrap once per second. So the 31-bit space won't help you much. If you really want this kind of security, you should make me an offer for my old PC. I'll even pop out the OverDrive, getting you down to 25 MHz. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Sun, Oct 01, 2000 at 01:10:50AM -0400, Albert D. Cahalan wrote: Andries Brouwer writes: On Fri, Sep 29, 2000 at 03:57:10PM -0400, Albert D. Cahalan wrote: My machines regularly see 6- or 7-digit PIDs. Oh, the horror! Consider, do you like to type "kill 1234567890" more than a simple "kill 1234"? Hmm. I double click on the ps output and single click to paste. The number of digits does not play a role. I have a real VT510 terminal w/o a mouse, but OK... I still don't like to read and compare such numbers. Ever heard of grep?! Pipe the ps output through grep and then to kill. Still, it's cool you're doing real stuff with a real terminal. If more people did, they'd realise that their source-code shouldn't have 150 chars wide lines et al. What do you think of "ps -efj" on a standard 80x24 screen? I never give such commands, but just tried: aeb 1198761 426 236 0 23:32 tty1 00:00:00 xterm aeb 119877 119876 119877 119877 0 23:32 pts/9 00:00:00 -bash aeb 119884 119877 119884 119877 0 23:33 pts/9 00:00:00 ps -efj as you see, the ps program here fails to align the columns, but otherwise all is well. How are you going to like the output after some more uptime? The record is around 1200 days I think. With a faster machine doing a lot of work, you could just about lose the CMD column. So, let's see if I get this straight: you want us to limit PID's to 15 bits rather than 31 bits because the output of ps wouldn't look nice otherwise?! PLEASE... Should we stick to 16 bit UID's because a simple "ls -nal" might look ugly?! Oh, and du/df will probably start to look ugly when having those 2 TB sized LV's. Oh my... Better return to non LFS. [The patch is available. There are a few security advantages. There should not be any significant security advantages. One can easily wrap/predict in a 31-bit space. There are a few weaknesses that can be exploited using a wraparound. With 100 processes/sec that takes 497 days with a 32-bit pid and 5 minutes with a 16-bit pid. David Miller once posted a forks/second rate for SPARC that was many thousands... these days, once might wrap once per second. I agree with this one, though. Hoping for security just by having more PID's is a bit naive. It might give some increased security, but having some form of random pid-calculation will give extra overhead on fork anyway, right?! Is it really worth it? When you have a 31-bit PID space and people start to manufacture programs to exploit the wraparound, you'd probably notice. So the 31-bit space won't help you much. If you really want this kind of security, you should make me an offer for my old PC. I'll even pop out the OverDrive, getting you down to 25 MHz. Uhmmm. Of course, DOS attacks versus such a machine isn't very complicated anyway... /David _ _ // David Weinehall [EMAIL PROTECTED] / Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \ http://www.acc.umu.se/~tao// Full colour fire / - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Sat, Sep 30, 2000 at 08:35:28AM -0500, Jeff Epler wrote: > 31- or 32-bit PIDs might be a convenience, but they don't furnish > security against wraparound attacks, they just make them take > a little longer to exploit. Precisely. It takes a factor 6 longer. Maybe you think security is a yes/no matter, but then no secure systems exist. In real life it is a matter of less or more secure. > vulnerabilities due to PID wrap should just plain get fixed Yes. Just like all vulnerabilities. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Fri, Sep 29, 2000 at 11:44:42PM +0200, Andries Brouwer wrote: > There are a few weaknesses that can be exploited using a wraparound. > With 100 processes/sec that takes 497 days with a 32-bit pid > and 5 minutes with a 16-bit pid. Surely the estimate of 100 forks/sec is low. I get 83 forks/sec on a 486-75 and a Python program, just as an estimate. Besides, vulnerabilities due to PID wrap should just plain get fixed, if only because ports to a "lesser" unix might be made. 31- or 32-bit PIDs might be a convenience, but they don't furnish security against wraparound attacks, they just make them take a little longer to exploit. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Fri, Sep 29, 2000 at 11:44:42PM +0200, Andries Brouwer wrote: There are a few weaknesses that can be exploited using a wraparound. With 100 processes/sec that takes 497 days with a 32-bit pid and 5 minutes with a 16-bit pid. Surely the estimate of 100 forks/sec is low. I get 83 forks/sec on a 486-75 and a Python program, just as an estimate. Besides, vulnerabilities due to PID wrap should just plain get fixed, if only because ports to a "lesser" unix might be made. 31- or 32-bit PIDs might be a convenience, but they don't furnish security against wraparound attacks, they just make them take a little longer to exploit. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Sat, Sep 30, 2000 at 08:35:28AM -0500, Jeff Epler wrote: 31- or 32-bit PIDs might be a convenience, but they don't furnish security against wraparound attacks, they just make them take a little longer to exploit. Precisely. It takes a factor 6 longer. Maybe you think security is a yes/no matter, but then no secure systems exist. In real life it is a matter of less or more secure. vulnerabilities due to PID wrap should just plain get fixed Yes. Just like all vulnerabilities. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Fri, Sep 29, 2000 at 06:51:22PM -0400, Chris Wing wrote:
> > (ii) There is also a rather obscure place in SYSV IPC where a 16-bit pid_t
> > is used for the fields msg_lspid and msg_lrpid of the (obsolete)
> > struct msqid_ds and the fields shm_cpid and shm_lpid of the (obsolete)
> > struct shmid_ds. Nothing compiled today uses this, and almost nothing
> > uses it at all, but this nevertheless means that one needs an option
> > CONFIG_15BIT_PID (default=N) for backward binary compatibility.
> Just to clarify, the old struct msqid_ds et. al are still used by all
> Linux software before glibc 2.2. As of glibc 2.2, there is a new
> user-level ABI for the SysV IPC functions {msg,sem,shm}*(), which provides
> 32-bit pids and 32-bit uids. All software using SysV IPC will need to be
> recompiled under glibc 2.2 to take advantage of the new structures.
>
> I don't think that returning incorrect pids to older programs here is
> going to be any worse than returning incorrect uids or gids. But, we
> should fix the kernel to return (-1) in 16 bits, or something like that,
> in case of a pid overflow, to programs using the older structures.
Perhaps. That doesnt help since old programs do not know that they
have to test for some special value.
I think the appropriate thing is to return EOVERFLOW. That is defined by:
EOVERFLOWValue too large to be stored in data type.
precisely what we want here.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
Andries:
Just to clarify, the old struct msqid_ds et. al are still used by all
Linux software before glibc 2.2. As of glibc 2.2, there is a new
user-level ABI for the SysV IPC functions {msg,sem,shm}*(), which provides
32-bit pids and 32-bit uids. All software using SysV IPC will need to be
recompiled under glibc 2.2 to take advantage of the new structures.
I don't think that returning incorrect pids to older programs here is
going to be any worse than returning incorrect uids or gids. But, we
should fix the kernel to return (-1) in 16 bits, or something like that,
in case of a pid overflow, to programs using the older structures.
-Chris Wing
[EMAIL PROTECTED]
> (ii) There is also a rather obscure place in SYSV IPC where a 16-bit pid_t
> is used for the fields msg_lspid and msg_lrpid of the (obsolete)
> struct msqid_ds and the fields shm_cpid and shm_lpid of the (obsolete)
> struct shmid_ds. Nothing compiled today uses this, and almost nothing
> uses it at all, but this nevertheless means that one needs an option
> CONFIG_15BIT_PID (default=N) for backward binary compatibility.
>
> Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Fri, Sep 29, 2000 at 03:57:10PM -0400, Albert D. Cahalan wrote: > > The code is old. > > There is very little reason for it, and we could change today. > > My machines regularly see 6- or 7-digit PIDs. > Oh, the horror! > > Consider, do you like to type "kill 1234567890" more than > a simple "kill 1234"? Hmm. I double click on the ps output and single click to paste. The number of digits does not play a role. > What do you think of "ps -efj" on a standard 80x24 screen? I never give such commands, but just tried: aeb 1198761 426 236 0 23:32 tty1 00:00:00 xterm aeb 119877 119876 119877 119877 0 23:32 pts/9 00:00:00 -bash aeb 119884 119877 119884 119877 0 23:33 pts/9 00:00:00 ps -efj as you see, the ps program here fails to align the columns, but otherwise all is well. > > [The patch is available. There are a few security advantages. > > There should not be any significant security advantages. > One can easily wrap/predict in a 31-bit space. There are a few weaknesses that can be exploited using a wraparound. With 100 processes/sec that takes 497 days with a 32-bit pid and 5 minutes with a 16-bit pid. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
Andries Brouwer writes: > On Wed, Sep 27, 2000 at 02:32:17PM +0100, Bernhard Bender wrote: > The code is old. > There is very little reason for it, and we could change today. Some userspace software uses "short" for PIDs. Bash did this. > In fact I think I once submitted the corresponding patch. > My machines regularly see 6- or 7-digit PIDs. Oh, the horror! Consider, do you like to type "kill 1234567890" more than a simple "kill 1234"? What do you think of "ps -efj" on a standard 80x24 screen? The limit should be by default, because this keeps the numbers conveniently small. If you really need more processes than that, going to 65000 or 9 might be reasonable. > (ii) There is also a rather obscure place in SYSV IPC where a 16-bit pid_t > is used for the fields msg_lspid and msg_lrpid of the (obsolete) > struct msqid_ds and the fields shm_cpid and shm_lpid of the (obsolete) Gee, another reason to keep the limit low. > [The patch is available. There are a few security advantages. There should not be any significant security advantages. One can easily wrap/predict in a 31-bit space. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
Andries Brouwer writes: On Wed, Sep 27, 2000 at 02:32:17PM +0100, Bernhard Bender wrote: The code is old. There is very little reason for it, and we could change today. Some userspace software uses "short" for PIDs. Bash did this. In fact I think I once submitted the corresponding patch. My machines regularly see 6- or 7-digit PIDs. Oh, the horror! Consider, do you like to type "kill 1234567890" more than a simple "kill 1234"? What do you think of "ps -efj" on a standard 80x24 screen? The limit should be by default, because this keeps the numbers conveniently small. If you really need more processes than that, going to 65000 or 9 might be reasonable. (ii) There is also a rather obscure place in SYSV IPC where a 16-bit pid_t is used for the fields msg_lspid and msg_lrpid of the (obsolete) struct msqid_ds and the fields shm_cpid and shm_lpid of the (obsolete) Gee, another reason to keep the limit low. [The patch is available. There are a few security advantages. There should not be any significant security advantages. One can easily wrap/predict in a 31-bit space. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Fri, Sep 29, 2000 at 03:57:10PM -0400, Albert D. Cahalan wrote: The code is old. There is very little reason for it, and we could change today. My machines regularly see 6- or 7-digit PIDs. Oh, the horror! Consider, do you like to type "kill 1234567890" more than a simple "kill 1234"? Hmm. I double click on the ps output and single click to paste. The number of digits does not play a role. What do you think of "ps -efj" on a standard 80x24 screen? I never give such commands, but just tried: aeb 1198761 426 236 0 23:32 tty1 00:00:00 xterm aeb 119877 119876 119877 119877 0 23:32 pts/9 00:00:00 -bash aeb 119884 119877 119884 119877 0 23:33 pts/9 00:00:00 ps -efj as you see, the ps program here fails to align the columns, but otherwise all is well. [The patch is available. There are a few security advantages. There should not be any significant security advantages. One can easily wrap/predict in a 31-bit space. There are a few weaknesses that can be exploited using a wraparound. With 100 processes/sec that takes 497 days with a 32-bit pid and 5 minutes with a 16-bit pid. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
Andries:
Just to clarify, the old struct msqid_ds et. al are still used by all
Linux software before glibc 2.2. As of glibc 2.2, there is a new
user-level ABI for the SysV IPC functions {msg,sem,shm}*(), which provides
32-bit pids and 32-bit uids. All software using SysV IPC will need to be
recompiled under glibc 2.2 to take advantage of the new structures.
I don't think that returning incorrect pids to older programs here is
going to be any worse than returning incorrect uids or gids. But, we
should fix the kernel to return (-1) in 16 bits, or something like that,
in case of a pid overflow, to programs using the older structures.
-Chris Wing
[EMAIL PROTECTED]
(ii) There is also a rather obscure place in SYSV IPC where a 16-bit pid_t
is used for the fields msg_lspid and msg_lrpid of the (obsolete)
struct msqid_ds and the fields shm_cpid and shm_lpid of the (obsolete)
struct shmid_ds. Nothing compiled today uses this, and almost nothing
uses it at all, but this nevertheless means that one needs an option
CONFIG_15BIT_PID (default=N) for backward binary compatibility.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Fri, Sep 29, 2000 at 06:51:22PM -0400, Chris Wing wrote:
(ii) There is also a rather obscure place in SYSV IPC where a 16-bit pid_t
is used for the fields msg_lspid and msg_lrpid of the (obsolete)
struct msqid_ds and the fields shm_cpid and shm_lpid of the (obsolete)
struct shmid_ds. Nothing compiled today uses this, and almost nothing
uses it at all, but this nevertheless means that one needs an option
CONFIG_15BIT_PID (default=N) for backward binary compatibility.
Just to clarify, the old struct msqid_ds et. al are still used by all
Linux software before glibc 2.2. As of glibc 2.2, there is a new
user-level ABI for the SysV IPC functions {msg,sem,shm}*(), which provides
32-bit pids and 32-bit uids. All software using SysV IPC will need to be
recompiled under glibc 2.2 to take advantage of the new structures.
I don't think that returning incorrect pids to older programs here is
going to be any worse than returning incorrect uids or gids. But, we
should fix the kernel to return (-1) in 16 bits, or something like that,
in case of a pid overflow, to programs using the older structures.
Perhaps. That doesnt help since old programs do not know that they
have to test for some special value.
I think the appropriate thing is to return EOVERFLOW. That is defined by:
EOVERFLOWValue too large to be stored in data type.
precisely what we want here.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Fri, Sep 29, 2000 at 09:17:11AM +1200, Chris Wedgwood wrote: > [The patch is available. There are a few security advantages. > Also, it makes a fork a just measurable fraction of a percent > faster.] > > How does it make it faster? The only thing I can see is it might > remove the heuristic we have for when PIDs wrap -- which technically > we still need. Until the first wraparound has happened we need not check whether the pid is in use already as pid or pgid or sid. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Wed, Sep 27, 2000 at 02:32:17PM +0100, Bernhard Bender wrote: > looking at my process list after a week or so of uptime I discoverd that PIDs > seem to wrap around at 32767 (aka. 2^15 - 1). Yes. > I find this "feature" annoying, since I like to view my process list sorted > by PID, which gives a nice overview about recently started processes vs. > age-old daemons. > > So, I would like to ask if someone could please explain the reason for this. > If there is no compelling reason I would like to propose to remove this > limit. I recall this was not present in 2.2.x You recall incorrectly. The code is old. There is very little reason for it, and we could change today. In fact I think I once submitted the corresponding patch. My machines regularly see 6- or 7-digit PIDs. There are two very minor points: (i) If you are in the habit of tar'ing up /proc, and moreover the tar you use considers files with the same device and inode to be identical, then your tarfiles may become smaller after the patch -#define fake_ino(pid,ino) (((pid)<<16)|(ino)) +#define fake_ino(pid,ino) (((1)<<16)|(ino)) in fs/proc/base.c. (ii) There is also a rather obscure place in SYSV IPC where a 16-bit pid_t is used for the fields msg_lspid and msg_lrpid of the (obsolete) struct msqid_ds and the fields shm_cpid and shm_lpid of the (obsolete) struct shmid_ds. Nothing compiled today uses this, and almost nothing uses it at all, but this nevertheless means that one needs an option CONFIG_15BIT_PID (default=N) for backward binary compatibility. Andries [The patch is available. There are a few security advantages. Also, it makes a fork a just measurable fraction of a percent faster.] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Wed, Sep 27, 2000 at 02:32:17PM +0100, Bernhard Bender wrote: looking at my process list after a week or so of uptime I discoverd that PIDs seem to wrap around at 32767 (aka. 2^15 - 1). Yes. I find this "feature" annoying, since I like to view my process list sorted by PID, which gives a nice overview about recently started processes vs. age-old daemons. So, I would like to ask if someone could please explain the reason for this. If there is no compelling reason I would like to propose to remove this limit. I recall this was not present in 2.2.x You recall incorrectly. The code is old. There is very little reason for it, and we could change today. In fact I think I once submitted the corresponding patch. My machines regularly see 6- or 7-digit PIDs. There are two very minor points: (i) If you are in the habit of tar'ing up /proc, and moreover the tar you use considers files with the same device and inode to be identical, then your tarfiles may become smaller after the patch -#define fake_ino(pid,ino) (((pid)16)|(ino)) +#define fake_ino(pid,ino) (((1)16)|(ino)) in fs/proc/base.c. (ii) There is also a rather obscure place in SYSV IPC where a 16-bit pid_t is used for the fields msg_lspid and msg_lrpid of the (obsolete) struct msqid_ds and the fields shm_cpid and shm_lpid of the (obsolete) struct shmid_ds. Nothing compiled today uses this, and almost nothing uses it at all, but this nevertheless means that one needs an option CONFIG_15BIT_PID (default=N) for backward binary compatibility. Andries [The patch is available. There are a few security advantages. Also, it makes a fork a just measurable fraction of a percent faster.] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIDs limited to 15 significant bits
On Fri, Sep 29, 2000 at 09:17:11AM +1200, Chris Wedgwood wrote: [The patch is available. There are a few security advantages. Also, it makes a fork a just measurable fraction of a percent faster.] How does it make it faster? The only thing I can see is it might remove the heuristic we have for when PIDs wrap -- which technically we still need. Until the first wraparound has happened we need not check whether the pid is in use already as pid or pgid or sid. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PIDs limited to 15 significant bits
Hi, looking at my process list after a week or so of uptime I discoverd that PIDs seem to wrap arround at 32767 (aka. 2^15 - 1). I found the relevant code doing this in kernel/fork.c:get_pid() where a mask (0x8000) is used to limit the PID of a new process to 15 significant bits. (I am running 2.4.0-test6 currently) I find this "feature" annoying, since I like to view my process list sorted by PID, which gives a nice overview about recently started processes vs. age-old daemons. So, I would like to ask if someone could please explain the reason for this. If there is no compelling reason I would like to propose to remove this limit. I recall this was not present in 2.2.x After all, UIDs have just been changes to 32bits, why limit PIDs? thanks Bernhard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PIDs limited to 15 significant bits
Hi, looking at my process list after a week or so of uptime I discoverd that PIDs seem to wrap arround at 32767 (aka. 2^15 - 1). I found the relevant code doing this in kernel/fork.c:get_pid() where a mask (0x8000) is used to limit the PID of a new process to 15 significant bits. (I am running 2.4.0-test6 currently) I find this "feature" annoying, since I like to view my process list sorted by PID, which gives a nice overview about recently started processes vs. age-old daemons. So, I would like to ask if someone could please explain the reason for this. If there is no compelling reason I would like to propose to remove this limit. I recall this was not present in 2.2.x After all, UIDs have just been changes to 32bits, why limit PIDs? thanks Bernhard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
