Messages in this thread |  | | Date | Fri, 23 Aug 2002 00:11:06 +0200 | From | Andries Brouwer <> | Subject | Re: MAX_PID changes in 2.5.31 |
| |
> > On Tue, Aug 20, 2002 at 12:29:11AM +0100, Alan Cox wrote: > > > > > libc5 is very much 16bit pid throughout. > > > > Can you clarify? > > It uses the 16bit assuming syscall entry points, and has no knowledge of > the 32bit pid stuff when its needed
Ha, Alan - I am a bit slow, and you are a bit brief, but let us see.
I interpreted your "throughout" as "also outside IPC", and hence asked for clarification. For the moment, let me assume that we are just talking about SYSV IPC. (You were not thinking about uids instead of pids?)
The kernel has these days new structs shmid64_ds, msqid64_ds and old structs shmid_ds, msqid_ds. The system calls sys_shmctl(), sys_msgctl() know what struct to use by checking whether the caller has set the IPC_64 bit. (No different entry points.) The assignment is done blindly: out.shm_cpid = in->shm_cpid; hence will truncate pids.
Today glibc has structs shmid_ds and msqid_ds with int ..pid, and structs old_shmid_ds and old_msqid_ds with __ipc_pid_t msg_lspid, msg_lrpid, shm_cpid, shm_lpid. It uses the new structs and sets IPC_64 when that works. Otherwise it uses old structs, and warns in case something was truncated.
So, with a modern glibc all is fine. Here modern includes glibc 2.1.91, but not glibc 2.1.3.
Earlier glibc, and libc5, don't know about IPC_64 and hence use the old structures.
Remains the question whether that is bad. With large pid_t, the four variables msg_lspid, msg_lrpid, shm_cpid, shm_lpid will be truncated.
Who uses these? Nobody, as far as I can see from a recent collection of RPMs.
So, it would be interesting to see what I overlooked. Where are the programs that need these variables?
Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |