[parisc-linux] what's up with the ipc syscalls?

[parisc-linux] what's up with the ipc syscalls?

[Randolph Chung]

in our syscall table, semctl, msgctl and shmctl are marked as "broken".
Does anybody know what's up with that?

i did a simple hack, which is to replace

        return sys_msgctl (msqid, cmd & ~IPC_64, buf);

with 

        return sys_msgctl (msqid, cmd | IPC_64, buf);

in sys_parisc.c, and at least in some simple tests it seems to work
(whereas the original one was really broken)

haven't tested it very much yet.... a similar hack for semctl doesn't
seem to work. haven't investigated more yet.. but wanted to know if
others can shed light on what was the problems there....

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] what's up with the ipc syscalls?

[Thomas Bogendoerfer]

On Sat, Nov 01, 2003 at 12:24:51AM -0800, Randolph Chung wrote:
> in our syscall table, semctl, msgctl and shmctl are marked as "broken".
> Does anybody know what's up with that?
> 
> i did a simple hack, which is to replace
> 
>         return sys_msgctl (msqid, cmd & ~IPC_64, buf);
> 
> with 
> 
>         return sys_msgctl (msqid, cmd | IPC_64, buf);
> 
> in sys_parisc.c, and at least in some simple tests it seems to work
> (whereas the original one was really broken)

if this makes a difference, something in ipc/util.c is missing. When I
added the code above, I also made the ipc_parse_version only return
IPC_64, because we never had IPC_OLD. Older glibc made the call with
IPC_64 set, so we needed the wrapper in sys_parisc.c. I just looked
at the 2.4 version of ipc/util.c and it's still ok ...

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                 [ Alexander Viro on linux-kernel ]

Re: [parisc-linux] what's up with the ipc syscalls?

[Randolph Chung]

> if this makes a difference, something in ipc/util.c is missing. When I
> added the code above, I also made the ipc_parse_version only return
> IPC_64, because we never had IPC_OLD. Older glibc made the call with
> IPC_64 set, so we needed the wrapper in sys_parisc.c. I just looked
> at the 2.4 version of ipc/util.c and it's still ok ...

Ah! that explains it.... that change was not brought forward to 2.6...
i was wondering why my test worked on 2.4 and failed on 2.6....

anyway, if we are only supporting IPC_64, then why mask off the IPC64
bit in the wrapper? if the ipc/utils.c stuff isn't there, wouldn't it
default to doing the right thing when IPC_64 is set?

right now glibc *doesn't* call the syscall with IPC_64, but i'm about to
make it do that again.

thanks,
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] what's up with the ipc syscalls?

[Thomas Bogendoerfer]

On Sun, Nov 02, 2003 at 10:12:52AM -0800, Randolph Chung wrote:
> anyway, if we are only supporting IPC_64, then why mask off the IPC64
> bit in the wrapper? if the ipc/utils.c stuff isn't there, wouldn't it
> default to doing the right thing when IPC_64 is set?

look at the switch statements in msg.c/sem.c/shm.c. If you don't mask
off IPC_64, the cases don't match.

> right now glibc *doesn't* call the syscall with IPC_64, but i'm about to
> make it do that again.

I don't think this is a good idea, because by checking for IPC_64 we
could see, whether an old glibc is used and could convert structs
(see sys_parisc.c:sys_shmctl_broken()).

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                 [ Alexander Viro on linux-kernel ]

Re: [parisc-linux] what's up with the ipc syscalls?

[Randolph Chung]

> look at the switch statements in msg.c/sem.c/shm.c. If you don't mask
> off IPC_64, the cases don't match.
> 
> > right now glibc *doesn't* call the syscall with IPC_64, but i'm about to
> > make it do that again.
> 
> I don't think this is a good idea, because by checking for IPC_64 we
> could see, whether an old glibc is used and could convert structs
> (see sys_parisc.c:sys_shmctl_broken()).

?

the whole point is to check the value passed in from userspace instead
of forcing a particular value in the kernel, right?

what i'm proposing is:
- don't touch 2.4, glibc can pass in IPC_64 or not, and it will work
  (since the kernel forces something anyway)

- fix glibc to pass in IPC_64 properly into the kernel from now on, 
  2.4 will still work with current hacks.

- fix 2.6 to detect the IPC_64 flag and go through the "normal"
  (arch-indep) path to figure out it should use the new structs

2.6 is broken as it is now, so there's no 2.6 compatibility to worry
about.

did i miss something?

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] what's up with the ipc syscalls?

[Carlos O'Donell]

On Sun, Nov 02, 2003 at 10:42:00PM +0100, Thomas Bogendoerfer wrote:
> On Sun, Nov 02, 2003 at 10:12:52AM -0800, Randolph Chung wrote:
> > anyway, if we are only supporting IPC_64, then why mask off the IPC64
> > bit in the wrapper? if the ipc/utils.c stuff isn't there, wouldn't it
> > default to doing the right thing when IPC_64 is set?
> 
> look at the switch statements in msg.c/sem.c/shm.c. If you don't mask
> off IPC_64, the cases don't match.
> 
> > right now glibc *doesn't* call the syscall with IPC_64, but i'm about to
> > make it do that again.
> 
> I don't think this is a good idea, because by checking for IPC_64 we
> could see, whether an old glibc is used and could convert structs
> (see sys_parisc.c:sys_shmctl_broken()).

There is no such thing as that "old glibc" we have always had
__ASSUME_IPC64. What support are we looking to preserve?

c.

Re: [parisc-linux] what's up with the ipc syscalls?

[Thomas Bogendoerfer]

On Sun, Nov 02, 2003 at 05:56:27PM -0500, Carlos O'Donell wrote:
> On Sun, Nov 02, 2003 at 10:42:00PM +0100, Thomas Bogendoerfer wrote:
> > On Sun, Nov 02, 2003 at 10:12:52AM -0800, Randolph Chung wrote:
> > > anyway, if we are only supporting IPC_64, then why mask off the IPC64
> > > bit in the wrapper? if the ipc/utils.c stuff isn't there, wouldn't it
> > > default to doing the right thing when IPC_64 is set?
> > 
> > look at the switch statements in msg.c/sem.c/shm.c. If you don't mask
> > off IPC_64, the cases don't match.
> > 
> > > right now glibc *doesn't* call the syscall with IPC_64, but i'm about to
> > > make it do that again.
> > 
> > I don't think this is a good idea, because by checking for IPC_64 we
> > could see, whether an old glibc is used and could convert structs
> > (see sys_parisc.c:sys_shmctl_broken()).
> 
> There is no such thing as that "old glibc" we have always had
> __ASSUME_IPC64. What support are we looking to preserve?

glibc 2.2.x, some weeks before woody went final. For a closer date
check the date of my sys_parisc.c commit.

Since there might be still binaries in woody, which are compiled
with an such an "old" glibc, we will break this binaries. The suggested
change is an change of the kernel ABI, so I would avoid it. The problem
with this "old" glibc was, that the structs for shmctl and friends
weren't properly aligned for 64bit. I've changed that and also decided
to get rid of IPC_64, because that's x86 crap.

Adding the 2.4 changes to the 2.6 kernel should fix everything.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                 [ Alexander Viro on linux-kernel ]

Re: [parisc-linux] what's up with the ipc syscalls?

[Thomas Bogendoerfer]

On Sun, Nov 02, 2003 at 01:55:28PM -0800, Randolph Chung wrote:
> - fix glibc to pass in IPC_64 properly into the kernel from now on, 
>   2.4 will still work with current hacks.

no, 2.4 will break, because shmctl will try to fixup structs, which
don't need fixing. Please look at the code in sys_parisc.c

> - fix 2.6 to detect the IPC_64 flag and go through the "normal"
>   (arch-indep) path to figure out it should use the new structs

we only have new structs in the sense of ipc/*.c. That old stuff
is older x86 stuff, we never had. The only problem is, that we
had some broken structs, which weren't working on 64bit kernel, because
the alignment was broken.

> 2.6 is broken as it is now, so there's no 2.6 compatibility to worry
> about.

so why no just use the same way, I changed it in 2.4 ?

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                 [ Alexander Viro on linux-kernel ]

Re: [parisc-linux] what's up with the ipc syscalls?

[Carlos O'Donell]

On Mon, Nov 03, 2003 at 09:56:01AM +0100, Thomas Bogendoerfer wrote:
> glibc 2.2.x, some weeks before woody went final. For a closer date
> check the date of my sys_parisc.c commit.

My apologies Thomas I think I begin to see your logic. Now if you follow
me I'll paint a picture.

a. We don't have an IPC multiplexor.
b. We added all such functions into syscalls.list so they would be
   generated as assembly wrappers.
c. Kernel would activate IPC64 for all the calls so it returned IPC64 to
   userspace.

> Since there might be still binaries in woody, which are compiled
> with an such an "old" glibc, we will break this binaries. The suggested
> change is an change of the kernel ABI, so I would avoid it. The problem
> with this "old" glibc was, that the structs for shmctl and friends
> weren't properly aligned for 64bit. I've changed that and also decided
> to get rid of IPC_64, because that's x86 crap.
> 
> Adding the 2.4 changes to the 2.6 kernel should fix everything.

Should an old binary exist with this old glibc, it would break should
the kernel stop activating IPC64.

I agree that the 2.4 changes forward ported will change everything, but
the glibc changes are *also* required so we can eventually turn off the
kernel code that activates IPC64 for all the incoming calls. When we
don't care about these old binaries and old glibc we will remove the
kernel code.

Now it's my turn to ask the question: Did that make any sense? :o)

c.

Re: [parisc-linux] what's up with the ipc syscalls?

[Thomas Bogendoerfer]

On Mon, Nov 03, 2003 at 04:41:19PM -0500, Carlos O'Donell wrote:
> On Mon, Nov 03, 2003 at 09:56:01AM +0100, Thomas Bogendoerfer wrote:
[ stuff about broken ipc syscalls in 2.6 ...]

I had some thoughts about the conversion stuff, I've added to work
around problems introduced because of the change of some structures in
glibc/kernel. I finally realized, that these conversion only works,
if the "old glibc" is still installed together with the old binary.
That's because the newer glibcs don't set the IPC_64 bit when doing 
the syscall, but the old binary still uses the wrong structs, so the
conversion routine never triggers. I think it's really time to remove that
crap. Below is an compiled but not booted patch, which removes it and also
forward ports the necessary bits in ipc/util.c from 2.4. 

If someone also wants to change glibc, feel free. I still think changing
glibc is a bad idea, because this new glibc won't work with a current 2.4
kernel.

Thomas.


Index: arch/parisc/kernel/sys_parisc.c
===================================================================
RCS file: /home/cvs/parisc/linux-2.6/arch/parisc/kernel/sys_parisc.c,v
retrieving revision 1.15
diff -u -p -r1.15 sys_parisc.c
--- arch/parisc/kernel/sys_parisc.c	1 Nov 2003 23:44:02 -0000	1.15
+++ arch/parisc/kernel/sys_parisc.c	10 Nov 2003 23:17:53 -0000
@@ -241,108 +241,6 @@ asmlinkage ssize_t parisc_readahead(int 
 }
 
 /*
- * FIXME, please remove this crap as soon as possible
- *
- * This is here to fix up broken glibc structures, 
- * which are already fixed in newer glibcs
- */
-#include <linux/msg.h>
-#include <linux/sem.h>
-#include <linux/shm.h>
-#include "sys32.h"
-
-struct broken_ipc_perm
-{
-    key_t key;			/* Key.  */
-    uid_t uid;			/* Owner's user ID.  */
-    gid_t gid;			/* Owner's group ID.  */
-    uid_t cuid;			/* Creator's user ID.  */
-    gid_t cgid;			/* Creator's group ID.  */
-    unsigned short int mode;		/* Read/write permission.  */
-    unsigned short int __pad1;
-    unsigned short int seq;		/* Sequence number.  */
-    unsigned short int __pad2;
-    unsigned long int __unused1;
-    unsigned long int __unused2;
-};
-		    
-struct broken_shmid64_ds {
-	struct broken_ipc_perm	shm_perm;	/* operation perms */
-	size_t			shm_segsz;	/* size of segment (bytes) */
-#ifndef __LP64__
-	unsigned int		__pad1;
-#endif
-	__kernel_time_t		shm_atime;	/* last attach time */
-#ifndef __LP64__
-	unsigned int		__pad2;
-#endif
-	__kernel_time_t		shm_dtime;	/* last detach time */
-#ifndef __LP64__
-	unsigned int		__pad3;
-#endif
-	__kernel_time_t		shm_ctime;	/* last change time */
-	__kernel_pid_t		shm_cpid;	/* pid of creator */
-	__kernel_pid_t		shm_lpid;	/* pid of last operator */
-	unsigned int		shm_nattch;	/* no. of current attaches */
-	unsigned int		__unused1;
-	unsigned int		__unused2;
-};
-
-static void convert_broken_perm (struct broken_ipc_perm *out, struct ipc64_perm *in)
-{
-	out->key  = in->key;
-	out->uid  = in->uid;
-	out->gid  = in->gid;
-	out->cuid = in->cuid;
-	out->cgid = in->cgid;
-	out->mode = in->mode;
-	out->seq  = in->seq;
-}
-
-static int copyout_broken_shmid64(struct broken_shmid64_ds *buf, struct shmid64_ds *sbuf)
-{
-	struct broken_shmid64_ds tbuf;
-	
-	memset(&tbuf, 0, sizeof tbuf);
-	convert_broken_perm (&tbuf.shm_perm, &sbuf->shm_perm);
-	tbuf.shm_segsz = sbuf->shm_segsz;
-	tbuf.shm_atime = sbuf->shm_atime;
-	tbuf.shm_dtime = sbuf->shm_dtime;
-	tbuf.shm_ctime = sbuf->shm_ctime;
-	tbuf.shm_cpid = sbuf->shm_cpid;
-	tbuf.shm_lpid = sbuf->shm_lpid;
-	tbuf.shm_nattch = sbuf->shm_nattch;
-	return copy_to_user(buf, &tbuf, sizeof tbuf) ? -EFAULT : 0;
-}
-
-int sys_msgctl_broken(int msqid, int cmd, struct msqid_ds *buf)
-{
-	return sys_msgctl (msqid, cmd & ~IPC_64, buf);
-}
-
-int sys_semctl_broken(int semid, int semnum, int cmd, union semun arg)
-{
-	return sys_semctl (semid, semnum, cmd & ~IPC_64, arg);
-}
-
-int sys_shmctl_broken(int shmid, int cmd, struct shmid64_ds *buf)
-{
-	struct shmid64_ds sbuf;
-	int err;
-
-	if (cmd & IPC_64) {
-		cmd &= ~IPC_64;
-		if (cmd == IPC_STAT || cmd == SHM_STAT) {
-			KERNEL_SYSCALL(err, sys_shmctl, shmid, cmd, (struct shmid_ds *)&sbuf);
-			if (err == 0)
-				err = copyout_broken_shmid64((struct broken_shmid64_ds *)buf, &sbuf);
-			return err;
-		}
-	}
-	return sys_shmctl (shmid, cmd, (struct shmid_ds *)buf);
-}
-
-/*
  * This changes the io permissions bitmap in the current task.
  */
 asmlinkage int sys_ioperm(unsigned long from, unsigned long num, int turn_on)
Index: arch/parisc/kernel/sys_parisc32.c
===================================================================
RCS file: /home/cvs/parisc/linux-2.6/arch/parisc/kernel/sys_parisc32.c,v
retrieving revision 1.11
diff -u -p -r1.11 sys_parisc32.c
--- arch/parisc/kernel/sys_parisc32.c	28 Sep 2003 04:04:52 -0000	1.11
+++ arch/parisc/kernel/sys_parisc32.c	10 Nov 2003 23:19:00 -0000
@@ -1352,12 +1352,10 @@ asmlinkage int sys32_lseek(unsigned int 
 	return sys_lseek(fd, offset, origin);
 }
 
-asmlinkage long sys32_semctl_broken(int semid, int semnum, int cmd, union semun arg)
+asmlinkage long sys32_semctl(int semid, int semnum, int cmd, union semun arg)
 {
         union semun u;
 	
-	cmd &= ~IPC_64; /* should be removed together with the _broken suffix */
-
         if (cmd == SETVAL) {
                 /* Ugh.  arg is a union of int,ptr,ptr,ptr, so is 8 bytes.
                  * The int should be in the first 4, but our argument
Index: arch/parisc/kernel/syscall_table.S
===================================================================
RCS file: /home/cvs/parisc/linux-2.6/arch/parisc/kernel/syscall_table.S,v
retrieving revision 1.2
diff -u -p -r1.2 syscall_table.S
--- arch/parisc/kernel/syscall_table.S	2 Nov 2003 04:40:50 -0000	1.2
+++ arch/parisc/kernel/syscall_table.S	10 Nov 2003 23:18:46 -0000
@@ -260,15 +260,15 @@
 	ENTRY_COMP(recvmsg)
 	ENTRY_SAME(semop)		/* 185 */
 	ENTRY_SAME(semget)
-	ENTRY_DIFF(semctl_broken)
+	ENTRY_DIFF(semctl)
 	ENTRY_DIFF(msgsnd)
 	ENTRY_DIFF(msgrcv)
 	ENTRY_SAME(msgget)		/* 190 */
-	ENTRY_SAME(msgctl_broken)
+	ENTRY_SAME(msgctl)
 	ENTRY_SAME(shmat_wrapper)
 	ENTRY_SAME(shmdt)
 	ENTRY_SAME(shmget)
-	ENTRY_SAME(shmctl_broken)	/* 195 */
+	ENTRY_SAME(shmctl)		/* 195 */
 	ENTRY_SAME(ni_syscall)		/* streams1 */
 	ENTRY_SAME(ni_syscall)		/* streams2 */
 	ENTRY_SAME(lstat64)
Index: ipc/util.c
===================================================================
RCS file: /home/cvs/parisc/linux-2.6/ipc/util.c,v
retrieving revision 1.3
diff -u -p -r1.3 util.c
--- ipc/util.c	8 Oct 2003 20:53:06 -0000	1.3
+++ ipc/util.c	10 Nov 2003 23:19:41 -0000
@@ -509,7 +509,7 @@ int ipc_checkid(struct ipc_ids* ids, str
 	return 0;
 }
 
-#if !defined(__ia64__) && !defined(__x86_64__)
+#if !defined(__ia64__) && !defined(__x86_64__) && !defined(__hppa__)
 
 /**
  *	ipc_parse_version	-	IPC call version
Index: ipc/util.h
===================================================================
RCS file: /home/cvs/parisc/linux-2.6/ipc/util.h,v
retrieving revision 1.1
diff -u -p -r1.1 util.h
--- ipc/util.h	29 Jul 2003 17:02:19 -0000	1.1
+++ ipc/util.h	10 Nov 2003 23:20:13 -0000
@@ -56,7 +56,7 @@ int ipc_checkid(struct ipc_ids* ids, str
 void kernel_to_ipc64_perm(struct kern_ipc_perm *in, struct ipc64_perm *out);
 void ipc64_perm_to_ipc_perm(struct ipc64_perm *in, struct ipc_perm *out);
 
-#if defined(__ia64__) || defined(__x86_64__)
+#if defined(__ia64__) || defined(__x86_64__) || defined(__hppa__)
   /* On IA-64, we always use the "64-bit version" of the IPC structures.  */ 
 # define ipc_parse_version(cmd)	IPC_64
 #else
-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                 [ Alexander Viro on linux-kernel ]

Re: [parisc-linux] what's up with the ipc syscalls?

[Joel Soete]

Thomas Bogendoerfer wrote:
> On Mon, Nov 03, 2003 at 04:41:19PM -0500, Carlos O'Donell wrote:
> 
>>On Mon, Nov 03, 2003 at 09:56:01AM +0100, Thomas Bogendoerfer wrote:
> 
> [ stuff about broken ipc syscalls in 2.6 ...]
> 
> I had some thoughts about the conversion stuff, I've added to work
> around problems introduced because of the change of some structures in
> glibc/kernel. I finally realized, that these conversion only works,
> if the "old glibc" is still installed together with the old binary.
> That's because the newer glibcs don't set the IPC_64 bit when doing 
> the syscall, but the old binary still uses the wrong structs, so the
> conversion routine never triggers. I think it's really time to remove that
> crap. Below is an compiled but not booted patch, which removes it and also
> forward ports the necessary bits in ipc/util.c from 2.4.

I also reach to compile 2.4 with this patch :).

Can you point me out what should I apply as change to glibc?

Thanks,
	Joel

> 
> If someone also wants to change glibc, feel free. I still think changing
> glibc is a bad idea, because this new glibc won't work with a current 2.4
> kernel.
> 
> Thomas.
> 
> 
> Index: arch/parisc/kernel/sys_parisc.c
> ===================================================================
> RCS file: /home/cvs/parisc/linux-2.6/arch/parisc/kernel/sys_parisc.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 sys_parisc.c
> --- arch/parisc/kernel/sys_parisc.c	1 Nov 2003 23:44:02 -0000	1.15
> +++ arch/parisc/kernel/sys_parisc.c	10 Nov 2003 23:17:53 -0000
> @@ -241,108 +241,6 @@ asmlinkage ssize_t parisc_readahead(int 
>  }
>  
>  /*
> - * FIXME, please remove this crap as soon as possible
> - *
> - * This is here to fix up broken glibc structures, 
> - * which are already fixed in newer glibcs
> - */
> -#include <linux/msg.h>
> -#include <linux/sem.h>
> -#include <linux/shm.h>
> -#include "sys32.h"
> -
> -struct broken_ipc_perm
> -{
> -    key_t key;			/* Key.  */
> -    uid_t uid;			/* Owner's user ID.  */
> -    gid_t gid;			/* Owner's group ID.  */
> -    uid_t cuid;			/* Creator's user ID.  */
> -    gid_t cgid;			/* Creator's group ID.  */
> -    unsigned short int mode;		/* Read/write permission.  */
> -    unsigned short int __pad1;
> -    unsigned short int seq;		/* Sequence number.  */
> -    unsigned short int __pad2;
> -    unsigned long int __unused1;
> -    unsigned long int __unused2;
> -};
> -		    
> -struct broken_shmid64_ds {
> -	struct broken_ipc_perm	shm_perm;	/* operation perms */
> -	size_t			shm_segsz;	/* size of segment (bytes) */
> -#ifndef __LP64__
> -	unsigned int		__pad1;
> -#endif
> -	__kernel_time_t		shm_atime;	/* last attach time */
> -#ifndef __LP64__
> -	unsigned int		__pad2;
> -#endif
> -	__kernel_time_t		shm_dtime;	/* last detach time */
> -#ifndef __LP64__
> -	unsigned int		__pad3;
> -#endif
> -	__kernel_time_t		shm_ctime;	/* last change time */
> -	__kernel_pid_t		shm_cpid;	/* pid of creator */
> -	__kernel_pid_t		shm_lpid;	/* pid of last operator */
> -	unsigned int		shm_nattch;	/* no. of current attaches */
> -	unsigned int		__unused1;
> -	unsigned int		__unused2;
> -};
> -
> -static void convert_broken_perm (struct broken_ipc_perm *out, struct ipc64_perm *in)
> -{
> -	out->key  = in->key;
> -	out->uid  = in->uid;
> -	out->gid  = in->gid;
> -	out->cuid = in->cuid;
> -	out->cgid = in->cgid;
> -	out->mode = in->mode;
> -	out->seq  = in->seq;
> -}
> -
> -static int copyout_broken_shmid64(struct broken_shmid64_ds *buf, struct shmid64_ds *sbuf)
> -{
> -	struct broken_shmid64_ds tbuf;
> -	
> -	memset(&tbuf, 0, sizeof tbuf);
> -	convert_broken_perm (&tbuf.shm_perm, &sbuf->shm_perm);
> -	tbuf.shm_segsz = sbuf->shm_segsz;
> -	tbuf.shm_atime = sbuf->shm_atime;
> -	tbuf.shm_dtime = sbuf->shm_dtime;
> -	tbuf.shm_ctime = sbuf->shm_ctime;
> -	tbuf.shm_cpid = sbuf->shm_cpid;
> -	tbuf.shm_lpid = sbuf->shm_lpid;
> -	tbuf.shm_nattch = sbuf->shm_nattch;
> -	return copy_to_user(buf, &tbuf, sizeof tbuf) ? -EFAULT : 0;
> -}
> -
> -int sys_msgctl_broken(int msqid, int cmd, struct msqid_ds *buf)
> -{
> -	return sys_msgctl (msqid, cmd & ~IPC_64, buf);
> -}
> -
> -int sys_semctl_broken(int semid, int semnum, int cmd, union semun arg)
> -{
> -	return sys_semctl (semid, semnum, cmd & ~IPC_64, arg);
> -}
> -
> -int sys_shmctl_broken(int shmid, int cmd, struct shmid64_ds *buf)
> -{
> -	struct shmid64_ds sbuf;
> -	int err;
> -
> -	if (cmd & IPC_64) {
> -		cmd &= ~IPC_64;
> -		if (cmd == IPC_STAT || cmd == SHM_STAT) {
> -			KERNEL_SYSCALL(err, sys_shmctl, shmid, cmd, (struct shmid_ds *)&sbuf);
> -			if (err == 0)
> -				err = copyout_broken_shmid64((struct broken_shmid64_ds *)buf, &sbuf);
> -			return err;
> -		}
> -	}
> -	return sys_shmctl (shmid, cmd, (struct shmid_ds *)buf);
> -}
> -
> -/*
>   * This changes the io permissions bitmap in the current task.
>   */
>  asmlinkage int sys_ioperm(unsigned long from, unsigned long num, int turn_on)
> Index: arch/parisc/kernel/sys_parisc32.c
> ===================================================================
> RCS file: /home/cvs/parisc/linux-2.6/arch/parisc/kernel/sys_parisc32.c,v
> retrieving revision 1.11
> diff -u -p -r1.11 sys_parisc32.c
> --- arch/parisc/kernel/sys_parisc32.c	28 Sep 2003 04:04:52 -0000	1.11
> +++ arch/parisc/kernel/sys_parisc32.c	10 Nov 2003 23:19:00 -0000
> @@ -1352,12 +1352,10 @@ asmlinkage int sys32_lseek(unsigned int 
>  	return sys_lseek(fd, offset, origin);
>  }
>  
> -asmlinkage long sys32_semctl_broken(int semid, int semnum, int cmd, union semun arg)
> +asmlinkage long sys32_semctl(int semid, int semnum, int cmd, union semun arg)
>  {
>          union semun u;
>  	
> -	cmd &= ~IPC_64; /* should be removed together with the _broken suffix */
> -
>          if (cmd == SETVAL) {
>                  /* Ugh.  arg is a union of int,ptr,ptr,ptr, so is 8 bytes.
>                   * The int should be in the first 4, but our argument
> Index: arch/parisc/kernel/syscall_table.S
> ===================================================================
> RCS file: /home/cvs/parisc/linux-2.6/arch/parisc/kernel/syscall_table.S,v
> retrieving revision 1.2
> diff -u -p -r1.2 syscall_table.S
> --- arch/parisc/kernel/syscall_table.S	2 Nov 2003 04:40:50 -0000	1.2
> +++ arch/parisc/kernel/syscall_table.S	10 Nov 2003 23:18:46 -0000
> @@ -260,15 +260,15 @@
>  	ENTRY_COMP(recvmsg)
>  	ENTRY_SAME(semop)		/* 185 */
>  	ENTRY_SAME(semget)
> -	ENTRY_DIFF(semctl_broken)
> +	ENTRY_DIFF(semctl)
>  	ENTRY_DIFF(msgsnd)
>  	ENTRY_DIFF(msgrcv)
>  	ENTRY_SAME(msgget)		/* 190 */
> -	ENTRY_SAME(msgctl_broken)
> +	ENTRY_SAME(msgctl)
>  	ENTRY_SAME(shmat_wrapper)
>  	ENTRY_SAME(shmdt)
>  	ENTRY_SAME(shmget)
> -	ENTRY_SAME(shmctl_broken)	/* 195 */
> +	ENTRY_SAME(shmctl)		/* 195 */
>  	ENTRY_SAME(ni_syscall)		/* streams1 */
>  	ENTRY_SAME(ni_syscall)		/* streams2 */
>  	ENTRY_SAME(lstat64)
> Index: ipc/util.c
> ===================================================================
> RCS file: /home/cvs/parisc/linux-2.6/ipc/util.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 util.c
> --- ipc/util.c	8 Oct 2003 20:53:06 -0000	1.3
> +++ ipc/util.c	10 Nov 2003 23:19:41 -0000
> @@ -509,7 +509,7 @@ int ipc_checkid(struct ipc_ids* ids, str
>  	return 0;
>  }
>  
> -#if !defined(__ia64__) && !defined(__x86_64__)
> +#if !defined(__ia64__) && !defined(__x86_64__) && !defined(__hppa__)
>  
>  /**
>   *	ipc_parse_version	-	IPC call version
> Index: ipc/util.h
> ===================================================================
> RCS file: /home/cvs/parisc/linux-2.6/ipc/util.h,v
> retrieving revision 1.1
> diff -u -p -r1.1 util.h
> --- ipc/util.h	29 Jul 2003 17:02:19 -0000	1.1
> +++ ipc/util.h	10 Nov 2003 23:20:13 -0000
> @@ -56,7 +56,7 @@ int ipc_checkid(struct ipc_ids* ids, str
>  void kernel_to_ipc64_perm(struct kern_ipc_perm *in, struct ipc64_perm *out);
>  void ipc64_perm_to_ipc_perm(struct ipc64_perm *in, struct ipc_perm *out);
>  
> -#if defined(__ia64__) || defined(__x86_64__)
> +#if defined(__ia64__) || defined(__x86_64__) || defined(__hppa__)
>    /* On IA-64, we always use the "64-bit version" of the IPC structures.  */ 
>  # define ipc_parse_version(cmd)	IPC_64
>  #else

Re: [parisc-linux] what's up with the ipc syscalls?

[Carlos O'Donell]

> I had some thoughts about the conversion stuff, I've added to work
> around problems introduced because of the change of some structures in
> glibc/kernel. I finally realized, that these conversion only works,
> if the "old glibc" is still installed together with the old binary.
> That's because the newer glibcs don't set the IPC_64 bit when doing 
> the syscall, but the old binary still uses the wrong structs, so the
> conversion routine never triggers. I think it's really time to remove that
> crap. Below is an compiled but not booted patch, which removes it and also
> forward ports the necessary bits in ipc/util.c from 2.4. 

The following things confuse me.

a. Our glibc never set IPC_64, we had pass-thru assembly syscall
   wrappers. Why? Because we don't have an IPC multiplexor, none of the
   generic glibc code can be used by hppa.

So I don't understand some of your comments about "old glibc setting
IPC_64."

> If someone also wants to change glibc, feel free. I still think changing
> glibc is a bad idea, because this new glibc won't work with a current 2.4
> kernel.

I believed we had the following scenario:

a. Old glibc never called with IPC_64.
b. Kernel turned IPC_64 on for us so we get the new style structs.
c. Apps get new style structs without calling IPC_64.

Now we wish to have the hack in the kernel removed, but apps exist that
expect newstyle structs without calling IPC_64. Thus glibc has to
call the syscall with IPC_64 to get the right value back to userspace.

AFAIK the following is required:

a. Remove kernel hacks (Thanks Thomas!).
b. Add glibc code to turn IPC_64 on for all the afflicted syscalls.
c. Eventually when all the apps disappear we can toss out the code from
   glibc.

Thomas, did I get this right?

Cheers,
Carlos.

Re: [parisc-linux] what's up with the ipc syscalls?

[Thomas Bogendoerfer]

On Tue, Nov 11, 2003 at 04:46:10PM -0500, Carlos O'Donell wrote:
> > I had some thoughts about the conversion stuff, I've added to work
> > around problems introduced because of the change of some structures in
> > glibc/kernel. I finally realized, that these conversion only works,
> > if the "old glibc" is still installed together with the old binary.
> > That's because the newer glibcs don't set the IPC_64 bit when doing 
> > the syscall, but the old binary still uses the wrong structs, so the
> > conversion routine never triggers. I think it's really time to remove that
> > crap. Below is an compiled but not booted patch, which removes it and also
> > forward ports the necessary bits in ipc/util.c from 2.4. 
> 
> The following things confuse me.
> 
> a. Our glibc never set IPC_64, we had pass-thru assembly syscall
>    wrappers. Why? Because we don't have an IPC multiplexor, none of the
>    generic glibc code can be used by hppa.

IPC_64 has nothing to do with the x86 IPC multiplexor. It's for
selecting the IPC structures with bigger uid/gid/etc. . This is
only needed for x86, because there are structs with 16bit uid/gid.
Linux/PARISC always used 32bit uid/gid.

> So I don't understand some of your comments about "old glibc setting
> IPC_64."

glibc 2.2.x (don't know the exact number, if someone cares about the
version, I will try to find it out) has set IPC_64, because someone 
used a template from another architecture, maybe even x86. I've changed
that at the time, I changed the kernel code.

> a. Old glibc never called with IPC_64.

correct. NOTE: old means older than 2.2.x; woody glibc doesn't do that.

> b. Kernel turned IPC_64 on for us so we get the new style structs.

yes.

> c. Apps get new style structs without calling IPC_64.

right, but that's not done from the *_broken wrapper in sys_parisc.c,
but from the ipc_parse_version() in util.h. We use the same way
as x86_64 and ia64 already do. If we use the x86, we would need to
add stuff for IPC_OLD. This IMHO adds not needed bloat.

If we want to make that bullet proof, we should mask the IPC_64 bit
like the ipc_parse_version() function in ipc/util.c, but return always
IPC_64. Then it doesn't matter what glibc does. But we waste a bit
for IPC_EVEN_MORE_FUNKY_STRUCTS.

> Now we wish to have the hack in the kernel removed, but apps exist that
> expect newstyle structs without calling IPC_64. Thus glibc has to
> call the syscall with IPC_64 to get the right value back to userspace.

why ? The kernel knows it only supports IPC_64. It's the only thing it
knows and has to know right now.

> a. Remove kernel hacks (Thanks Thomas!).
> b. Add glibc code to turn IPC_64 on for all the afflicted syscalls.

no, just leave glibc alone. If you would do that and install this glibc
on a 2.4 kernel, the ipc syscalls will break, because of the hacks
there. Of course I'm also removing the hacks from the 2.4 kernel, but
there is an installed base of 2.4 kernel...

My patch just keeps the kernel ABI consistent between 2.4 and 2.6.
That's an strong argument in my eyes. Which means no kernel ABI
change, no need for a glibc change. And even better no broken
applications, because the kernel ABI hasn't changed.

> c. Eventually when all the apps disappear we can toss out the code from
>    glibc.

Re: [parisc-linux] what's up with the ipc syscalls?

[JSO]

Carlos O'Donell wrote:

>>I had some thoughts about the conversion stuff, I've added to work
>>around problems introduced because of the change of some structures in
>>glibc/kernel. I finally realized, that these conversion only works,
>>if the "old glibc" is still installed together with the old binary.
>>That's because the newer glibcs don't set the IPC_64 bit when doing 
>>the syscall, but the old binary still uses the wrong structs, so the
>>conversion routine never triggers. I think it's really time to remove that
>>crap. Below is an compiled but not booted patch, which removes it and also
>>forward ports the necessary bits in ipc/util.c from 2.4. 
>>    
>>
>
>The following things confuse me.
>
>a. Our glibc never set IPC_64, we had pass-thru assembly syscall
>   wrappers. Why? Because we don't have an IPC multiplexor, none of the
>   generic glibc code can be used by hppa.
>
>So I don't understand some of your comments about "old glibc setting
>IPC_64."
>
>  
>
>>If someone also wants to change glibc, feel free. I still think changing
>>glibc is a bad idea, because this new glibc won't work with a current 2.4
>>kernel.
>>    
>>
>
>I believed we had the following scenario:
>
>a. Old glibc never called with IPC_64.
>b. Kernel turned IPC_64 on for us so we get the new style structs.
>c. Apps get new style structs without calling IPC_64.
>
>Now we wish to have the hack in the kernel removed, but apps exist that
>expect newstyle structs without calling IPC_64. Thus glibc has to
>call the syscall with IPC_64 to get the right value back to userspace.
>
>AFAIK the following is required:
>
>a. Remove kernel hacks (Thanks Thomas!).
>  
>
So I test it successfuly with 2.4 on my b2k (just re-compile the kernel, 
ssh remote connection, rsync ft, ...) :)
Sorry no more time try 2.6 on a b180 :(

>b. Add glibc code to turn IPC_64 on for all the afflicted syscalls.
>c. Eventually when all the apps disappear we can toss out the code from
>   glibc.
>
>Thomas, did I get this right?
>
>Cheers,
>Carlos.
>
>_______________________________________________
>parisc-linux mailing list
>parisc-linux@lists.parisc-linux.org
>http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>  
>

Re: [parisc-linux] what's up with the ipc syscalls?

[Carlos O'Donell]

On Wed, Nov 12, 2003 at 04:32:55PM +0100, Thomas Bogendoerfer wrote:
> > The following things confuse me.
> > 
> > a. Our glibc never set IPC_64, we had pass-thru assembly syscall
> >    wrappers. Why? Because we don't have an IPC multiplexor, none of the
> >    generic glibc code can be used by hppa.
> 
> IPC_64 has nothing to do with the x86 IPC multiplexor. It's for
> selecting the IPC structures with bigger uid/gid/etc. . This is
> only needed for x86, because there are structs with 16bit uid/gid.
> Linux/PARISC always used 32bit uid/gid.

Yes it does. From userspace the glibc code calls INLINE_SYSCALL(...) and
calls the IPC multiplexor syscall directly. We can't use this code, so
we use the syscalls.list method to generate assembly wrappers, these
wrappers have no logic and merely pass-thru the users options to the
syscall. glibc for hppa could never have "turned on" IPC_64 without
cloning the associated .c files in libc/sysdeps/unix/sysv/linux/, and
AFAIK we never have. Do you know any different?
 
> > So I don't understand some of your comments about "old glibc setting
> > IPC_64."
> 
> glibc 2.2.x (don't know the exact number, if someone cares about the
> version, I will try to find it out) has set IPC_64, because someone 
> used a template from another architecture, maybe even x86. I've changed
> that at the time, I changed the kernel code.

This is the code I'm looking to find but cannot find. If you could track
down the revision I would be extremely happy since I would like to look
at the code. We essentially need to put this back into place so that the
older apps work (versioned symbol).

> > a. Old glibc never called with IPC_64.
> 
> correct. NOTE: old means older than 2.2.x; woody glibc doesn't do that.

Good. We're on the same page.

> > b. Kernel turned IPC_64 on for us so we get the new style structs.
> 
> yes.

Yes.

> > c. Apps get new style structs without calling IPC_64.
> 
> right, but that's not done from the *_broken wrapper in sys_parisc.c,
> but from the ipc_parse_version() in util.h. We use the same way
> as x86_64 and ia64 already do. If we use the x86, we would need to
> add stuff for IPC_OLD. This IMHO adds not needed bloat.
> 
> If we want to make that bullet proof, we should mask the IPC_64 bit
> like the ipc_parse_version() function in ipc/util.c, but return always
> IPC_64. Then it doesn't matter what glibc does. But we waste a bit
> for IPC_EVEN_MORE_FUNKY_STRUCTS.

That's why we have symbol versioning. We can construct some IPC syscalls
in glibc and version them so that the older apps can use them. The
newer apps can make the call directly to the kernel with the bit on or
off. Simplifies the kernel and pushes the version compat into glibc
where it should exist.

> > Now we wish to have the hack in the kernel removed, but apps exist that
> > expect newstyle structs without calling IPC_64. Thus glibc has to
> > call the syscall with IPC_64 to get the right value back to userspace.
> 
> why ? The kernel knows it only supports IPC_64. It's the only thing it
> knows and has to know right now.

Can we ignore the bit then and make the code simpler?

> > a. Remove kernel hacks (Thanks Thomas!).
> > b. Add glibc code to turn IPC_64 on for all the afflicted syscalls.
> 
> no, just leave glibc alone. If you would do that and install this glibc
> on a 2.4 kernel, the ipc syscalls will break, because of the hacks
> there. Of course I'm also removing the hacks from the 2.4 kernel, but
> there is an installed base of 2.4 kernel...
> 
> My patch just keeps the kernel ABI consistent between 2.4 and 2.6.
> That's an strong argument in my eyes. Which means no kernel ABI
> change, no need for a glibc change. And even better no broken
> applications, because the kernel ABI hasn't changed.

It only works for a glibc that *doesn't* set IPC_64?

> > c. Eventually when all the apps disappear we can toss out the code from
> >    glibc.
> 
> From my point of view, those old apps, which are covered by my hack
> are already gone, because they already stopped working after an glibc upgrade.

Untrue, we can put out a new glibc and the old apps can work again. This
glibc hasn't made it all the way up the chain.

c.