Re: struct ipc_perm and size of seq member

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

On Fri, 22 Sep 2000, Geoff Keating wrote:
> > Date: Fri, 22 Sep 2000 14:18:37 +0200
> > From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> >
> > Hi,
> >
> > I'm finally able to run 2.4.0-t8 on my B&W G3 and can now track down the
> > remaining problems with glibc-2.1.9x. With 2.4 I still have an IPC
> > problem, that maybe related to different notion of the size of seq. 2.4
> > on PPC defines it as 'unsigned long', but glibc-2.1.94 uses it as
> > 'unsigned short'. Besides the missing padding in powerpc/bits/ipc.h, why
> > does glibc use a 16bit type here, while the kernel uses 32bit? Is this
> > required for userspace compatibility?
>
> This structure used to be
>
> struct ipc_perm
> {
> 	__kernel_key_t	key;
> 	__kernel_uid_t	uid;
> 	__kernel_gid_t	gid;
> 	__kernel_uid_t	cuid;
> 	__kernel_gid_t	cgid;
> 	__kernel_mode_t	mode;
> 	unsigned short	seq;
> };
>
> so the kernel change breaks backward compatibility, and the glibc
> problem you're seeing is just one aspect of this.

Hmm, I thought backwards compatibility is maintained with versioning and 
ipc_priv.h containing:

struct __old_ipc_perm
{
  __key_t __key;                        /* Key.  */
  unsigned int uid;                     /* Owner's user ID.  */
  unsigned int gid;                     /* Owner's group ID.  */
  unsigned int cuid;                    /* Creator's user ID.  */
  unsigned int cgid;                    /* Creator's group ID.  */
  unsigned int mode;                    /* Read/write permission.  */
  unsigned short int __seq;             /* Sequence number.  */
};

?
I don't want to change __old_ipc_perm, I want to know if changing seq to an 
'unsigned long' (which is what 2.4 has on all platforms) in ipc_perm is safe 
and I can't think of a reason why this wouldn't work with proper versioning. 
On the other side, even though 2.4 now only handles a 'unsigned long' seq in 
kern_ipc_perm, all the platforms still cripple seq to 'unsigned short' in 
userspace. So, is there a reason for that? If the other platforms bumped 
uid/gid to 32bit, why didn't they bump seq to 32bit?

If it is unsafe to bump seq to 32bit in userspace, I'll just add the correct 
padding before seq to ipc_perm in powerpc/bits/ipc.h and I'll do the 
corresponding change in the kernel headers as well.

Franz.