Re: How to shoot yourself in the foot: kill -9 postmaster

On Tue, Mar 06, 2001 at 08:19:12PM +0100, Peter Eisentraut wrote:
> Alfred Perlstein writes:
>
> > Seriously, there's some dispute on the type that 'shm_nattch' is,
> > under Solaris it's "shmatt_t" (unsigned long afaik), under FreeBSD
> > it's 'short' (i should fix this. :)).
>
> What I don't like is that my /usr/include/sys/shm.h (through other
> headers) has:
>
> typedef unsigned long int shmatt_t;
>
> /* Data structure describing a set of semaphores. */
> struct shmid_ds
> {
> struct ipc_perm shm_perm; /* operation permission struct */
> size_t shm_segsz; /* size of segment in bytes */
> __time_t shm_atime; /* time of last shmat() */
> unsigned long int __unused1;
> __time_t shm_dtime; /* time of last shmdt() */
> unsigned long int __unused2;
> __time_t shm_ctime; /* time of last change by shmctl() */
> unsigned long int __unused3;
> __pid_t shm_cpid; /* pid of creator */
> __pid_t shm_lpid; /* pid of last shmop */
> shmatt_t shm_nattch; /* number of current attaches */
> unsigned long int __unused4;
> unsigned long int __unused5;
> };
>
> whereas /usr/src/linux/include/shm.h has:
>
> struct shmid_ds {
> struct ipc_perm shm_perm; /* operation perms */
> int shm_segsz; /* size of segment (bytes) */
> __kernel_time_t shm_atime; /* last attach time */
> __kernel_time_t shm_dtime; /* last detach time */
> __kernel_time_t shm_ctime; /* last change time */
> __kernel_ipc_pid_t shm_cpid; /* pid of creator */
> __kernel_ipc_pid_t shm_lpid; /* pid of last operator */
> unsigned short shm_nattch; /* no. of current attaches */
> unsigned short shm_unused; /* compatibility */
> void *shm_unused2; /* ditto - used by DIPC */
> void *shm_unused3; /* unused */
> };
>
>
> Not only note the shm_nattch type, but also shm_segsz, and the "unused"
> fields in between. I don't know a thing about the Linux kernel sources,
> but this doesn't seem right.

On Linux, /usr/src/linux/include is meaningless for anything in userland;
it's meant only for building the kernel and kernel modules. That Red Hat
tends to expose it to user-level builds is a long-standing bug in Red
Hat's distribution, in violation of the File Hierarchy Standard as well
as explicit instructions from Linus & crew and from the maintainer of the
C library.

User-level programs see what's in /usr/include, which only has to match
what the C library wants. It's the C library's job to do any mapping
needed, and it does. The C library is maintained very, very carefully
to keep binary compatibility with all old versions. (One sometimes
encounters commercial programs that rely on a bug or undocumented/
usupported feature that disappears in a later library version.)

That is why there is no problem with version skew in the syscall
argument structures on a correctly-configured Linux system. (On a
Red Hat system it is very easy to get them out of sync, but RH fans
are used to problems.)

Nathan Myers
ncm(at)zembu(dot)com