All of lore.kernel.org
 help / color / mirror / Atom feed
* [parisc-linux] Oops on 2.4.20-pa33
@ 2003-05-05 20:02 Jan-Benedict Glaw
  2003-05-05 20:05 ` Randolph Chung
  2003-05-05 20:10 ` [parisc-linux] Oops on 2.4.20-pa33 John David Anglin
  0 siblings, 2 replies; 28+ messages in thread
From: Jan-Benedict Glaw @ 2003-05-05 20:02 UTC (permalink / raw)
  To: parisc-linux

[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

Hi!

I've tried to compile/boot current 2.4.x CVS, but it Oopsed. I noted
down what looked really important (this is, IAOQ, r02 and kernel
addresses from stack). This is what I resolved out of System.map:

IAOQ:   10224658        __canonicalize_funcptr_for_compare
r02:    101229d4        do_sigaction

Kernel addresses on stack:
        1013a278        dentry_open
        10131a38        __kmem_cache_alloc
        101229d4        do_sigaction
        10102a9c        handle_interruption
        10122dc8        sys_rt_sigaction
        10107f90        syscall_exit
        10107084        intr_check_sig
        10106cf4        _switch_to_ret
        1013be10        chrdev_open
        1013a278        dentry_open
        1014aba8        locate_fd
        1011b530        it_real_fn

Seems I cannot really find it:)

b132l-1:~# gcc -v
Reading specs from /usr/lib/gcc-lib/hppa-linux/3.2.3/specs
Configured with: ../src/configure -v --enable-languages=c,c++,f77,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-objc-gc hppa-linux
Thread model: posix
gcc version 3.2.3

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Oops on 2.4.20-pa33
  2003-05-05 20:02 [parisc-linux] Oops on 2.4.20-pa33 Jan-Benedict Glaw
@ 2003-05-05 20:05 ` Randolph Chung
  2003-05-05 21:05   ` [parisc-linux] [PATCH-2.4] DIVA serial build error (was: Oops on 2.4.20-pa33) Jan-Benedict Glaw
  2003-05-06  6:04   ` [parisc-linux] Oops on 2.4.20-pa33 Joel Soete
  2003-05-05 20:10 ` [parisc-linux] Oops on 2.4.20-pa33 John David Anglin
  1 sibling, 2 replies; 28+ messages in thread
From: Randolph Chung @ 2003-05-05 20:05 UTC (permalink / raw)
  To: Jan-Benedict Glaw; +Cc: parisc-linux

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

> IAOQ:   10224658        __canonicalize_funcptr_for_compare
> r02:    101229d4        do_sigaction

i don't have a 32-bit machine handy, can you try this patch and let me
know if it fixes your problem? An earlier version of this was posted on
this list but didn't get commited. thx -randolph

Index: arch/parisc/kernel/signal.c
===================================================================
RCS file: /var/cvs/linux/arch/parisc/kernel/signal.c,v
retrieving revision 1.43
diff -u -p -r1.43 signal.c
--- arch/parisc/kernel/signal.c	4 Aug 2002 22:57:47 -0000	1.43
+++ arch/parisc/kernel/signal.c	5 May 2003 20:08:55 -0000
@@ -489,7 +489,7 @@ do_signal(sigset_t *oldset, struct pt_re
 		ka = &current->sig->action[signr-1];
 		DBG(("sa_handler is %x\n", 
 			(unsigned int) ka->sa.sa_handler));
-		if (ka->sa.sa_handler == SIG_IGN) {
+		if (ka->sa.sa_handler == (void *)SIG_IGN) {
 			if (signr != SIGCHLD)
 				continue;
 			while (sys_wait4(-1, NULL, WNOHANG, NULL) > 0)
@@ -497,7 +497,7 @@ do_signal(sigset_t *oldset, struct pt_re
 			continue;
 		}
 
-		if (ka->sa.sa_handler == SIG_DFL) {
+		if (ka->sa.sa_handler == (void *)SIG_DFL) {
 			int exit_code = signr;
 
 			/* Init gets no signals it doesn't want.  */

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Oops on 2.4.20-pa33
  2003-05-05 20:02 [parisc-linux] Oops on 2.4.20-pa33 Jan-Benedict Glaw
  2003-05-05 20:05 ` Randolph Chung
@ 2003-05-05 20:10 ` John David Anglin
  1 sibling, 0 replies; 28+ messages in thread
From: John David Anglin @ 2003-05-05 20:10 UTC (permalink / raw)
  To: Jan-Benedict Glaw; +Cc: parisc-linux

> I've tried to compile/boot current 2.4.x CVS, but it Oopsed. I noted
> down what looked really important (this is, IAOQ, r02 and kernel
> addresses from stack). This is what I resolved out of System.map:
> 
> IAOQ:   10224658        __canonicalize_funcptr_for_compare
> r02:    101229d4        do_sigaction

The fix for this was discussed on the list previously.  There needs
to be some "void *" casts added to various function pointer comparisons.
Search on the above functions to find the thread.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [parisc-linux] [PATCH-2.4] DIVA serial build error (was: Oops on 2.4.20-pa33)
  2003-05-05 20:05 ` Randolph Chung
@ 2003-05-05 21:05   ` Jan-Benedict Glaw
  2003-05-06 15:20     ` Jan-Benedict Glaw
  2003-05-06  6:04   ` [parisc-linux] Oops on 2.4.20-pa33 Joel Soete
  1 sibling, 1 reply; 28+ messages in thread
From: Jan-Benedict Glaw @ 2003-05-05 21:05 UTC (permalink / raw)
  To: parisc-linux

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]

On Mon, 2003-05-05 13:05:37 -0700, Randolph Chung <randolph@tausq.org>
wrote in message <20030505200537.GF29544@tausq.org>:
> > IAOQ:   10224658        __canonicalize_funcptr_for_compare
> > r02:    101229d4        do_sigaction
> 
> i don't have a 32-bit machine handy, can you try this patch and let me
> know if it fixes your problem? An earlier version of this was posted on
> this list but didn't get commited. thx -randolph

Oh, forgive me to be that read resistant:)

I'm currently rebuilding the kernel. While doing so, I remembered I had
to do a little compile fix. I'm not sure if it's correct, but at least,
it builds:


--- linux/drivers/char/serial.c.orig	2003-05-05 22:59:23.000000000 +0200
+++ linux/drivers/char/serial.c	2003-05-05 23:00:44.000000000 +0200
@@ -5836,10 +5836,10 @@
 
 	/* printk("Unloading %s: version %s\n", serial_name, serial_version); */
 	del_timer_sync(&serial_timer);
-#ifdef CONFIG_SERIAL_SHARE_IRQ
+#ifdef CONFIG_HP_DIVA
 	if (hp_diva_count > 0)
 		del_timer_sync(&hp_diva_timer);
-#endif /* CONFIG_SERIAL_SHARE_IRQ */
+#endif /* CONFIG_HP_DIVA */
 	save_flags(flags); cli();
         remove_bh(SERIAL_BH);
 	if ((e1 = tty_unregister_driver(&serial_driver)))


MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Oops on 2.4.20-pa33
  2003-05-05 20:05 ` Randolph Chung
  2003-05-05 21:05   ` [parisc-linux] [PATCH-2.4] DIVA serial build error (was: Oops on 2.4.20-pa33) Jan-Benedict Glaw
@ 2003-05-06  6:04   ` Joel Soete
  2003-05-06 14:04     ` Randolph Chung
  1 sibling, 1 reply; 28+ messages in thread
From: Joel Soete @ 2003-05-06  6:04 UTC (permalink / raw)
  To: Randolph Chung, Jan-Benedict Glaw; +Cc: parisc-linux

Hi all,

>
>> IAOQ:   10224658        __canonicalize_funcptr_for_compare
>> r02:    101229d4        do_sigaction
>
>i don't have a 32-bit machine handy, can you try this patch and let me
>know if it fixes your problem? An earlier version of this was posted on
>this list but didn't get commited. thx -randolph
>
>Index: arch/parisc/kernel/signal.c
>===================================================================
>RCS file: /var/cvs/linux/arch/parisc/kernel/signal.c,v
>retrieving revision 1.43
>diff -u -p -r1.43 signal.c
>--- arch/parisc/kernel/signal.c	4 Aug 2002 22:57:47 -0000	1.43
>+++ arch/parisc/kernel/signal.c	5 May 2003 20:08:55 -0000

AFAIK here is the full patch I suggested after some mail exchanges with Dave:

diff -Naur linux-2.4.20-pa32/arch/parisc/kernel/signal.c linux-2.4.20-pa32-gcc33/arch/parisc/kernel/signal.c
--- linux-2.4.20-pa32/arch/parisc/kernel/signal.c	2003-03-21 10:54:23.000000000
+0100
+++ linux-2.4.20-pa32-gcc33/arch/parisc/kernel/signal.c	2003-03-21 12:39:20.000000000
+0100
@@ -489,7 +489,11 @@
 		ka = &current->sig->action[signr-1];
 		DBG(("sa_handler is %x\n", 
 			(unsigned int) ka->sa.sa_handler));
+#if !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__
>= 1))
+		if (ka->sa.sa_handler == (void *)SIG_IGN) {
+#else
 		if (ka->sa.sa_handler == SIG_IGN) {
+#endif
 			if (signr != SIGCHLD)
 				continue;
 			while (sys_wait4(-1, NULL, WNOHANG, NULL) > 0)
@@ -497,7 +501,11 @@
 			continue;
 		}
 
+#if !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__
>= 1))
+		if (ka->sa.sa_handler == (void *)SIG_DFL) {
+#else
 		if (ka->sa.sa_handler == SIG_DFL) {
+#endif
 			int exit_code = signr;
 
 			/* Init gets no signals it doesn't want.  */
diff -Naur linux-2.4.20-pa32/drivers/char/n_tty.c linux-2.4.20-pa32-gcc33/drivers/char/n_tty.c
--- linux-2.4.20-pa32/drivers/char/n_tty.c	2003-03-21 10:51:30.000000000
+0100
+++ linux-2.4.20-pa32-gcc33/drivers/char/n_tty.c	2003-03-21 12:34:35.000000000
+0100
@@ -810,7 +810,11 @@
 int is_ignored(int sig)
 {
 	return (sigismember(&current->blocked, sig) ||
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+	        current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN);
+#else
 	        current->sig->action[sig-1].sa.sa_handler == SIG_IGN);
+#endif
 }
 
 static void n_tty_set_termios(struct tty_struct *tty, struct termios * old)
diff -Naur linux-2.4.20-pa32/fs/ncpfs/sock.c linux-2.4.20-pa32-gcc33/fs/ncpfs/sock.c
--- linux-2.4.20-pa32/fs/ncpfs/sock.c	2003-03-21 10:36:05.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/fs/ncpfs/sock.c	2003-03-21 12:35:37.000000000
+0100
@@ -466,9 +466,17 @@
 			   What if we've blocked it ourselves?  What about
 			   alarms?  Why, in fact, are we mucking with the
 			   sigmask at all? -- r~ */
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+			if (current->sig->action[SIGINT - 1].sa.sa_handler == (void *)SIG_DFL)
+#else
 			if (current->sig->action[SIGINT - 1].sa.sa_handler == SIG_DFL)
+#endif
 				mask |= sigmask(SIGINT);
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+			if (current->sig->action[SIGQUIT - 1].sa.sa_handler == (void *)SIG_DFL)
+#else
 			if (current->sig->action[SIGQUIT - 1].sa.sa_handler == SIG_DFL)
+#endif
 				mask |= sigmask(SIGQUIT);
 		}
 		siginitsetinv(&current->blocked, mask);
diff -Naur linux-2.4.20-pa32/fs/proc/array.c linux-2.4.20-pa32-gcc33/fs/proc/array.c
--- linux-2.4.20-pa32/fs/proc/array.c	2003-03-21 10:01:18.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/fs/proc/array.c	2003-03-21 12:36:44.000000000
+0100
@@ -231,9 +231,17 @@
 	if (p->sig) {
 		k = p->sig->action;
 		for (i = 1; i <= _NSIG; ++i, ++k) {
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+			if (k->sa.sa_handler == (void *)SIG_IGN)
+#else
 			if (k->sa.sa_handler == SIG_IGN)
+#endif
 				sigaddset(ign, i);
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+			else if (k->sa.sa_handler != (void *)SIG_DFL)
+#else
 			else if (k->sa.sa_handler != SIG_DFL)
+#endif
 				sigaddset(catch, i);
 		}
 	}
diff -Naur linux-2.4.20-pa32/include/linux/compiler.h linux-2.4.20-pa32-gcc33/include/linux/compiler.h
--- linux-2.4.20-pa32/include/linux/compiler.h	2003-03-21 12:31:39.000000000
+0100
+++ linux-2.4.20-pa32-gcc33/include/linux/compiler.h	2003-03-21 12:32:07.000000000
+0100
@@ -1,6 +1,12 @@
 #ifndef __LINUX_COMPILER_H
 #define __LINUX_COMPILER_H
 
+#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
+#define inline		__inline__ __attribute__((always_inline))
+#define __inline__	__inline__ __attribute__((always_inline))
+#define __inline	__inline__ __attribute__((always_inline))
+#endif
+
 /* Somewhere in the middle of the GCC 2.96 development cycle, we implemented
    a mechanism by which the user can annotate likely branch directions and
    expect the blocks to be reordered appropriately.  Define __builtin_expect
diff -Naur linux-2.4.20-pa32/kernel/signal.c linux-2.4.20-pa32-gcc33/kernel/signal.c
--- linux-2.4.20-pa32/kernel/signal.c	2003-03-21 10:39:32.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/kernel/signal.c	2003-03-21 12:37:40.000000000
+0100
@@ -126,7 +126,11 @@
 	int i;
 	struct k_sigaction *ka = &t->sig->action[0];
 	for (i = _NSIG ; i != 0 ; i--) {
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+		if (ka->sa.sa_handler != (void *)SIG_IGN)
+#else
 		if (ka->sa.sa_handler != SIG_IGN)
+#endif
 			ka->sa.sa_handler = SIG_DFL;
 		ka->sa.sa_flags = 0;
 		sigemptyset(&ka->sa.sa_mask);
@@ -572,7 +576,11 @@
 		return -ESRCH;
 	}
 
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+	if (t->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN)
+#else
 	if (t->sig->action[sig-1].sa.sa_handler == SIG_IGN)
+#endif
 		t->sig->action[sig-1].sa.sa_handler = SIG_DFL;
 	sigdelset(&t->blocked, sig);
 	recalc_sigpending(t);
@@ -1094,8 +1102,13 @@
 		 * the signal to be ignored.
 		 */
 
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+		if (k->sa.sa_handler == (void *)SIG_IGN
+		    || (k->sa.sa_handler == (void *)SIG_DFL
+#else
 		if (k->sa.sa_handler == SIG_IGN
 		    || (k->sa.sa_handler == SIG_DFL
+#endif
 			&& (sig == SIGCONT ||
 			    sig == SIGCHLD ||
 			    sig == SIGURG ||
diff -Naur linux-2.4.20-pa32/net/sunrpc/clnt.c linux-2.4.20-pa32-gcc33/net/sunrpc/clnt.c
--- linux-2.4.20-pa32/net/sunrpc/clnt.c	2003-03-21 10:46:28.000000000 +0100
+++ linux-2.4.20-pa32-gcc33/net/sunrpc/clnt.c	2003-03-21 12:38:07.000000000
+0100
@@ -209,9 +209,17 @@
 	/* Turn off various signals */
 	if (clnt->cl_intr) {
 		struct k_sigaction *action = current->sig->action;
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+		if (action[SIGINT-1].sa.sa_handler == (void *)SIG_DFL)
+#else
 		if (action[SIGINT-1].sa.sa_handler == SIG_DFL)
+#endif
 			sigallow |= sigmask(SIGINT);
+#if defined (__hppa__) && !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__
== 3 && __GNUC_MINOR__ >= 1))
+		if (action[SIGQUIT-1].sa.sa_handler == (void *)SIG_DFL)
+#else
 		if (action[SIGQUIT-1].sa.sa_handler == SIG_DFL)
+#endif
 			sigallow |= sigmask(SIGQUIT);
 	}
 	spin_lock_irqsave(&current->sigmask_lock, irqflags);

hth,
    Joel

PS: It was writen for gcc > 3.1 and I was just working on a simplification
(remove _GNUC_ [sub]version test as suggested by Willy) but during test with
so gcc-3.0 I encounter HW pb with my b2k of test. I finaly compile but runs
seems to present pb (but I quiet convience it is the HW pb). Can somebody
else would test more?


---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Oops on 2.4.20-pa33
  2003-05-06  6:04   ` [parisc-linux] Oops on 2.4.20-pa33 Joel Soete
@ 2003-05-06 14:04     ` Randolph Chung
  2003-05-06 15:04       ` Joel Soete
  0 siblings, 1 reply; 28+ messages in thread
From: Randolph Chung @ 2003-05-06 14:04 UTC (permalink / raw)
  To: Joel Soete; +Cc: Jan-Benedict Glaw, parisc-linux

> AFAIK here is the full patch I suggested after some mail exchanges with Dave:
> 

I think willy already mentioned that:

> +#if !defined (__LP64__) && ((__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__
> >= 1))
> +		if (ka->sa.sa_handler == (void *)SIG_IGN) {
> +#else
>  		if (ka->sa.sa_handler == SIG_IGN) {
> +#endif

is wrong.. just do

> +		if (ka->sa.sa_handler == (void *)SIG_IGN) {

unconditionally. don't put the ifdef's in.

can you post a cleaned up patch?

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Oops on 2.4.20-pa33
  2003-05-06 14:04     ` Randolph Chung
@ 2003-05-06 15:04       ` Joel Soete
  2003-05-06 15:08         ` Randolph Chung
  2003-05-06 16:34         ` Joel Soete
  0 siblings, 2 replies; 28+ messages in thread
From: Joel Soete @ 2003-05-06 15:04 UTC (permalink / raw)
  To: Randolph Chung; +Cc: Jan-Benedict Glaw, parisc-linux

>
>is wrong.. just do
>
>> +		if (ka->sa.sa_handler == (void *)SIG_IGN) {
>
>unconditionally. don't put the ifdef's in.
>
That is ok for me (even if I don't understand very well :( ; afaik the previous
code works fine for gcc<=3.1 and do not seems to concern 64bits? )

That said, I will try to prepare a new patch asap.

Joel


---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Oops on 2.4.20-pa33
  2003-05-06 15:04       ` Joel Soete
@ 2003-05-06 15:08         ` Randolph Chung
  2003-05-06 16:34         ` Joel Soete
  1 sibling, 0 replies; 28+ messages in thread
From: Randolph Chung @ 2003-05-06 15:08 UTC (permalink / raw)
  To: Joel Soete; +Cc: Jan-Benedict Glaw, parisc-linux

> That is ok for me (even if I don't understand very well :( ; afaik the previous
> code works fine for gcc<=3.1 and do not seems to concern 64bits? )

The point is that if the new code is always correct, then littering 
the code with #ifdef's makes the code hard to read and maintain. If 
you really need to make the code different for the two cases, it's 
better to conditionally define a function/macro in a single place 
(header file) and use that in the source, rather than having ifdef's 
in many places.

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] [PATCH-2.4] DIVA serial build error (was: Oops on 2.4.20-pa33)
  2003-05-05 21:05   ` [parisc-linux] [PATCH-2.4] DIVA serial build error (was: Oops on 2.4.20-pa33) Jan-Benedict Glaw
@ 2003-05-06 15:20     ` Jan-Benedict Glaw
  2003-05-07 16:27       ` Paul Bame
  0 siblings, 1 reply; 28+ messages in thread
From: Jan-Benedict Glaw @ 2003-05-06 15:20 UTC (permalink / raw)
  To: parisc-linux

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

On Mon, 2003-05-05 23:05:32 +0200, Jan-Benedict Glaw <jbglaw@lug-owl.de>
wrote in message <20030505210532.GU27494@lug-owl.de>:
> On Mon, 2003-05-05 13:05:37 -0700, Randolph Chung <randolph@tausq.org>
> wrote in message <20030505200537.GF29544@tausq.org>:
> > > IAOQ:   10224658        __canonicalize_funcptr_for_compare
> > > r02:    101229d4        do_sigaction
> > 
> > i don't have a 32-bit machine handy, can you try this patch and let me
> > know if it fixes your problem? An earlier version of this was posted on
> > this list but didn't get commited. thx -randolph
> 
> Oh, forgive me to be that read resistant:)

I've tried your patch - the box still crashed, but I haven't noted down
all the crash (out of time:( I'll redo it most probably this evening.

Has anybody looked at the other patch (I sent with the mail I'm now
replyin' to)? It was needed and seems to be correct. Is anybody to check
it into CVS?

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Oops on 2.4.20-pa33
  2003-05-06 15:04       ` Joel Soete
  2003-05-06 15:08         ` Randolph Chung
@ 2003-05-06 16:34         ` Joel Soete
  2003-05-06 16:42           ` John David Anglin
  1 sibling, 1 reply; 28+ messages in thread
From: Joel Soete @ 2003-05-06 16:34 UTC (permalink / raw)
  To: Randolph Chung; +Cc: Jan-Benedict Glaw, parisc-linux

>
>That said, I will try to prepare a new patch asap.
>
Ok here we are:

=====
diff -NaurX dontdiff linux-2.4.20-pa33/arch/parisc/kernel/signal.c linux-2.4.20-pa33-gcc33/arch/parisc/kernel/signal.c
--- linux-2.4.20-pa33/arch/parisc/kernel/signal.c	2003-05-06 17:47:32.000000000
+0200
+++ linux-2.4.20-pa33-gcc33/arch/parisc/kernel/signal.c	2003-05-06 18:09:35.000000000
+0200
@@ -489,7 +489,7 @@
 		ka = &current->sig->action[signr-1];
 		DBG(("sa_handler is %x\n", 
 			(unsigned int) ka->sa.sa_handler));
-		if (ka->sa.sa_handler == SIG_IGN) {
+		if (ka->sa.sa_handler == (void *)SIG_IGN) {
 			if (signr != SIGCHLD)
 				continue;
 			while (sys_wait4(-1, NULL, WNOHANG, NULL) > 0)
@@ -497,7 +497,7 @@
 			continue;
 		}
 
-		if (ka->sa.sa_handler == SIG_DFL) {
+		if (ka->sa.sa_handler == (void *)SIG_DFL) {
 			int exit_code = signr;
 
 			/* Init gets no signals it doesn't want.  */
diff -NaurX dontdiff linux-2.4.20-pa33/drivers/char/n_tty.c linux-2.4.20-pa33-gcc33/drivers/char/n_tty.c
--- linux-2.4.20-pa33/drivers/char/n_tty.c	2003-05-06 17:49:36.000000000
+0200
+++ linux-2.4.20-pa33-gcc33/drivers/char/n_tty.c	2003-05-06 18:10:25.000000000
+0200
@@ -810,7 +810,11 @@
 int is_ignored(int sig)
 {
 	return (sigismember(&current->blocked, sig) ||
+#if defined (__hppa__)
+	        current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN);
+#else
 	        current->sig->action[sig-1].sa.sa_handler == SIG_IGN);
+#endif
 }
 
 static void n_tty_set_termios(struct tty_struct *tty, struct termios * old)
diff -NaurX dontdiff linux-2.4.20-pa33/fs/ncpfs/sock.c linux-2.4.20-pa33-gcc33/fs/ncpfs/sock.c
--- linux-2.4.20-pa33/fs/ncpfs/sock.c	2003-05-06 17:50:52.000000000 +0200
+++ linux-2.4.20-pa33-gcc33/fs/ncpfs/sock.c	2003-05-06 18:11:12.000000000
+0200
@@ -466,9 +466,17 @@
 			   What if we've blocked it ourselves?  What about
 			   alarms?  Why, in fact, are we mucking with the
 			   sigmask at all? -- r~ */
+#if defined (__hppa__)
+			if (current->sig->action[SIGINT - 1].sa.sa_handler == (void *)SIG_DFL)
+#else
 			if (current->sig->action[SIGINT - 1].sa.sa_handler == SIG_DFL)
+#endif
 				mask |= sigmask(SIGINT);
+#if defined (__hppa__)
+			if (current->sig->action[SIGQUIT - 1].sa.sa_handler == (void *)SIG_DFL)
+#else
 			if (current->sig->action[SIGQUIT - 1].sa.sa_handler == SIG_DFL)
+#endif
 				mask |= sigmask(SIGQUIT);
 		}
 		siginitsetinv(&current->blocked, mask);
diff -NaurX dontdiff linux-2.4.20-pa33/fs/proc/array.c linux-2.4.20-pa33-gcc33/fs/proc/array.c
--- linux-2.4.20-pa33/fs/proc/array.c	2002-08-07 07:56:58.000000000 +0200
+++ linux-2.4.20-pa33-gcc33/fs/proc/array.c	2003-05-06 18:12:07.000000000
+0200
@@ -231,9 +231,17 @@
 	if (p->sig) {
 		k = p->sig->action;
 		for (i = 1; i <= _NSIG; ++i, ++k) {
+#if defined (__hppa__)
+			if (k->sa.sa_handler == (void *)SIG_IGN)
+#else
 			if (k->sa.sa_handler == SIG_IGN)
+#endif
 				sigaddset(ign, i);
+#if defined (__hppa__)
+			else if (k->sa.sa_handler != (void *)SIG_DFL)
+#else
 			else if (k->sa.sa_handler != SIG_DFL)
+#endif
 				sigaddset(catch, i);
 		}
 	}
diff -NaurX dontdiff linux-2.4.20-pa33/kernel/signal.c linux-2.4.20-pa33-gcc33/kernel/signal.c
--- linux-2.4.20-pa33/kernel/signal.c	2002-11-29 07:49:17.000000000 +0100
+++ linux-2.4.20-pa33-gcc33/kernel/signal.c	2003-05-06 18:13:50.000000000
+0200
@@ -126,7 +126,11 @@
 	int i;
 	struct k_sigaction *ka = &t->sig->action[0];
 	for (i = _NSIG ; i != 0 ; i--) {
+#if defined (__hppa__)
+		if (ka->sa.sa_handler != (void *)SIG_IGN)
+#else
 		if (ka->sa.sa_handler != SIG_IGN)
+#endif
 			ka->sa.sa_handler = SIG_DFL;
 		ka->sa.sa_flags = 0;
 		sigemptyset(&ka->sa.sa_mask);
@@ -572,7 +576,11 @@
 		return -ESRCH;
 	}
 
+#if defined (__hppa__)
+	if (t->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN)
+#else
 	if (t->sig->action[sig-1].sa.sa_handler == SIG_IGN)
+#endif
 		t->sig->action[sig-1].sa.sa_handler = SIG_DFL;
 	sigdelset(&t->blocked, sig);
 	recalc_sigpending(t);
@@ -1094,8 +1102,13 @@
 		 * the signal to be ignored.
 		 */
 
+#if defined (__hppa__)
+		if (k->sa.sa_handler == (void *)SIG_IGN
+		    || (k->sa.sa_handler == (void *)SIG_DFL
+#else
 		if (k->sa.sa_handler == SIG_IGN
 		    || (k->sa.sa_handler == SIG_DFL
+#endif
 			&& (sig == SIGCONT ||
 			    sig == SIGCHLD ||
 			    sig == SIGURG ||
diff -NaurX dontdiff linux-2.4.20-pa33/net/sunrpc/clnt.c linux-2.4.20-pa33-gcc33/net/sunrpc/clnt.c
--- linux-2.4.20-pa33/net/sunrpc/clnt.c	2003-05-06 18:03:20.000000000 +0200
+++ linux-2.4.20-pa33-gcc33/net/sunrpc/clnt.c	2003-05-06 18:14:43.000000000
+0200
@@ -209,9 +209,17 @@
 	/* Turn off various signals */
 	if (clnt->cl_intr) {
 		struct k_sigaction *action = current->sig->action;
+#if defined (__hppa__)
+		if (action[SIGINT-1].sa.sa_handler == (void *)SIG_DFL)
+#else
 		if (action[SIGINT-1].sa.sa_handler == SIG_DFL)
+#endif
 			sigallow |= sigmask(SIGINT);
+#if defined (__hppa__)
+		if (action[SIGQUIT-1].sa.sa_handler == (void *)SIG_DFL)
+#else
 		if (action[SIGQUIT-1].sa.sa_handler == SIG_DFL)
+#endif
 			sigallow |= sigmask(SIGQUIT);
 	}
 	spin_lock_irqsave(&current->sigmask_lock, irqflags);
diff -NaurX dontdiff linux-2.4.20-pa33/include/linux/compiler.h linux-2.4.20-pa33-gcc33/include/linux/compiler.h
--- linux-2.4.20-pa33/include/linux/compiler.h	2003-05-06 18:01:11.000000000
+0200
+++ linux-2.4.20-pa33-gcc33/include/linux/compiler.h	2003-05-06 18:08:56.000000000
+0200
@@ -1,6 +1,12 @@
 #ifndef __LINUX_COMPILER_H
 #define __LINUX_COMPILER_H
 
+#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
+#define inline		__inline__ __attribute__((always_inline))
+#define __inline__	__inline__ __attribute__((always_inline))
+#define __inline	__inline__ __attribute__((always_inline))
+#endif
+
 /* Somewhere in the middle of the GCC 2.96 development cycle, we implemented
    a mechanism by which the user can annotate likely branch directions and
    expect the blocks to be reordered appropriately.  Define __builtin_expect

PS1: compiler patch is not of me; a backport suggested in the pa-ml (Willy
iirc)

PS2: for files in main tree I save (if _hppa_ because seems to be specific
to hppa according very early Dave mail :)

hth,
    Joel


---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Oops on 2.4.20-pa33
  2003-05-06 16:34         ` Joel Soete
@ 2003-05-06 16:42           ` John David Anglin
  2003-05-06 17:56             ` Joel Soete
  2003-05-10 20:31             ` [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' pb Joel Soete
  0 siblings, 2 replies; 28+ messages in thread
From: John David Anglin @ 2003-05-06 16:42 UTC (permalink / raw)
  To: Joel Soete; +Cc: randolph, jbglaw, parisc-linux

> +#if defined (__hppa__)
> +	        current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN);
> +#else
>  	        current->sig->action[sig-1].sa.sa_handler == SIG_IGN);
> +#endif

You don't need to conditionalize the statement with the cast.  It should
work on all ports.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Oops on 2.4.20-pa33
  2003-05-06 16:42           ` John David Anglin
@ 2003-05-06 17:56             ` Joel Soete
  2003-05-07 15:48               ` Jan-Benedict Glaw
  2003-05-08  6:12               ` [parisc-linux] [PATCH-linux-2.5] sa_handler compare with cast Jan-Benedict Glaw
  2003-05-10 20:31             ` [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' pb Joel Soete
  1 sibling, 2 replies; 28+ messages in thread
From: Joel Soete @ 2003-05-06 17:56 UTC (permalink / raw)
  To: John David Anglin; +Cc: randolph, jbglaw, parisc-linux

>> +#if defined (__hppa__)
>> +	        current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN);
>> +#else
>>  	        current->sig->action[sig-1].sa.sa_handler == SIG_IGN);
>> +#endif
>
>You don't need to conditionalize the statement with the cast.  It should
>work on all ports.
>
I trust you.

So it will finaly become:
diff -NaurX dontdiff linux-2.4.20-pa33/arch/parisc/kernel/signal.c linux-2.4.20-pa33-gcc33/arch/parisc/kernel/signal.c
--- linux-2.4.20-pa33/arch/parisc/kernel/signal.c	2003-05-06 17:47:32.000000000
+0200
+++ linux-2.4.20-pa33-gcc33/arch/parisc/kernel/signal.c	2003-05-06 18:09:35.000000000
+0200
@@ -489,7 +489,7 @@
 		ka = &current->sig->action[signr-1];
 		DBG(("sa_handler is %x\n", 
 			(unsigned int) ka->sa.sa_handler));
-		if (ka->sa.sa_handler == SIG_IGN) {
+		if (ka->sa.sa_handler == (void *)SIG_IGN) {
 			if (signr != SIGCHLD)
 				continue;
 			while (sys_wait4(-1, NULL, WNOHANG, NULL) > 0)
@@ -497,7 +497,7 @@
 			continue;
 		}
 
-		if (ka->sa.sa_handler == SIG_DFL) {
+		if (ka->sa.sa_handler == (void *)SIG_DFL) {
 			int exit_code = signr;
 
 			/* Init gets no signals it doesn't want.  */
diff -NaurX dontdiff linux-2.4.20-pa33/drivers/char/n_tty.c linux-2.4.20-pa33-gcc33/drivers/char/n_tty.c
--- linux-2.4.20-pa33/drivers/char/n_tty.c	2003-05-06 17:49:36.000000000
+0200
+++ linux-2.4.20-pa33-gcc33/drivers/char/n_tty.c	2003-05-06 19:59:33.000000000
+0200
@@ -810,7 +810,7 @@
 int is_ignored(int sig)
 {
 	return (sigismember(&current->blocked, sig) ||
-	        current->sig->action[sig-1].sa.sa_handler == SIG_IGN);
+	        current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN);
 }
 
 static void n_tty_set_termios(struct tty_struct *tty, struct termios * old)
diff -NaurX dontdiff linux-2.4.20-pa33/fs/ncpfs/sock.c linux-2.4.20-pa33-gcc33/fs/ncpfs/sock.c
--- linux-2.4.20-pa33/fs/ncpfs/sock.c	2003-05-06 17:50:52.000000000 +0200
+++ linux-2.4.20-pa33-gcc33/fs/ncpfs/sock.c	2003-05-06 19:59:53.000000000
+0200
@@ -466,9 +466,9 @@
 			   What if we've blocked it ourselves?  What about
 			   alarms?  Why, in fact, are we mucking with the
 			   sigmask at all? -- r~ */
-			if (current->sig->action[SIGINT - 1].sa.sa_handler == SIG_DFL)
+			if (current->sig->action[SIGINT - 1].sa.sa_handler == (void *)SIG_DFL)
 				mask |= sigmask(SIGINT);
-			if (current->sig->action[SIGQUIT - 1].sa.sa_handler == SIG_DFL)
+			if (current->sig->action[SIGQUIT - 1].sa.sa_handler == (void *)SIG_DFL)
 				mask |= sigmask(SIGQUIT);
 		}
 		siginitsetinv(&current->blocked, mask);
diff -NaurX dontdiff linux-2.4.20-pa33/fs/proc/array.c linux-2.4.20-pa33-gcc33/fs/proc/array.c
--- linux-2.4.20-pa33/fs/proc/array.c	2002-08-07 07:56:58.000000000 +0200
+++ linux-2.4.20-pa33-gcc33/fs/proc/array.c	2003-05-06 20:00:10.000000000
+0200
@@ -231,9 +231,9 @@
 	if (p->sig) {
 		k = p->sig->action;
 		for (i = 1; i <= _NSIG; ++i, ++k) {
-			if (k->sa.sa_handler == SIG_IGN)
+			if (k->sa.sa_handler == (void *)SIG_IGN)
 				sigaddset(ign, i);
-			else if (k->sa.sa_handler != SIG_DFL)
+			else if (k->sa.sa_handler != (void *)SIG_DFL)
 				sigaddset(catch, i);
 		}
 	}
diff -NaurX dontdiff linux-2.4.20-pa33/kernel/signal.c linux-2.4.20-pa33-gcc33/kernel/signal.c
--- linux-2.4.20-pa33/kernel/signal.c	2002-11-29 07:49:17.000000000 +0100
+++ linux-2.4.20-pa33-gcc33/kernel/signal.c	2003-05-06 20:01:00.000000000
+0200
@@ -126,7 +126,7 @@
 	int i;
 	struct k_sigaction *ka = &t->sig->action[0];
 	for (i = _NSIG ; i != 0 ; i--) {
-		if (ka->sa.sa_handler != SIG_IGN)
+		if (ka->sa.sa_handler != (void *)SIG_IGN)
 			ka->sa.sa_handler = SIG_DFL;
 		ka->sa.sa_flags = 0;
 		sigemptyset(&ka->sa.sa_mask);
@@ -572,7 +572,7 @@
 		return -ESRCH;
 	}
 
-	if (t->sig->action[sig-1].sa.sa_handler == SIG_IGN)
+	if (t->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN)
 		t->sig->action[sig-1].sa.sa_handler = SIG_DFL;
 	sigdelset(&t->blocked, sig);
 	recalc_sigpending(t);
@@ -1094,8 +1094,8 @@
 		 * the signal to be ignored.
 		 */
 
-		if (k->sa.sa_handler == SIG_IGN
-		    || (k->sa.sa_handler == SIG_DFL
+		if (k->sa.sa_handler == (void *)SIG_IGN
+		    || (k->sa.sa_handler == (void *)SIG_DFL
 			&& (sig == SIGCONT ||
 			    sig == SIGCHLD ||
 			    sig == SIGURG ||
diff -NaurX dontdiff linux-2.4.20-pa33/net/sunrpc/clnt.c linux-2.4.20-pa33-gcc33/net/sunrpc/clnt.c
--- linux-2.4.20-pa33/net/sunrpc/clnt.c	2003-05-06 18:03:20.000000000 +0200
+++ linux-2.4.20-pa33-gcc33/net/sunrpc/clnt.c	2003-05-06 20:01:16.000000000
+0200
@@ -209,9 +209,9 @@
 	/* Turn off various signals */
 	if (clnt->cl_intr) {
 		struct k_sigaction *action = current->sig->action;
-		if (action[SIGINT-1].sa.sa_handler == SIG_DFL)
+		if (action[SIGINT-1].sa.sa_handler == (void *)SIG_DFL)
 			sigallow |= sigmask(SIGINT);
-		if (action[SIGQUIT-1].sa.sa_handler == SIG_DFL)
+		if (action[SIGQUIT-1].sa.sa_handler == (void *)SIG_DFL)
 			sigallow |= sigmask(SIGQUIT);
 	}
 	spin_lock_irqsave(&current->sigmask_lock, irqflags);
diff -NaurX dontdiff linux-2.4.20-pa33/include/linux/compiler.h linux-2.4.20-pa33-gcc33/include/linux/compiler.h
--- linux-2.4.20-pa33/include/linux/compiler.h	2003-05-06 18:01:11.000000000
+0200
+++ linux-2.4.20-pa33-gcc33/include/linux/compiler.h	2003-05-06 18:08:56.000000000
+0200
@@ -1,6 +1,12 @@
 #ifndef __LINUX_COMPILER_H
 #define __LINUX_COMPILER_H
 
+#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
+#define inline		__inline__ __attribute__((always_inline))
+#define __inline__	__inline__ __attribute__((always_inline))
+#define __inline	__inline__ __attribute__((always_inline))
+#endif
+
 /* Somewhere in the middle of the GCC 2.96 development cycle, we implemented
    a mechanism by which the user can annotate likely branch directions and
    expect the blocks to be reordered appropriately.  Define __builtin_expect

If everybody agree is somebody could comit it (I haven't any ci cvs access
and it is better like this :)

Joel

PS: for gcc-3.2 there are still pending patch to be comitted iirc:
diff -NaurX dontdiff linux-2.4.20-pa33/include/asm-parisc/spinlock.h linux-2.4.20-pa33-gcc33/include/asm-parisc/spinlock.h
--- linux-2.4.20-pa33/include/asm-parisc/spinlock.h	2003-05-06 20:19:36.000000000
+0200
+++ linux-2.4.20-pa33-gcc33/include/asm-parisc/spinlock.h	2003-05-06 20:23:14.000000000
+0200
@@ -14,7 +14,7 @@
 	volatile int counter;
 } rwlock_t;
 
-#define RW_LOCK_UNLOCKED (rwlock_t) { SPIN_LOCK_UNLOCKED, 0 }
+#define RW_LOCK_UNLOCKED (rwlock_t) { SPIN_LOCK_UNLOCKED_INIT, 0 }
 
 #define rwlock_init(lp)	do { *(lp) = RW_LOCK_UNLOCKED; } while (0)
 
diff -NaurX dontdiff linux-2.4.20-pa33/include/asm-parisc/spinlock_t.h linux-2.4.20-pa33-gcc33/include/asm-parisc/spinlock_t.h
--- linux-2.4.20-pa33/include/asm-parisc/spinlock_t.h	2003-05-06 20:19:36.000000000
+0200
+++ linux-2.4.20-pa33-gcc33/include/asm-parisc/spinlock_t.h	2003-05-06 20:24:07.000000000
+0200
@@ -47,7 +47,9 @@
 } spinlock_t;
 
 #ifndef CONFIG_DEBUG_SPINLOCK
-#define SPIN_LOCK_UNLOCKED (spinlock_t) { 1 }
+/* This following change because of gcc-3.2 limits for C99 compilience */
+#define SPIN_LOCK_UNLOCKED_INIT { 1 }
+#define SPIN_LOCK_UNLOCKED (spinlock_t) SPIN_LOCK_UNLOCKED_INIT
 
 /* Define 6 spinlock primitives that don't depend on anything else. */
 
@@ -79,7 +81,9 @@
 
 #else
 
-#define SPIN_LOCK_UNLOCKED (spinlock_t) { 1, 0, 0 }
+/* This following change because of gcc-3.2 limits for C99 compilience */
+#define SPIN_LOCK_UNLOCKED_INIT { 1, 0L, 0L }
+#define SPIN_LOCK_UNLOCKED (spinlock_t) SPIN_LOCK_UNLOCKED_INIT
 
 /* Define 6 spinlock primitives that don't depend on anything else. */
 
 	spin_lock_irqsave(&current->sigmask_lock, irqflags);



---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Oops on 2.4.20-pa33
  2003-05-06 17:56             ` Joel Soete
@ 2003-05-07 15:48               ` Jan-Benedict Glaw
  2003-05-07 16:09                 ` Joel Soete
  2003-05-08  6:12               ` [parisc-linux] [PATCH-linux-2.5] sa_handler compare with cast Jan-Benedict Glaw
  1 sibling, 1 reply; 28+ messages in thread
From: Jan-Benedict Glaw @ 2003-05-07 15:48 UTC (permalink / raw)
  To: parisc-linux

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

On Tue, 2003-05-06 19:56:48 +0200, Joel Soete <jsoe0708@tiscali.be>
wrote in message <3EB7766A000003EE@ocpmta7.freegates.net>:
> >> +#if defined (__hppa__)
> >> +	        current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN);
> >> +#else
> >>  	        current->sig->action[sig-1].sa.sa_handler == SIG_IGN);
> >> +#endif
> >
> >You don't need to conditionalize the statement with the cast.  It should
> >work on all ports.
> >
> I trust you.
> 
> So it will finaly become:
[...]

With this patch applied (plus the diva patch I've sent to the list these
days) I can compile'n'boot:

jbglaw@b132l-1:~$ uname -a
Linux b132l-1 2.4.20-pa33 #15 Wed May 7 08:29:13 CEST 2003 parisc unknown unknown GNU/Linux

So I think it would be nice to put this patch into CVS.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Oops on 2.4.20-pa33
  2003-05-07 15:48               ` Jan-Benedict Glaw
@ 2003-05-07 16:09                 ` Joel Soete
  2003-05-07 17:17                   ` Randolph Chung
  0 siblings, 1 reply; 28+ messages in thread
From: Joel Soete @ 2003-05-07 16:09 UTC (permalink / raw)
  To: Jan-Benedict Glaw, parisc-linux

>On Tue, 2003-05-06 19:56:48 +0200, Joel Soete <jsoe0708@tiscali.be>
>wrote in message <3EB7766A000003EE@ocpmta7.freegates.net>:
>> >> +#if defined (__hppa__)
>> >> +	        current->sig->action[sig-1].sa.sa_handler == (void *)SIG_IGN);
>> >> +#else
>> >>  	        current->sig->action[sig-1].sa.sa_handler == SIG_IGN);
>> >> +#endif
>> >
>> >You don't need to conditionalize the statement with the cast.  It should
>> >work on all ports.
>> >
>> I trust you.
>> 
>> So it will finaly become:
>[...]
>
>With this patch applied (plus the diva patch I've sent to the list these
>days) I can compile'n'boot:

Thanks first for feedback.
I also have a look on your patch and it seems to me relevant.

>
>jbglaw@b132l-1:~$ uname -a
>Linux b132l-1 2.4.20-pa33 #15 Wed May 7 08:29:13 CEST 2003 parisc unknown
>unknown GNU/Linux
>
>So I think it would be nice to put this patch into CVS.
>
I hope also it will be ci but I could not help.

Thanks again,
    Joel


---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] [PATCH-2.4] DIVA serial build error (was: Oops on 2.4.20-pa33)
  2003-05-06 15:20     ` Jan-Benedict Glaw
@ 2003-05-07 16:27       ` Paul Bame
  0 siblings, 0 replies; 28+ messages in thread
From: Paul Bame @ 2003-05-07 16:27 UTC (permalink / raw)
  To: Jan-Benedict Glaw; +Cc: parisc-linux

> 
> Has anybody looked at the other patch (I sent with the mail I'm now
> replyin' to)? It was needed and seems to be correct. Is anybody to check
> it into CVS?
> 

Yes, it's correct and I'll apply it in CVS shortly.  Thanks so much!

	-P

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Oops on 2.4.20-pa33
  2003-05-07 16:09                 ` Joel Soete
@ 2003-05-07 17:17                   ` Randolph Chung
  2003-05-07 17:51                     ` Jan-Benedict Glaw
  2003-05-08  5:52                     ` Joel Soete
  0 siblings, 2 replies; 28+ messages in thread
From: Randolph Chung @ 2003-05-07 17:17 UTC (permalink / raw)
  To: Joel Soete; +Cc: Jan-Benedict Glaw, parisc-linux

> >So I think it would be nice to put this patch into CVS.
> >
> I hope also it will be ci but I could not help.

it's in 2.4.20-pa35 now.

Joel, do you think you can come up with a version that applies to 2.5 as
well?

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

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Oops on 2.4.20-pa33
  2003-05-07 17:17                   ` Randolph Chung
@ 2003-05-07 17:51                     ` Jan-Benedict Glaw
  2003-05-09  2:37                       ` Andrew Shugg
  2003-05-08  5:52                     ` Joel Soete
  1 sibling, 1 reply; 28+ messages in thread
From: Jan-Benedict Glaw @ 2003-05-07 17:51 UTC (permalink / raw)
  To: parisc-linux

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

On Wed, 2003-05-07 10:17:34 -0700, Randolph Chung <randolph@tausq.org>
wrote in message <20030507171734.GG23465@tausq.org>:
> > >So I think it would be nice to put this patch into CVS.
> > >
> > I hope also it will be ci but I could not help.
> 
> it's in 2.4.20-pa35 now.
> 
> Joel, do you think you can come up with a version that applies to 2.5 as
> well?

Thanks. This reminds me that I'd still *love* to see the CVS repository
rsync'able. That'd really help me. However, it's at least nice to be
basically able to rsync the checked-out source trees.

Any chances for a rsync for the CVS repo?

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Oops on 2.4.20-pa33
  2003-05-07 17:17                   ` Randolph Chung
  2003-05-07 17:51                     ` Jan-Benedict Glaw
@ 2003-05-08  5:52                     ` Joel Soete
  1 sibling, 0 replies; 28+ messages in thread
From: Joel Soete @ 2003-05-08  5:52 UTC (permalink / raw)
  To: Randolph Chung; +Cc: Jan-Benedict Glaw, parisc-linux

>> >So I think it would be nice to put this patch into CVS.
>> >
>> I hope also it will be ci but I could not help.
>
>it's in 2.4.20-pa35 now.
>
>Joel, do you think you can come up with a version that applies to 2.5 as
>well?
>
Well, I have not yet have time to look into 2.5 but I can try to do my best.
Just be patient: i lost my test server and I have to make place elsewhere.

Regards,
    Joel

---------------------------------
Vous surfez avec une ligne classique ?
Economisez jusqu'à 25% avec Tiscali Complete !
Offre spéciale : première année d'abonnement offerte.
... Plus d'info sur http://complete.tiscali.be

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [parisc-linux] [PATCH-linux-2.5] sa_handler compare with cast
  2003-05-06 17:56             ` Joel Soete
  2003-05-07 15:48               ` Jan-Benedict Glaw
@ 2003-05-08  6:12               ` Jan-Benedict Glaw
  1 sibling, 0 replies; 28+ messages in thread
From: Jan-Benedict Glaw @ 2003-05-08  6:12 UTC (permalink / raw)
  To: parisc-linux

[-- Attachment #1: Type: text/plain, Size: 8028 bytes --]

On Tue, 2003-05-06 19:56:48 +0200, Joel Soete <jsoe0708@tiscali.be>
wrote in message <3EB7766A000003EE@ocpmta7.freegates.net>:
> So it will finaly become:
> diff -NaurX dontdiff linux-2.4.20-pa33/arch/parisc/kernel/signal.c linux-2.4.20-pa33-gcc33/arch/parisc/kernel/signal.c
> --- linux-2.4.20-pa33/arch/parisc/kernel/signal.c	2003-05-06 17:47:32.000000000
> +0200
> +++ linux-2.4.20-pa33-gcc33/arch/parisc/kernel/signal.c	2003-05-06 18:09:35.000000000
> +0200
[...]

This is the 2.5.x version. It's _only_ the sa_handler caste, not
including the additional compiler fixes you suggested.


Index: drivers/char/n_tty.c
===================================================================
RCS file: /var/cvs/linux-2.5/drivers/char/n_tty.c,v
retrieving revision 1.8
diff -u -r1.8 n_tty.c
--- drivers/char/n_tty.c	5 May 2003 17:06:33 -0000	1.8
+++ drivers/char/n_tty.c	8 May 2003 06:08:38 -0000
@@ -808,7 +808,8 @@
 int is_ignored(int sig)
 {
 	return (sigismember(&current->blocked, sig) ||
-	        current->sighand->action[sig-1].sa.sa_handler == SIG_IGN);
+	        current->sighand->action[sig-1].sa.sa_handler
+				== (void *)SIG_IGN);
 }
 
 static void n_tty_set_termios(struct tty_struct *tty, struct termios * old)
Index: fs/ncpfs/sock.c
===================================================================
RCS file: /var/cvs/linux-2.5/fs/ncpfs/sock.c,v
retrieving revision 1.6
diff -u -r1.6 sock.c
--- fs/ncpfs/sock.c	15 Feb 2003 03:48:26 -0000	1.6
+++ fs/ncpfs/sock.c	8 May 2003 06:08:39 -0000
@@ -757,9 +757,9 @@
 			   What if we've blocked it ourselves?  What about
 			   alarms?  Why, in fact, are we mucking with the
 			   sigmask at all? -- r~ */
-			if (current->sighand->action[SIGINT - 1].sa.sa_handler == SIG_DFL)
+			if (current->sighand->action[SIGINT - 1].sa.sa_handler == (void *)SIG_DFL)
 				mask |= sigmask(SIGINT);
-			if (current->sighand->action[SIGQUIT - 1].sa.sa_handler == SIG_DFL)
+			if (current->sighand->action[SIGQUIT - 1].sa.sa_handler == (void *)SIG_DFL)
 				mask |= sigmask(SIGQUIT);
 		}
 		siginitsetinv(&current->blocked, mask);
Index: fs/proc/array.c
===================================================================
RCS file: /var/cvs/linux-2.5/fs/proc/array.c,v
retrieving revision 1.15
diff -u -r1.15 array.c
--- fs/proc/array.c	5 May 2003 17:08:54 -0000	1.15
+++ fs/proc/array.c	8 May 2003 06:08:40 -0000
@@ -213,9 +213,9 @@
 
 	k = p->sighand->action;
 	for (i = 1; i <= _NSIG; ++i, ++k) {
-		if (k->sa.sa_handler == SIG_IGN)
+		if (k->sa.sa_handler == (void *)SIG_IGN)
 			sigaddset(ign, i);
-		else if (k->sa.sa_handler != SIG_DFL)
+		else if (k->sa.sa_handler != (void *)SIG_DFL)
 			sigaddset(catch, i);
 	}
 }
Index: kernel/signal.c
===================================================================
RCS file: /var/cvs/linux-2.5/kernel/signal.c,v
retrieving revision 1.19
diff -u -r1.19 signal.c
--- kernel/signal.c	24 Apr 2003 01:38:05 -0000	1.19
+++ kernel/signal.c	8 May 2003 06:08:42 -0000
@@ -144,12 +144,12 @@
 		(((sig) < SIGRTMIN)  && T(sig, SIG_KERNEL_STOP_MASK))
 
 #define sig_user_defined(t, signr) \
-	(((t)->sighand->action[(signr)-1].sa.sa_handler != SIG_DFL) &&	\
-	 ((t)->sighand->action[(signr)-1].sa.sa_handler != SIG_IGN))
+	(((t)->sighand->action[(signr)-1].sa.sa_handler != (void *)SIG_DFL) &&	\
+	 ((t)->sighand->action[(signr)-1].sa.sa_handler != (void *)SIG_IGN))
 
 #define sig_fatal(t, signr) \
 	(!T(signr, SIG_KERNEL_IGNORE_MASK|SIG_KERNEL_STOP_MASK) && \
-	 (t)->sighand->action[(signr)-1].sa.sa_handler == SIG_DFL)
+	 (t)->sighand->action[(signr)-1].sa.sa_handler == (void *)SIG_DFL)
 
 static inline int sig_ignored(struct task_struct *t, int sig)
 {
@@ -171,8 +171,8 @@
 
 	/* Is it explicitly or implicitly ignored? */
 	handler = t->sighand->action[sig-1].sa.sa_handler;
-	return   handler == SIG_IGN ||
-		(handler == SIG_DFL && sig_kernel_ignore(sig));
+	return   handler == (void *)SIG_IGN ||
+		(handler == (void *)SIG_DFL && sig_kernel_ignore(sig));
 }
 
 /*
@@ -366,7 +366,7 @@
 	int i;
 	struct k_sigaction *ka = &t->sighand->action[0];
 	for (i = _NSIG ; i != 0 ; i--) {
-		if (force_default || ka->sa.sa_handler != SIG_IGN)
+		if (force_default || ka->sa.sa_handler != (void *)SIG_IGN)
 			ka->sa.sa_handler = SIG_DFL;
 		ka->sa.sa_flags = 0;
 		sigemptyset(&ka->sa.sa_mask);
@@ -801,7 +801,7 @@
 	int ret;
 
 	spin_lock_irqsave(&t->sighand->siglock, flags);
-	if (t->sighand->action[sig-1].sa.sa_handler == SIG_IGN)
+	if (t->sighand->action[sig-1].sa.sa_handler == (void *)SIG_IGN)
 		t->sighand->action[sig-1].sa.sa_handler = SIG_DFL;
 	sigdelset(&t->blocked, sig);
 	recalc_sigpending_tsk(t);
@@ -817,7 +817,7 @@
 	unsigned long int flags;
 
 	spin_lock_irqsave(&t->sighand->siglock, flags);
-	if (t->sighand->action[sig-1].sa.sa_handler == SIG_IGN)
+	if (t->sighand->action[sig-1].sa.sa_handler == (void *)SIG_IGN)
 		t->sighand->action[sig-1].sa.sa_handler = SIG_DFL;
 	sigdelset(&t->blocked, sig);
 	recalc_sigpending_tsk(t);
@@ -1281,7 +1281,7 @@
 	psig = tsk->parent->sighand;
 	spin_lock_irqsave(&psig->siglock, flags);
 	if (sig == SIGCHLD && tsk->state != TASK_STOPPED &&
-	    (psig->action[SIGCHLD-1].sa.sa_handler == SIG_IGN ||
+	    (psig->action[SIGCHLD-1].sa.sa_handler == (void *)SIG_IGN ||
 	     (psig->action[SIGCHLD-1].sa.sa_flags & SA_NOCLDWAIT))) {
 		/*
 		 * We are exiting and our parent doesn't care.  POSIX.1
@@ -1299,7 +1299,7 @@
 		 * it, just use SIG_IGN instead).
 		 */
 		tsk->exit_signal = -1;
-		if (psig->action[SIGCHLD-1].sa.sa_handler == SIG_IGN)
+		if (psig->action[SIGCHLD-1].sa.sa_handler == (void *)SIG_IGN)
 			sig = 0;
 	}
 	if (sig > 0 && sig <= _NSIG)
@@ -1347,7 +1347,7 @@
 
 	sighand = parent->sighand;
 	spin_lock_irqsave(&sighand->siglock, flags);
-	if (sighand->action[SIGCHLD-1].sa.sa_handler != SIG_IGN &&
+	if (sighand->action[SIGCHLD-1].sa.sa_handler != (void *)SIG_IGN &&
 	    !(sighand->action[SIGCHLD-1].sa.sa_flags & SA_NOCLDSTOP))
 		__group_send_sig_info(SIGCHLD, &info, parent);
 	/*
@@ -1581,9 +1581,9 @@
 		}
 
 		ka = &current->sighand->action[signr-1];
-		if (ka->sa.sa_handler == SIG_IGN) /* Do nothing.  */
+		if (ka->sa.sa_handler == (void *)SIG_IGN) /* Do nothing.  */
 			continue;
-		if (ka->sa.sa_handler != SIG_DFL) /* Run the handler.  */
+		if (ka->sa.sa_handler != (void *)SIG_DFL) /* Run the handler.  */
 			return signr;
 
 		/*
@@ -2034,8 +2034,8 @@
 		 *   (for example, SIGCHLD), shall cause the pending signal to
 		 *   be discarded, whether or not it is blocked"
 		 */
-		if (act->sa.sa_handler == SIG_IGN ||
-		    (act->sa.sa_handler == SIG_DFL &&
+		if (act->sa.sa_handler == (void *)SIG_IGN ||
+		    (act->sa.sa_handler == (void *)SIG_DFL &&
 		     sig_kernel_ignore(sig))) {
 			/*
 			 * This is a fairly rare case, so we only take the
Index: net/sunrpc/clnt.c
===================================================================
RCS file: /var/cvs/linux-2.5/net/sunrpc/clnt.c,v
retrieving revision 1.12
diff -u -r1.12 clnt.c
--- net/sunrpc/clnt.c	8 Apr 2003 15:21:04 -0000	1.12
+++ net/sunrpc/clnt.c	8 May 2003 06:08:44 -0000
@@ -255,9 +255,9 @@
 	/* Turn off various signals */
 	if (clnt->cl_intr) {
 		struct k_sigaction *action = current->sighand->action;
-		if (action[SIGINT-1].sa.sa_handler == SIG_DFL)
+		if (action[SIGINT-1].sa.sa_handler == (void *)SIG_DFL)
 			sigallow |= sigmask(SIGINT);
-		if (action[SIGQUIT-1].sa.sa_handler == SIG_DFL)
+		if (action[SIGQUIT-1].sa.sa_handler == (void *)SIG_DFL)
 			sigallow |= sigmask(SIGQUIT);
 	}
 	spin_lock_irqsave(&current->sighand->siglock, irqflags);



MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Oops on 2.4.20-pa33
  2003-05-07 17:51                     ` Jan-Benedict Glaw
@ 2003-05-09  2:37                       ` Andrew Shugg
  2003-05-09 22:04                         ` Jan-Benedict Glaw
  0 siblings, 1 reply; 28+ messages in thread
From: Andrew Shugg @ 2003-05-09  2:37 UTC (permalink / raw)
  To: parisc-linux

Jan-Benedict Glaw said:
> Thanks. This reminds me that I'd still *love* to see the CVS repository
> rsync'able. That'd really help me. However, it's at least nice to be
> basically able to rsync the checked-out source trees.
> 
> Any chances for a rsync for the CVS repo?
> 
> MfG, JBG

I'm not sure why you'd want to be able to rsync the entire repository,
unless you want to be able to track multiple branches of a module
without having to have a full checkout of each one?  That would make
more sense I guess, if you live in a world where the Internet is slow
and bandwidth is not free (I live there too, small world!).

There is already an rsync server running on ftp.parisc-linux.org, but I
don't believe it's widely advertised.

I just ran an 'rsync -va ftp.parisc-linux.org.au::pub' (the only rsync
'module' available) and the output was 14M!  Presumably this caused a
fair bit of thrashing at f.p-l.o's end as well ...

If you'd like to see what's available by rsync, I've compressed that
listing and uploaded it here.

ftp://ftp.neep.com.au/pub/parisc-linux/ftp.parisc-linux.org-rsync.txt.bz2

I'll have a trundle through it myself today, to see if I can write a
helpful motd for rsyncd and suggest how the ::pub module can be split up
into more useful bits.  (Bame, may I assume that you're still nominally
in charge of the rsyncd server?)

Andrew.

-- 
Andrew Shugg <andrew@neep.com.au>                   http://www.neep.com.au/

"Just remember, Mr Fawlty, there's always someone worse off than yourself."
"Is there?  Well I'd like to meet him.  I could do with a good laugh."

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Oops on 2.4.20-pa33
  2003-05-09  2:37                       ` Andrew Shugg
@ 2003-05-09 22:04                         ` Jan-Benedict Glaw
  0 siblings, 0 replies; 28+ messages in thread
From: Jan-Benedict Glaw @ 2003-05-09 22:04 UTC (permalink / raw)
  To: parisc-linux

[-- Attachment #1: Type: text/plain, Size: 1720 bytes --]

On Fri, 2003-05-09 10:37:47 +0800, Andrew Shugg <andrew@neep.com.au>
wrote in message <20030509103745.H20047@neep.com.au>:
> Jan-Benedict Glaw said:
> > Thanks. This reminds me that I'd still *love* to see the CVS repository
> > rsync'able. That'd really help me. However, it's at least nice to be
> > basically able to rsync the checked-out source trees.
> > 
> > Any chances for a rsync for the CVS repo?
> > 
> > MfG, JBG
> 
> I'm not sure why you'd want to be able to rsync the entire repository,
> unless you want to be able to track multiple branches of a module
> without having to have a full checkout of each one?  That would make
> more sense I guess, if you live in a world where the Internet is slow
> and bandwidth is not free (I live there too, small world!).

It's even good for looking at older revisions of files without being
online.

> There is already an rsync server running on ftp.parisc-linux.org, but I
> don't believe it's widely advertised.

I do already use it.

> I'll have a trundle through it myself today, to see if I can write a
> helpful motd for rsyncd and suggest how the ::pub module can be split up
> into more useful bits.  (Bame, may I assume that you're still nominally
> in charge of the rsyncd server?)

The "pub" module is nice as it is just right now, but I'd love to see
the CVS repository directory (/var/cvs ?) also there:)

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' pb
  2003-05-10 20:31             ` [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' pb Joel Soete
@ 2003-05-10 20:25               ` Jan-Benedict Glaw
  2003-05-10 21:08               ` Grant Grundler
  2003-05-10 21:21               ` [parisc-linux] Re: Yet another '__canonicalize_funcptr_for_compare' pb John David Anglin
  2 siblings, 0 replies; 28+ messages in thread
From: Jan-Benedict Glaw @ 2003-05-10 20:25 UTC (permalink / raw)
  To: parisc-linux

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

On Sat, 2003-05-10 20:31:33 +0000, Joel Soete <joel.soete@tiscali.be>
wrote in message <3EBD61A5.8030205@tiscali.be>:
> 
> The kernel seems to compiles well without err but it failled to build 
> some module again because of '__canonicalize_funcptr_for_compare' needed 
> in tun.o under drivers/net.

This leads me to ask: How do I localize wrong pointer compares?
Compiling 2.5.x with mostly everything compiled as module unhides quite
some modules with suffer from this problem. So is there any simple way
finding out at which address a call to
__canonicalize_funcptr_for_compare happens so that I can localize the
code line?

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' pb
  2003-05-06 16:42           ` John David Anglin
  2003-05-06 17:56             ` Joel Soete
@ 2003-05-10 20:31             ` Joel Soete
  2003-05-10 20:25               ` Jan-Benedict Glaw
                                 ` (2 more replies)
  1 sibling, 3 replies; 28+ messages in thread
From: Joel Soete @ 2003-05-10 20:31 UTC (permalink / raw)
  To: John David Anglin; +Cc: randolph, parisc-linux

Hi Dave,

Atfer I reach to recover some kind of b2k test system I reach to grab 
2.4.21-rc2-pa35 and try to compile it with gcc-3.2 (debian 3.2.3-2 iirc)

The kernel seems to compiles well without err but it failled to build 
some module again because of '__canonicalize_funcptr_for_compare' needed 
in tun.o under drivers/net.

I read first the pre-asm code to try to locate pb and figure out that it 
was in tun_set_iff() near begining:
tun.c
...
static int tun_set_iff(struct file *file, struct ifreq *ifr)
{
        struct tun_struct *tun;
        struct net_device *dev;
        int err;

        dev = __dev_get_by_name(ifr->ifr_name);
        if (dev) {
                /* Device exist */
                tun = dev->priv;

                if (dev->init != tun_net_init || tun->attached)
                        return -EBUSY;

                /* Check permissions */
...

I suspect first if(dev) because dev is a pointer to a struct but finaly 
it is in "if (dev->init != tun_net_init..." which would become "if 
(dev->init != (void*)tun_net_init...".

Is it the right workaround? fixe?

I have another stupid question: as hppa seems to be the only platform 
requiring this stuff and I don't see how to check all src to track this 
pb (practicaly only try and chess?), how much would it be difficult to 
implement this __canonicalize_funcptr_for_compare into the hppa lib kernel?

Thanks in advance for advise,
    Joel

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' pb
  2003-05-10 20:31             ` [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' pb Joel Soete
  2003-05-10 20:25               ` Jan-Benedict Glaw
@ 2003-05-10 21:08               ` Grant Grundler
  2003-05-10 21:32                 ` John David Anglin
  2003-05-10 21:33                 ` Joel Soete
  2003-05-10 21:21               ` [parisc-linux] Re: Yet another '__canonicalize_funcptr_for_compare' pb John David Anglin
  2 siblings, 2 replies; 28+ messages in thread
From: Grant Grundler @ 2003-05-10 21:08 UTC (permalink / raw)
  To: Joel Soete; +Cc: John David Anglin, randolph, parisc-linux

On Sat, May 10, 2003 at 08:31:33PM +0000, Joel Soete wrote:
> I have another stupid question: as hppa seems to be the only platform 
> requiring this stuff

ia64 and a few others have similar 64-bit function pointers.
This issue has resurfaced on parisc-linux and ia64-linux mailing
list regularly.  (2 or 3 times per year).

grant

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [parisc-linux] Re: Yet another '__canonicalize_funcptr_for_compare' pb
  2003-05-10 20:31             ` [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' pb Joel Soete
  2003-05-10 20:25               ` Jan-Benedict Glaw
  2003-05-10 21:08               ` Grant Grundler
@ 2003-05-10 21:21               ` John David Anglin
  2 siblings, 0 replies; 28+ messages in thread
From: John David Anglin @ 2003-05-10 21:21 UTC (permalink / raw)
  To: Joel Soete; +Cc: randolph, parisc-linux

>         dev = __dev_get_by_name(ifr->ifr_name);
>         if (dev) {
>                 /* Device exist */
>                 tun = dev->priv;
> 
>                 if (dev->init != tun_net_init || tun->attached)
>                         return -EBUSY;
> 
>                 /* Check permissions */
> ...
> 
> I suspect first if(dev) because dev is a pointer to a struct but finaly 
> it is in "if (dev->init != tun_net_init..." which would become "if 
> (dev->init != (void*)tun_net_init...".

__canonicalize_funcptr_for_compare is only used in comparisons involving
function pointers.

> Is it the right workaround? fixe?

Probably.  There are some tricky issues with respect to loadable
kernel modules.

> I have another stupid question: as hppa seems to be the only platform 
> requiring this stuff and I don't see how to check all src to track this 
> pb (practicaly only try and chess?), how much would it be difficult to 
> implement this __canonicalize_funcptr_for_compare into the hppa lib kernel?

You can tell if a kernel or module uses __canonicalize_funcptr_for_compare
with nm.  If you find it's used somewhere, check each object module for
it.  You can find the code location of it with "objdump -d".  This will
give a pretty good idea where in the source the comparison occurs.

As to a kernel implementation, this is hard.  If the function pointer
is in user space, canonicalization requires a bunch of tests and then
a call to code in the dynamic loader in the user program.

As far as function pointers in the kernel address space, this would
take some research.  Direct comparison (i.e., using "void *" casts)
will work ok as long as the pointer either points directly to the
kernel function involved or unique plabels are used.  If all
kernel function addresses get bound immediately when a module
is loaded, this would simplify the situation and the canonicalization
could be done simply by looking at the function address in the plabel.
The exact details depend on how the kernel and modules are linked.

The reason why function pointer canonicalization is needed on the
pa is that there can be several plabels pointing to the same function
a user program.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' pb
  2003-05-10 21:08               ` Grant Grundler
@ 2003-05-10 21:32                 ` John David Anglin
  2003-05-10 21:33                 ` Joel Soete
  1 sibling, 0 replies; 28+ messages in thread
From: John David Anglin @ 2003-05-10 21:32 UTC (permalink / raw)
  To: Grant Grundler; +Cc: joel.soete, randolph, parisc-linux

> On Sat, May 10, 2003 at 08:31:33PM +0000, Joel Soete wrote:
> > I have another stupid question: as hppa seems to be the only platform 
> > requiring this stuff
> 
> ia64 and a few others have similar 64-bit function pointers.
> This issue has resurfaced on parisc-linux and ia64-linux mailing
> list regularly.  (2 or 3 times per year).

The ia64 situation differs from the parisc situation in that all
calls are made using function descriptors and the descriptors are
unique.  As a result, it is sufficient to simply compare the function
pointers.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' pb
  2003-05-10 21:08               ` Grant Grundler
  2003-05-10 21:32                 ` John David Anglin
@ 2003-05-10 21:33                 ` Joel Soete
  2003-05-10 21:38                   ` [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' John David Anglin
  1 sibling, 1 reply; 28+ messages in thread
From: Joel Soete @ 2003-05-10 21:33 UTC (permalink / raw)
  To: Grant Grundler; +Cc: John David Anglin, randolph, parisc-linux

Grant Grundler wrote:

>On Sat, May 10, 2003 at 08:31:33PM +0000, Joel Soete wrote:
>  
>
>>I have another stupid question: as hppa seems to be the only platform 
>>requiring this stuff
>>    
>>
>
>ia64 and a few others have similar 64-bit function pointers.
>
Sorry I forget to mentioned that I compiling a 32-bits hppa kernel. Does 
it make diffrence?

Joel

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [parisc-linux] Yet another '__canonicalize_funcptr_for_compare'
  2003-05-10 21:33                 ` Joel Soete
@ 2003-05-10 21:38                   ` John David Anglin
  0 siblings, 0 replies; 28+ messages in thread
From: John David Anglin @ 2003-05-10 21:38 UTC (permalink / raw)
  To: Joel Soete; +Cc: grundler, randolph, parisc-linux

> Sorry I forget to mentioned that I compiling a 32-bits hppa kernel. Does 
> it make diffrence?

Yes.  Function pointer canonicalization is only done on the 32-bit
port.  This is not to say that there aren't issues with 64-bit kernels
in this area, particularly if you use loadable modules.  The 64-bit
code assumes that there is an official procedure descriptor (OPD)
for each function.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2003-05-10 21:39 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-05-05 20:02 [parisc-linux] Oops on 2.4.20-pa33 Jan-Benedict Glaw
2003-05-05 20:05 ` Randolph Chung
2003-05-05 21:05   ` [parisc-linux] [PATCH-2.4] DIVA serial build error (was: Oops on 2.4.20-pa33) Jan-Benedict Glaw
2003-05-06 15:20     ` Jan-Benedict Glaw
2003-05-07 16:27       ` Paul Bame
2003-05-06  6:04   ` [parisc-linux] Oops on 2.4.20-pa33 Joel Soete
2003-05-06 14:04     ` Randolph Chung
2003-05-06 15:04       ` Joel Soete
2003-05-06 15:08         ` Randolph Chung
2003-05-06 16:34         ` Joel Soete
2003-05-06 16:42           ` John David Anglin
2003-05-06 17:56             ` Joel Soete
2003-05-07 15:48               ` Jan-Benedict Glaw
2003-05-07 16:09                 ` Joel Soete
2003-05-07 17:17                   ` Randolph Chung
2003-05-07 17:51                     ` Jan-Benedict Glaw
2003-05-09  2:37                       ` Andrew Shugg
2003-05-09 22:04                         ` Jan-Benedict Glaw
2003-05-08  5:52                     ` Joel Soete
2003-05-08  6:12               ` [parisc-linux] [PATCH-linux-2.5] sa_handler compare with cast Jan-Benedict Glaw
2003-05-10 20:31             ` [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' pb Joel Soete
2003-05-10 20:25               ` Jan-Benedict Glaw
2003-05-10 21:08               ` Grant Grundler
2003-05-10 21:32                 ` John David Anglin
2003-05-10 21:33                 ` Joel Soete
2003-05-10 21:38                   ` [parisc-linux] Yet another '__canonicalize_funcptr_for_compare' John David Anglin
2003-05-10 21:21               ` [parisc-linux] Re: Yet another '__canonicalize_funcptr_for_compare' pb John David Anglin
2003-05-05 20:10 ` [parisc-linux] Oops on 2.4.20-pa33 John David Anglin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.