[parisc-linux] pthread problems - test program

[parisc-linux] pthread problems - test program

[Randolph Chung]

While testing out some stuff today, I ran across a threaded
program that will hang randomly when run. I tried to create a test case
to simulate what the larger program is doing. It also hangs, although
perhaps for different reasons (not sure yet)

The test program is in cvs in the userspace repository. It's called
thread_test2.c. It creates threads one at a time, and uses condition
variables for synchronization. On hppa the program will hang after some
time, and ps shows a lot of zombie processes. On x86 the program runs as
expected and there are no zombies.

I don't know if this is related to some of the hanging problems Dave and
doko have seen sometimes during gcc testing.... but our pthreads
definitely seem to be a bit buggy :(

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

> I don't know if this is related to some of the hanging problems Dave and
> doko have seen sometimes during gcc testing.... but our pthreads
> definitely seem to be a bit buggy :(

I was going to add Ada tasking to the list of pthread problems but
I just discovered that Ada hard codes signal numbers for linux and
some of our signal numbers are different from those used on x86.

I believe that our Java testsuite fails are probably pthread related.
I sometimes end up with Java programs that don't die when their
respective test completes.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

> The test program is in cvs in the userspace repository. It's called
> thread_test2.c. It creates threads one at a time, and uses condition
> variables for synchronization. On hppa the program will hang after some
> time, and ps shows a lot of zombie processes. On x86 the program runs as
> expected and there are no zombies.

I see threadfunc uses waitpid.  This is the same syscall that seems
to cause problems with expect (zombie expect child and parent waiting
for signal that never comes).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Randolph Chung]

In reference to a message from John David Anglin, dated Apr 03:
> > The test program is in cvs in the userspace repository. It's called
> > thread_test2.c. It creates threads one at a time, and uses condition
> > variables for synchronization. On hppa the program will hang after some
> > time, and ps shows a lot of zombie processes. On x86 the program runs as
> > expected and there are no zombies.
> 
> I see threadfunc uses waitpid.  This is the same syscall that seems
> to cause problems with expect (zombie expect child and parent waiting
> for signal that never comes).

This is very similar to what happens with my test program.

Running this under gdb is kind of amusing. gdb gets quite confused...

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

> The test program is in cvs in the userspace repository. It's called
> thread_test2.c. It creates threads one at a time, and uses condition
> variables for synchronization. On hppa the program will hang after some
> time, and ps shows a lot of zombie processes. On x86 the program runs as
> expected and there are no zombies.

What's the situation on the following signals: SIGLTHRRES, SIGLTHRCAN
and SIGLTHRDBG?  I'm not sure but pthread_cond_signal may need SIGLTHRRES.
Are these signals 37, 38 and 39?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Randolph Chung]

> What's the situation on the following signals: SIGLTHRRES, SIGLTHRCAN
> and SIGLTHRDBG?  I'm not sure but pthread_cond_signal may need SIGLTHRRES.
> Are these signals 37, 38 and 39?

yes, we use the same signals. 

int __pthread_sig_restart = __SIGRTMIN;
int __pthread_sig_cancel = __SIGRTMIN + 1;
int __pthread_sig_debug = __SIGRTMIN + 2;

SIGRTMIN is 37

i think we can reduce the test to a signals test. if you strace the test
program you will see that it's doing a loop of sigprocmask(),
sigsuspend(), wake up by signal, etc.... that may make a test case a bit
simpler.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Carlos O'Donell]

On Sun, Apr 03, 2005 at 05:50:38PM -0700, Randolph Chung wrote:
> > What's the situation on the following signals: SIGLTHRRES, SIGLTHRCAN
> > and SIGLTHRDBG?  I'm not sure but pthread_cond_signal may need SIGLTHRRES.
> > Are these signals 37, 38 and 39?
> 
> yes, we use the same signals. 
> 
> int __pthread_sig_restart = __SIGRTMIN;
> int __pthread_sig_cancel = __SIGRTMIN + 1;
> int __pthread_sig_debug = __SIGRTMIN + 2;
> 
> SIGRTMIN is 37
> 
> i think we can reduce the test to a signals test. if you strace the test
> program you will see that it's doing a loop of sigprocmask(),
> sigsuspend(), wake up by signal, etc.... that may make a test case a bit
> simpler.

It irks me that such a simple program doesn't run properly :(
I've started digging into the code, and I'm going to add some signal
printk's to see what we're missing.

c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Carlos O'Donell]

On Sun, Apr 03, 2005 at 05:50:38PM -0700, Randolph Chung wrote:
> i think we can reduce the test to a signals test. if you strace the test
> program you will see that it's doing a loop of sigprocmask(),
> sigsuspend(), wake up by signal, etc.... that may make a test case a bit
> simpler.

Agreed. It looks like sigsuspend just isn't returning and looping
forever in the kernel.

c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Carlos O'Donell]

On Mon, Apr 04, 2005 at 08:02:34PM -0400, Carlos O'Donell wrote:
> On Sun, Apr 03, 2005 at 05:50:38PM -0700, Randolph Chung wrote:
> > i think we can reduce the test to a signals test. if you strace the test
> > program you will see that it's doing a loop of sigprocmask(),
> > sigsuspend(), wake up by signal, etc.... that may make a test case a bit
> > simpler.
> 
> Agreed. It looks like sigsuspend just isn't returning and looping
> forever in the kernel.

I found another program that doesn't work on hppa. This one was written
by Randolph if my memory serves me correctly. I'll have to add it to the
userspace tests that fail.

---
all: foo.c libfoo.c
	gcc -g -shared -c libfoo.c
	rm -f libfoo.so
	ln -s libfoo.o libfoo.so
	gcc -g -o foo foo.c -lfoo -L. -lpthread

clean:
	rm -f *.o
	rm -f *.so
	rm -f foo
---
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>

void exit_on_signal(int signr)
{
  int status;
  pid_t child;
  fprintf(stderr, "Exiting on signal from child\n");
  child = wait(&status);
  fprintf(stderr, "Waited for child %d\n",(int)child);
  exit(0);
}

extern void foo(void);

int main(void)
{
  int status;
/*  foo();*/
  signal(SIGUSR2,exit_on_signal);
  pid_t parent = getpid();
  if (fork() == 0) 
    {
      /* child kills parent */
      kill(parent, SIGUSR2);
    } 
  else 
    {
      printf("Parent done.\n");
    }
  return 0;
}
---
#include <pthread.h>

void
do_prepare(void)
{
	printf("do_prepare\n");
}

void
do_child(void)
{
	printf("do_child\n");
}

void
foo(void)
{
	  pthread_atfork(&do_prepare, NULL, &do_child);
}
---

Try it out.

c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

> I found another program that doesn't work on hppa. This one was written
> by Randolph if my memory serves me correctly. I'll have to add it to the
> userspace tests that fail.
> 
> ---
> all: foo.c libfoo.c
> 	gcc -g -shared -c libfoo.c
> 	rm -f libfoo.so
> 	ln -s libfoo.o libfoo.so
> 	gcc -g -o foo foo.c -lfoo -L. -lpthread
> 
> clean:
> 	rm -f *.o
> 	rm -f *.so
> 	rm -f foo

The test can be simplified.  You don't need libfoo.  Just
link foo with -lpthread and it fails.

I see libtcl8.4 is linked against libpthread.so.  This is probably
why 8.3 works better than 8.4.

dave@hiauly6:~/gcc_test/pthr/carlos$ ./foo
Parent = 24778
Exiting on signal from child
Waited for child 24779
Quit (core dumped)

(gdb) bt
#0  __unregister_atfork (dso_handle=0x40184b58)
    at ../linuxthreads/sysdeps/unix/sysv/linux/unregister-atfork.c:28
#1  0x4016ede0 in __pthread_wait_for_restart_signal (self=0x40184b80)
    at pthread.c:1203
#2  0x405e41b8 in _IO_default_xsputn (f=0xbff00b94, data=0x8, n=3220179872)
    at genops.c:477
#3  0x00000000 in ?? ()
    ...

Running under gdb:

dave@hiauly6:~/gcc_test/pthr/carlos$ /usr/bin/gdb foo
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "hppa-linux"...Using host libthread_db library "/usr/lib/debug/libthread_db.so.1".

(gdb) handle SIGUSR2 noprint nostop pass
Signal        Stop      Print   Pass to program Description
SIGUSR2       No        No      Yes             User defined signal 2
(gdb) r
Starting program: /home/dave/gcc_test/pthr/carlos/foo
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 24875)]
Parent = 24875
Exiting on signal from child
Waited for child 24878

Program received signal SIGINT, Interrupt.
[Switching to Thread 16384 (LWP 24875)]
0x4016f05c in __pthread_sigsuspend (set=0xbff00dc8)
    at ../linuxthreads/sysdeps/unix/sysv/linux/pt-sigsuspend.c:54
    54      ../linuxthreads/sysdeps/unix/sysv/linux/pt-sigsuspend.c: No such file or directory.
	    in ../linuxthreads/sysdeps/unix/sysv/linux/pt-sigsuspend.c
(gdb) bt
#0  0x4016f05c in __pthread_sigsuspend (set=0xbff00dc8)
    at ../linuxthreads/sysdeps/unix/sysv/linux/pt-sigsuspend.c:54
#1  0x4016ede0 in __pthread_wait_for_restart_signal (self=0x40184b80)
    at pthread.c:1203
#2  0x4017081c in __pthread_alt_lock (lock=0x406c2980, self=0x40184b80)
    at restart.h:34
#3  0x4016d480 in *__GI___pthread_mutex_lock (mutex=0x406c2970) at mutex.c:123
#4  0x40662234 in __unregister_atfork (dso_handle=0x40184ac0) at list.h:72
#5  0x4016a930 in __do_global_dtors_aux () from /usr/lib/debug/libpthread.so.0
#6  0x40173bb0 in _fini () from /usr/lib/debug/libpthread.so.0
#7  0x400b6898 in _dl_fini () from /lib/ld.so.1
#8  0x400b6898 in _dl_fini () from /lib/ld.so.1
Previous frame identical to this frame (corrupt stack?)
(gdb) disass 0x4016f04c 0x4016f06c
Dump of assembler code from 0x4016f04c to 0x4016f06c:
0x4016f04c <__pthread_sigsuspend+12>:   ldi 8,r25
0x4016f050 <__pthread_sigsuspend+16>:   copy r19,r4
0x4016f054 <__pthread_sigsuspend+20>:   be,l 100(sr2,r0),%sr0,%r31
0x4016f058 <__pthread_sigsuspend+24>:   ldi b3,r20
0x4016f05c <__pthread_sigsuspend+28>:   copy r4,r19
0x4016f060 <__pthread_sigsuspend+32>:   ldw -54(,sp),rp
0x4016f064 <__pthread_sigsuspend+36>:   bv r0(rp)
0x4016f068 <__pthread_sigsuspend+40>:   ldw,mb -40(,sp),r4

The program always appears stuck at 0x4016f05c, so I assume that
the syscall at 0x4016f054 is hung.  There is definitely a timing
issue involved since the program doesn't fail if I don't tell gdb
how to handle SIGUSR2.  I added the parent printout.

(gdb) disass __pthread_sigsuspend
Dump of assembler code for function __pthread_sigsuspend:
0x4016f040 <__pthread_sigsuspend+0>:    stw rp,-14(,sp)
0x4016f044 <__pthread_sigsuspend+4>:    stw,ma r4,40(,sp)
0x4016f048 <__pthread_sigsuspend+8>:    stw r19,-20(,sp)
0x4016f04c <__pthread_sigsuspend+12>:   ldi 8,r25
0x4016f050 <__pthread_sigsuspend+16>:   copy r19,r4
0x4016f054 <__pthread_sigsuspend+20>:   be,l 100(sr2,r0),%sr0,%r31
0x4016f058 <__pthread_sigsuspend+24>:   ldi b3,r20
0x4016f05c <__pthread_sigsuspend+28>:   copy r4,r19
0x4016f060 <__pthread_sigsuspend+32>:   ldw -54(,sp),rp
0x4016f064 <__pthread_sigsuspend+36>:   bv r0(rp)
0x4016f068 <__pthread_sigsuspend+40>:   ldw,mb -40(,sp),r4
End of assembler dump.
(gdb) info reg
flags          0x0      0
r1             0x40661ee7       1080434407
rp             0x4016ede3       1075244515
r3             0x40184b58       1075333976
r4             0x40185c28       1075338280
r5             0x40184b80       1075334016
r6             0x40000328       1073742632
r7             0xbff00bd4       3220179924
r8             0xbff00be0       3220179936
r9             0x1      1
r10            0xbff00bd8       3220179928
r11            0x400bf354       1074525012
r12            0x400d04b8       1074595000
r13            0x2      2
r14            0x400d0d70       1074597232
r15            0xbff00bd8       3220179928
r16            0x400d0724       1074595620
r17            0xbff00bd4       3220179924
r18            0x0      0
r19            0x40185c28       1075338280
r20            0xb3     179
r21            0x1b     27
r22            0xbff00dcc       3220180428
---Type <return> to continue, or q <return> to quit---
r23            0x0      0
r24            0xbff00dc8       3220180424
r25            0x8      8
r26            0xbff00dc8       3220180424
dp             0x20e84  134788
ret0           0xfffffffc       4294967292
ret1           0x37d    893
sp             0xbff00f00       3220180736
r31            0x4016f05f       1075245151
sar            0x1b     27
pcoqh          0x4016f05f       1075245151
pcsqh          0x0      0
pcoqt          0x4016f063       1075245155
pcsqt          0x0      0
eiem           0x0      0
iir            0x0      0
isr            0x0      0
ior            0x0      0
ipsw           0xb      11
goto           0x0      0
sr4            0x0      0
sr0            0x0      0
sr1            0x0      0
---Type <return> to continue, or q <return> to quit---
sr2            0x0      0
sr3            0x0      0
sr5            0x0      0
sr6            0x0      0
sr7            0x0      0
cr0            0x0      0
cr8            0x0      0
cr9            0x0      0
ccr            0x0      0
cr12           0x0      0
cr13           0x0      0
cr24           0x0      0
cr25           0x0      0
cr26           0x0      0
mpsfu_high     0x0      0
mpsfu_low      0x0      0
mpsfu_ovflo    0x0      0
pad            0x0      0
fpsr           0x0      0
fpe1           0x0      0
fpe2           0x0      0
fpe3           0x0      0
fpe4           0x0      0
---Type <return> to continue, or q <return> to quit---
fpe5           0x0      0
fpe6           0x0      0
fpe7           0x0      0

Does this help?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Carlos O'Donell]

On Wed, Apr 06, 2005 at 04:12:31PM -0400, John David Anglin wrote:
> > I found another program that doesn't work on hppa. This one was written
> > by Randolph if my memory serves me correctly. I'll have to add it to the
> > userspace tests that fail.
> > 
> > ---
> > all: foo.c libfoo.c
> > 	gcc -g -shared -c libfoo.c
> > 	rm -f libfoo.so
> > 	ln -s libfoo.o libfoo.so
> > 	gcc -g -o foo foo.c -lfoo -L. -lpthread
> > 
> > clean:
> > 	rm -f *.o
> > 	rm -f *.so
> > 	rm -f foo
> 
> The test can be simplified.  You don't need libfoo.  Just
> link foo with -lpthread and it fails.
> 
> I see libtcl8.4 is linked against libpthread.so.  This is probably
> why 8.3 works better than 8.4.
> 
> dave@hiauly6:~/gcc_test/pthr/carlos$ ./foo
> Parent = 24778
> Exiting on signal from child
> Waited for child 24779
> Quit (core dumped)
> 
> (gdb) bt
> #0  __unregister_atfork (dso_handle=0x40184b58)
>     at ../linuxthreads/sysdeps/unix/sysv/linux/unregister-atfork.c:28
> #1  0x4016ede0 in __pthread_wait_for_restart_signal (self=0x40184b80)

I just want to comment first that in Randolph's testcase we are also
waiting for a restart signal as we are here, but we never receive the
signal.

We tracked this down to some "dequeue" from the signal waiting queue
that just seemed to return zero as if the thread had already been
dequeued. Perhaps this *is* all just a sign of missing atomic
operations.

I'm adding them in right now, I'll run this test under the new glibc and
see what happens.

c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

> > #1  0x4016ede0 in __pthread_wait_for_restart_signal (self=0x40184b80)
> 
> I just want to comment first that in Randolph's testcase we are also
> waiting for a restart signal as we are here, but we never receive the
> signal.

I believe that __pthread_wait_for_restart_signal is called twice in
the testcase.  We hang the second time around.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Carlos O'Donell]

On Wed, Apr 06, 2005 at 04:12:31PM -0400, John David Anglin wrote:
> > I found another program that doesn't work on hppa. This one was written
> > by Randolph if my memory serves me correctly. I'll have to add it to the
> > userspace tests that fail.
> > 
> > ---
> > all: foo.c libfoo.c
> > 	gcc -g -shared -c libfoo.c
> > 	rm -f libfoo.so
> > 	ln -s libfoo.o libfoo.so
> > 	gcc -g -o foo foo.c -lfoo -L. -lpthread
> > 
> > clean:
> > 	rm -f *.o
> > 	rm -f *.so
> > 	rm -f foo
> 
> The test can be simplified.  You don't need libfoo.  Just
> link foo with -lpthread and it fails.
> 
> I see libtcl8.4 is linked against libpthread.so.  This is probably
> why 8.3 works better than 8.4.
> 
> Does this help?

It helps in the sense that we can distill the testcase down futher. It's
clearly some race in the resume suspend path, but the problem eludes me
right now.

Distilling this into a non-linuxthread testcase is the utmost priority.

c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

> 0x4016f05c in __pthread_sigsuspend (set=0xbff00dc8)
>     at ../linuxthreads/sysdeps/unix/sysv/linux/pt-sigsuspend.c:54
>     54      ../linuxthreads/sysdeps/unix/sysv/linux/pt-sigsuspend.c: No such file or directory.
> 	    in ../linuxthreads/sysdeps/unix/sysv/linux/pt-sigsuspend.c
> (gdb) bt
> #0  0x4016f05c in __pthread_sigsuspend (set=0xbff00dc8)
>     at ../linuxthreads/sysdeps/unix/sysv/linux/pt-sigsuspend.c:54
> #1  0x4016ede0 in __pthread_wait_for_restart_signal (self=0x40184b80)
>     at pthread.c:1203
> #2  0x4017081c in __pthread_alt_lock (lock=0x406c2980, self=0x40184b80)
>     at restart.h:34
> #3  0x4016d480 in *__GI___pthread_mutex_lock (mutex=0x406c2970) at mutex.c:123
> #4  0x40662234 in __unregister_atfork (dso_handle=0x40184ac0) at list.h:72
> #5  0x4016a930 in __do_global_dtors_aux () from /usr/lib/debug/libpthread.so.0
> #6  0x40173bb0 in _fini () from /usr/lib/debug/libpthread.so.0
> #7  0x400b6898 in _dl_fini () from /lib/ld.so.1
> #8  0x400b6898 in _dl_fini () from /lib/ld.so.1

I think there is a race condition between the parent and child regarding
the lock used for __unregister_atfork.  As a result, the parent suspends
itself waiting for a restart signal that never gets generated.  If I add
an alarm(2) call to exit_on_signal, then parent exits when the alarm occurs.

Based on my testing, we get a SIGCHLD signal delivered before the
SIGUSR2, and no restart after the wait:

dave@hiauly6:~/gcc_test/pthr/carlos$ ./foo
Parent = 26338
restart signal 18
Exiting on signal from child
Waited for child 26339

Don't fully understand the use of the __status field in
struct _pthread_fastlock but the parent suspends when it's nonzero.
It's set twice at 0x401707c0:

(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/dave/gcc_test/pthr/carlos/foo
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 26626)]
Parent = 26626
[Switching to Thread 16384 (LWP 26626)]

Breakpoint 5, 0x401707c0 in __pthread_alt_lock (lock=0x406c2980, self=0x0)
    at spinlock.c:374
374     spinlock.c: No such file or directory.
    in spinlock.c
(gdb) bt
#0  0x401707c0 in __pthread_alt_lock (lock=0x406c2980, self=0x0)
    at spinlock.c:374
#1  0x4016d480 in *__GI___pthread_mutex_lock (mutex=0x406c2970) at mutex.c:123
#2  0x4016dad8 in __pthread_fork (b=0x406c2970) at ptfork.c:33
#3  0x4062011c in __libc_fork ()
    at ../linuxthreads/sysdeps/unix/sysv/linux/fork.c:40
#4  0x000109d4 in main () at foo.c:42
(gdb) c
Continuing.
Child = 26627
Parent done.

Breakpoint 5, 0x401707c0 in __pthread_alt_lock (lock=0x406c2980, self=0x0)
    at spinlock.c:374
374     in spinlock.c
(gdb) c
Continuing.
restart signal 18

Breakpoint 3, exit_on_signal (signr=17) at foo.c:17
17        fprintf(stderr, "Exiting on signal from child\n");
(gdb) c
Continuing.
Exiting on signal from child
Waited for child 26627

Program exited normally.

With the break 5 enabled, the __status field is 0 when exit_on_signal
is entered.  When it's disabled, the __status is 1 when exit_on_signal
is entered and the parent fails to to terminate.  When 5 is disabled,
we also don't get the Parent done message.

The second break 5 occurs here:

Breakpoint 5, 0x401707c0 in __pthread_alt_lock (lock=0x406c2980, self=0x0)
    at spinlock.c:374
374     in spinlock.c
(gdb) bt
#0  0x401707c0 in __pthread_alt_lock (lock=0x406c2980, self=0x0)
    at spinlock.c:374
#1  0x4016d480 in *__GI___pthread_mutex_lock (mutex=0x406c2970) at mutex.c:123
#2  0x40662234 in __unregister_atfork (dso_handle=0x40184ac0) at list.h:72
#3  0x4016a930 in __do_global_dtors_aux () from /usr/lib/debug/libpthread.so.0
#4  0x40173bb0 in _fini () from /usr/lib/debug/libpthread.so.0
#5  0x400b6898 in _dl_fini () from /lib/ld.so.1
#6  0x400b6898 in _dl_fini () from /lib/ld.so.1

Here we are unregistering the fork handlers.  I have the feeling
that we die when the SIGUSR2 signal is taken while the __status
field is 1 in the first attempt at doing __unregister_atfork.

It seems that the problem is with exit when it's used in a
signal handler receiving signals from children.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

After thinking a bit more about this, I'm convinced that the problem
is a race between the registration of fork handlers and the delivery of
the signal.  If the signal handler is called before the registration
is complete, the code suspends when the signal handler exits and
tries to unregister the fork handlers.  The test works if the signal
is delayed.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Carlos O'Donell]

On Thu, Apr 07, 2005 at 10:56:00PM -0400, John David Anglin wrote:
> After thinking a bit more about this, I'm convinced that the problem
> is a race between the registration of fork handlers and the delivery of
> the signal.  If the signal handler is called before the registration
> is complete, the code suspends when the signal handler exits and
> tries to unregister the fork handlers.  The test works if the signal
> is delayed.

If you can prove that those mutex's aren't working properly then we have
a case :)

Since technically this is not possible, the mutex .lock in __fork_block
makes sure that such a thing can't occur.

---

During the handler registration the mutex is taken, and only when
complete released. The __pthread_fork code must take that mutex before
calling the prepared handlers.

Look at:
linuxthreads/ptfork.c 
	(__pthread_fork)
linuxthreads/sysdeps/unix/sysv/linux/register-atfork.c
	(__register_atfork)


The lock is via __libc_lock_lock, which is:
	(__libc_maybe_call2 (pthread_mutex_lock, (&(NAME)), 0));

Which is pthread_mutex_lock, which could call:
	__pthread_lock(&mutex->__m_lock, NULL);
	__pthread_alt_lock(&mutex->__m_lock, NULL);
	__pthread_lock(&mutex->__m_lock, self);
	__pthread_alt_lock(&mutex->__m_lock, self);

The __pthread_lock is rather complex.

Seems to rely upon:
	__pthread_acquire(&lock->__spinlock);

Which relies upon:
	testandset(spinlock);

Which relies upon all the ldcw code we worked out.

*** WARNING ***

What am I missing?

c.


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

> Since technically this is not possible, the mutex .lock in __fork_block
> makes sure that such a thing can't occur.

The program hangs doesn't it?

If the handler registration is done before the fork, I'll believe you.
However, if they are done after the fork, the lock isn't going to help.
The same problem could occur if a signal is taken during deregistration
when exiting from main.

A signal can be taken while the mutex is locked, or as it appears when
__status is 1.  Since the signal handler does an exit, the main code
never runs again and there is no way it can change the lock or __status.
So, we end up suspending the task while its trying to exit (i.e.,
deadlock).

If the signal handler returns instead of exits, there isn't a problem.
If the child delays sending the signal a bit, there isn't a problem.

In the presence of signals, I believe that adding and removing
handlers run at exit needs to be atomic.  A simple mutex isn't
sufficient as a thread or task may die in the critical region.
Even if there is a mutex recovery mechanism, a handler might get
run twice, etc.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Carlos O'Donell]

On Sat, Apr 09, 2005 at 01:58:52AM -0400, Carlos O'Donell wrote:
> On Fri, Apr 08, 2005 at 06:54:20PM -0400, John David Anglin wrote:
> > > Since technically this is not possible, the mutex .lock in __fork_block
> > > makes sure that such a thing can't occur.
> > 
> > The program hangs doesn't it?
> 
> I just realized the program doesn't call pthread_atfork and it still
> hangs. Though it doesn't hang on i386. Is there a relied upon semantic
> we are missing here?

The following hangs and I don't really know why... maybe I'm just
sleepy :)

--- 
#include <stdio.h>
#include <signal.h>
#include <sys/types.h>

void exit_on_signal(int signr)
{
  fprintf(stderr, "Thread %d, exiting on signal %d.\n", getpid(), signr); 
  exit(0);
}

int main(void)
{
  pid_t parent = getpid();
  printf("Parent thread is %d\n",parent);
  signal(SIGUSR2,exit_on_signal);
  if (fork() == 0) 
    {
      /* child kills parent */
      printf("Child thread is %d\n",getpid());
      kill(parent, SIGUSR2);
    } 
  else 
    {
      printf("Parent done.\n");
    }
  exit(0);
}
---

c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

> > I just realized the program doesn't call pthread_atfork and it still
> > hangs. Though it doesn't hang on i386. Is there a relied upon semantic
> > we are missing here?
> 
> The following hangs and I don't really know why... maybe I'm just
> sleepy :)

Did you link with -lpthread?  The deregistration is done as a destructor
for the library.  Not sure about the initial registration.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Randolph Chung]

One more thing - in my test i've seen the program somewhat randomly get
killed by SIGSEGV or SIGILL. Sometimes, the "count" variable gets
corrupted. I wonder if this is also the same problem Dave sees with
"random" crashes during gcc builds.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

> On Sat, Apr 09, 2005 at 01:58:52AM -0400, Carlos O'Donell wrote:
> > On Fri, Apr 08, 2005 at 06:54:20PM -0400, John David Anglin wrote:
> > > > Since technically this is not possible, the mutex .lock in __fork_block
> > > > makes sure that such a thing can't occur.
> > > 
> > > The program hangs doesn't it?
> > 
> > I just realized the program doesn't call pthread_atfork and it still
> > hangs. Though it doesn't hang on i386. Is there a relied upon semantic
> > we are missing here?
> 
> The following hangs and I don't really know why... maybe I'm just
> sleepy :)

I think it all comes down to the timing of the signal.

(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/dave/gcc_test/pthr/carlos/foo
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 1051)]
Parent = 1051

Program received signal SIGUSR2, User defined signal 2.
[Switching to Thread 16384 (LWP 1051)]
0x4016db24 in __pthread_fork (b=0x406c2970) at ptfork.c:46
46      ptfork.c: No such file or directory.
        in ptfork.c
(gdb) p *((struct _pthread_fastlock *)0x406c2980)
$33 = {__spinlock = {lock = {1, 1, 1, 1}}, __status = 1}

or

Breakpoint 4, exit_on_signal (signr=17) at foo.c:17
17        fprintf(stderr, "Exiting on signal from child\n");
(gdb) bt
#0  exit_on_signal (signr=17) at foo.c:17
#1  0x40171e80 in __pthread_sighandler (signo=17, ctx=0x0) at sighandler.c:39
#2  <signal handler called>
#3  0x4016db24 in __pthread_fork (b=0x406c2970) at ptfork.c:46
#4  0x4062011c in __libc_fork ()
    at ../linuxthreads/sysdeps/unix/sysv/linux/fork.c:40
    #5  0x000108f4 in main () at foo.c:34
(gdb) p *((struct _pthread_fastlock *)0x406c2980)
$34 = {__spinlock = {lock = {1, 1, 1, 1}}, __status = 1}

If you look, you will see that __pthread_alt_lock has obtained a
lock with __status = 0, set __status to 1, then released the lock.
We then get the signal with __status == 1.  When the signal handler
exits with exit(0), __cxa_finalize tries to deregister the fork
handlers.  When it gets the lock, __status is 1.  This causes
the process to suspend itself.

The same thing could occur while the lock is taken.  In that case,
I think the process would spin trying to acquire the lock.

I number of other things to note.  If the signal handler uses
_exit() or _Exit(), the program doesn't hang.  If exit() is called
twice, the behavior is undefined.  I would argue that we don't call
exit twice but that's timing depend with the current testcase.
exit() isn't listed as async-signal-safe, so it's probably not
legit to call it from a signal handler.  Thus, this isn't a bug.

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

PS: I think the ldcw_align macro can be improved.  It looks like GCC
is treating the pointer as volatile and generating icky code.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Carlos O'Donell]

On Sat, Apr 09, 2005 at 07:44:22PM -0400, John David Anglin wrote:
> I number of other things to note.  If the signal handler uses
> _exit() or _Exit(), the program doesn't hang.  If exit() is called
> twice, the behavior is undefined.  I would argue that we don't call
> exit twice but that's timing depend with the current testcase.
> exit() isn't listed as async-signal-safe, so it's probably not
> legit to call it from a signal handler.  Thus, this isn't a bug.

Bugger. Then our testcase is undefined. Removing exit() fixes the
problem.

Randolph's SIGILL's are still an interesting problem.

c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

> Bugger. Then our testcase is undefined. Removing exit() fixes the
> problem.

There might still be a bug.  I have the sense that doing a fork()
in the signal handler might cause a problem similar to that with
exit().  I say might because I'm not sure that sigsuspend will
cause a problem in this case.  The procss may get restarted by
a SIGCHLD signal.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

> Since technically this is not possible, the mutex .lock in __fork_block
> makes sure that such a thing can't occur.

Just wondering if this has to do with rt signals versus old style linux
signals (ia64 seems to define some wrappers).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Carlos O'Donell]

On Fri, Apr 08, 2005 at 08:13:21PM -0400, John David Anglin wrote:
> > Since technically this is not possible, the mutex .lock in __fork_block
> > makes sure that such a thing can't occur.
> 
> Just wondering if this has to do with rt signals versus old style linux
> signals (ia64 seems to define some wrappers).

libc or kernel?

c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

> > Just wondering if this has to do with rt signals versus old style linux
> > signals (ia64 seems to define some wrappers).
> 
> libc or kernel?

libc.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Carlos O'Donell]

On Sat, Apr 09, 2005 at 11:01:00AM -0400, John David Anglin wrote:
> > > Just wondering if this has to do with rt signals versus old style linux
> > > signals (ia64 seems to define some wrappers).
> > 
> > libc or kernel?
> 
> libc.

Where are you looking to see these wrappers?

c.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

> > What's the situation on the following signals: SIGLTHRRES, SIGLTHRCAN
> > and SIGLTHRDBG?  I'm not sure but pthread_cond_signal may need SIGLTHRRES.
> > Are these signals 37, 38 and 39?
> 
> yes, we use the same signals. 

It looks as if we have 36 signals which may need to be blocked.  However,
_SIGSET_NWORDS is 32.  Is this a problem?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Carlos O'Donell]

On Tue, Apr 05, 2005 at 09:21:17PM -0400, John David Anglin wrote:
> > > What's the situation on the following signals: SIGLTHRRES, SIGLTHRCAN
> > > and SIGLTHRDBG?  I'm not sure but pthread_cond_signal may need SIGLTHRRES.
> > > Are these signals 37, 38 and 39?
> > 
> > yes, we use the same signals. 
> 
> It looks as if we have 36 signals which may need to be blocked.  However,
> _SIGSET_NWORDS is 32.  Is this a problem?

I don't quite understand what you mean by this? Can you show me the code
that defines this and where the error might be?

c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

> On Tue, Apr 05, 2005 at 09:21:17PM -0400, John David Anglin wrote:
> > > > What's the situation on the following signals: SIGLTHRRES, SIGLTHRCAN
> > > > and SIGLTHRDBG?  I'm not sure but pthread_cond_signal may need SIGLTHRRES.
> > > > Are these signals 37, 38 and 39?
> > > 
> > > yes, we use the same signals. 
> > 
> > It looks as if we have 36 signals which may need to be blocked.  However,
> > _SIGSET_NWORDS is 32.  Is this a problem?
> 
> I don't quite understand what you mean by this? Can you show me the code
> that defines this and where the error might be?

It appears that we have 36 potentially maskabable interrupts but
_SIGSET_NWORDS is defined as if we had 32 (x86 number).

>>From bits/sigaction.h:

    ...
    /* Additional set of signals to be blocked.  */
	__sigset_t sa_mask;
    };

/* Bits in `sa_flags'.  */

>>From bits/sigset.h:

# define _SIGSET_NWORDS (1024 / (8 * sizeof (unsigned long int)))
typedef struct
  {
    unsigned long int __val[_SIGSET_NWORDS];
  } __sigset_t;


>>From bits/signum.h:

/* Signals.  */
#define SIGHUP          1       /* Hangup (POSIX).  */
...
#define SIGXCPU         33      /* CPU limit exceeded (4.2 BSD).  */
#define SIGXFSZ         34      /* File size limit exceeded (4.2 BSD).  */
#define SIGSTKFLT       36      /* Stack fault.  */

#define _NSIG           65      /* Biggest signal number + 1
                                   (including real-time signals).  */

#define SIGRTMIN        (__libc_current_sigrtmin ())
#define SIGRTMAX        (__libc_current_sigrtmax ())

/* These are the hard limits of the kernel.  These values should not be
   used directly at user level.  */
#define __SIGRTMIN      37

I'm wondering if _SIGSET_NWORDS is correctly defined.

I've been trying to match up some defines in a file to add Ada
tasking to GCC for parisc from an x86 file.  I don't know that
there is a problem but the above seemed strange (i.e., SIGXCPU,
SIGXFSZ and SIGSTKFLT don't appear to be maskable on parisc but
they are maskable on x86).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

> #define SIGXCPU         33      /* CPU limit exceeded (4.2 BSD).  */
> #define SIGXFSZ         34      /* File size limit exceeded (4.2 BSD).  */
> #define SIGSTKFLT       36      /* Stack fault.  */

I guess the answer to my question is these signals aren't used,
so we only support a maximum of 32 signals that can be masked.
Hopefully, an EINVAL error will be generated if the above signals
used.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Carlos O'Donell]

On Wed, Apr 06, 2005 at 12:11:31PM -0400, John David Anglin wrote:
> > #define SIGXCPU         33      /* CPU limit exceeded (4.2 BSD).  */
> > #define SIGXFSZ         34      /* File size limit exceeded (4.2 BSD).  */
> > #define SIGSTKFLT       36      /* Stack fault.  */
> 
> I guess the answer to my question is these signals aren't used,
> so we only support a maximum of 32 signals that can be masked.
> Hopefully, an EINVAL error will be generated if the above signals
> used.

Ah, ok.

We still have the problem of a *stuck* thread using linuxthreads.
Which we don't have a clear solution for...

More debugging is required. Perhaps I'll take a break from TLS glibc
stuff to debug this a bit.

c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[John David Anglin]

> We still have the problem of a *stuck* thread using linuxthreads.
> Which we don't have a clear solution for...

It's my belief that expect/tcl has a similar problem, so the problem
likely isn't specific to linuxthreads.  Expect definitely doesn't use
linuxthreads.  This affects GCC and binutils testing so I rate fixing
this as extremely important ;^)

The problem also affects java.  I often have to manually kill various
java processes after a GCC test run completes.  At the moment, locking
isn't atomic in java.  I wonder if we are being bitten by the glibc
routines that still aren't atomic.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Carlos O'Donell]

On Wed, Apr 06, 2005 at 02:37:49PM -0400, John David Anglin wrote:
> > We still have the problem of a *stuck* thread using linuxthreads.
> > Which we don't have a clear solution for...
> 
> It's my belief that expect/tcl has a similar problem, so the problem
> likely isn't specific to linuxthreads.  Expect definitely doesn't use
> linuxthreads.  This affects GCC and binutils testing so I rate fixing
> this as extremely important ;^)
> 
> The problem also affects java.  I often have to manually kill various
> java processes after a GCC test run completes.  At the moment, locking
> isn't atomic in java.  I wonder if we are being bitten by the glibc
> routines that still aren't atomic.

We are missing all sorts of atomic support in libc.

Adding support would require a forced min_kernel_version bump up to the
point where light-weight syscalls (CAS) exists, and the DoS for the
gateway page was fixed.

Would you like me to go ahead and do this, then roll a new glibc deb?

Here is a brief summary of what glibc needs:

===================
Atomic Definitions:

sysdeps/hppa/atomicity.h
  exchange_and_add
  atomic_add
  compare_and_swap
	= These three are phased out in favour of atomic.h

sysdeps/hppa/bits/atomic.h
  atomic_compare_and_exchange_val_acq
  atomic_compare_and_exchange_bool_acq
	= New atomic requirements for glibc

===================
Atomic Extensions using CAS:

include/atomic.h
  = This file builds everything based on
    atomic_compare_and_exchange_bool_acq

sysdeps/generic/bits/atomic.h
  = hppa uses this file right now.
  = Would have bee nice to have gotten a warning
    here.
  = non-atomic versions used.

===================
Atomic Uses:

Range from everything to the wakeup of threads from a queue using
atomic_increment and atomic_decrement (evaluates to a variant of
atomic_compare_and_exchagne_val_acq from include/atomic.h), to the 
change of a value in a semaphore.

===================

I've neglected this because in the past the required CAS didn't exist
and it was impossible to do in userspace. Time to test it all out.

c.



c.

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] pthread problems - test program

[Carlos O'Donell]

On Wed, Apr 06, 2005 at 02:37:49PM -0400, John David Anglin wrote:
> > We still have the problem of a *stuck* thread using linuxthreads.
> > Which we don't have a clear solution for...
> 
> It's my belief that expect/tcl has a similar problem, so the problem
> likely isn't specific to linuxthreads.  Expect definitely doesn't use
> linuxthreads.  This affects GCC and binutils testing so I rate fixing
> this as extremely important ;^)

We might have multiple problems :)

c.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] some other small bitops.h suggestion?

[Joel Soete]

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

Hello Randolph,

Thanks for previous ci :-)

Here is some other change to suggest (even thought it doesn't fix anything
:-( ):
--- include/asm-parisc/bitops.h.Orig    2005-04-05 10:29:52.000000000 +0200
+++ include/asm-parisc/bitops.h 2005-04-05 10:58:36.000000000 +0200
@@ -304,17 +304,10 @@
  * hweightN: returns the hamming weight (i.e. the number
  * of bits set) of a N-bit word
  */
-#define hweight64(x)                                           \
-({                                                             \
-       unsigned long __x = (x);                                \
-       unsigned int __w;                                       \
-       __w = generic_hweight32((unsigned int) __x);            \
-       __w += generic_hweight32((unsigned int) (__x>>32));     \
-       __w;                                                    \
-})
-#define hweight32(x) generic_hweight32(x)
-#define hweight16(x) generic_hweight16(x)
-#define hweight8(x) generic_hweight8(x)
+#define hweight64(x)   generic_hweight64(x)
+#define hweight32(x)   generic_hweight32(x)
+#define hweight16(x)   generic_hweight16(x)
+#define hweight8(x)    generic_hweight8(x)

 /*
  * Every architecture must define this function. It's the fastest
@@ -337,10 +330,8 @@
 #else
        if (unlikely(b[0]))
                return __ffs(b[0]);
-       if (unlikely(((unsigned int)b[1])))
+       if (unlikely(b[1]))
                return __ffs(b[1]) + 64;
-       if (b[1] >> 32)
-               return __ffs(b[1] >> 32) + 96;
        return __ffs(b[2]) + 128;
 #endif
 }
====><====

The first hunk was because hweight64() was not 32bit ok (even thought not
actually used right now) and willy suggest me this change (as other arch
:-) ).

The second hunk just because I didn't understand why this form (looks like
sparc64) and not another (e.g. ppc64).
I so wrote a small test (here attached bitops-t5.c) and don't see significant
performance lost/win (excepted if I made mistakes)

Thanks,
    Joel



[-- Attachment #2: include_asm-parisc_bitops.h.diff --]
[-- Type: text/plain, Size: 1106 bytes --]

--- include/asm-parisc/bitops.h.Orig	2005-04-05 10:29:52.000000000 +0200
+++ include/asm-parisc/bitops.h	2005-04-05 10:58:36.000000000 +0200
@@ -304,17 +304,10 @@
  * hweightN: returns the hamming weight (i.e. the number
  * of bits set) of a N-bit word
  */
-#define hweight64(x)						\
-({								\
-	unsigned long __x = (x);				\
-	unsigned int __w;					\
-	__w = generic_hweight32((unsigned int) __x);		\
-	__w += generic_hweight32((unsigned int) (__x>>32));	\
-	__w;							\
-})
-#define hweight32(x) generic_hweight32(x)
-#define hweight16(x) generic_hweight16(x)
-#define hweight8(x) generic_hweight8(x)
+#define hweight64(x)	generic_hweight64(x)
+#define hweight32(x)	generic_hweight32(x)
+#define hweight16(x)	generic_hweight16(x)
+#define hweight8(x)	generic_hweight8(x)
 
 /*
  * Every architecture must define this function. It's the fastest
@@ -337,10 +330,8 @@
 #else
 	if (unlikely(b[0]))
 		return __ffs(b[0]);
-	if (unlikely(((unsigned int)b[1])))
+	if (unlikely(b[1]))
 		return __ffs(b[1]) + 64;
-	if (b[1] >> 32)
-		return __ffs(b[1] >> 32) + 96;
 	return __ffs(b[2]) + 128;
 #endif
 }

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: bitops-t5.c --]
[-- Type: text/x-csrc, Size: 4993 bytes --]

/*
    # gcc -O2 -march=2.0 -D__LP64__ -DVORIG -o bitops-o bitops-t5.c
    # gcc -O2 -march=2.0 -D__LP64__ -o bitops-n bitops-t5.c
    # for i in 1 2 3 4 5 ; do echo "Loop $i"; time ./bitops-o ; time ./bitops-n ; done
Loop 1
------
Computing sched_find_first_bit_pa() for i = 0 to 2147483648...
LOOP_SIZE = 0x0000000080000000.

real    0m22.582s
user    0m22.550s
sys     0m0.021s

Computing sched_find_first_bit_ppc64() for i = 0 to 2147483648...
LOOP_SIZE = 0x0000000080000000.

real    0m22.573s
user    0m22.544s
sys     0m0.020s

Loop 2
------
Computing sched_find_first_bit_pa() for i = 0 to 2147483648...
LOOP_SIZE = 0x0000000080000000.

real    0m22.625s
user    0m22.546s
sys     0m0.023s

Computing sched_find_first_bit_ppc64() for i = 0 to 2147483648...
LOOP_SIZE = 0x0000000080000000.

real    0m22.601s
user    0m22.562s
sys     0m0.015s

Loop 3
------
Computing sched_find_first_bit_pa() for i = 0 to 2147483648...
LOOP_SIZE = 0x0000000080000000.

real    0m22.619s
user    0m22.554s
sys     0m0.023s

Computing sched_find_first_bit_ppc64() for i = 0 to 2147483648...
LOOP_SIZE = 0x0000000080000000.

real    0m22.582s
user    0m22.558s
sys     0m0.013s

Loop 4
------
Computing sched_find_first_bit_pa() for i = 0 to 2147483648...
LOOP_SIZE = 0x0000000080000000.

real    0m22.659s
user    0m22.559s
sys     0m0.022s

Computing sched_find_first_bit_ppc64() for i = 0 to 2147483648...
LOOP_SIZE = 0x0000000080000000.

real    0m23.006s
user    0m22.561s
sys     0m0.030s

Loop 5
------
Computing sched_find_first_bit_pa() for i = 0 to 2147483648...
LOOP_SIZE = 0x0000000080000000.

real    0m22.627s
user    0m22.569s
sys     0m0.018s

Computing sched_find_first_bit_ppc64() for i = 0 to 2147483648...
LOOP_SIZE = 0x0000000080000000.

real    0m22.630s
user    0m22.552s
sys     0m0.019s

 */

#include <stdio.h>

/* include/linux/compiler.h */
#define likely(x)       __builtin_expect(!!(x), 1)
#define unlikely(x)     __builtin_expect(!!(x), 0)

 /* include/linux/kernel.h */
#define ULLONG_MAX      (~0ULL)

/**
 * __ffs - find first bit in word.
 * @word: The word to search
 *
 * Undefined if no bit exists, so code should check against 0 first.
 */

static __inline__ unsigned long long __ffs(unsigned long long x)
{
	unsigned long long ret;

	__asm__(
#ifdef __LP64__
		" ldi       63,%1\n"
		" extrd,u,*<>  %0,63,32,%%r0\n"
		" extrd,u,*TR  %0,31,32,%0\n"	/* move top 32-bits down */
		" addi    -32,%1,%1\n"
#else
		" ldi       31,%1\n"
#endif
		" extru,<>  %0,31,16,%%r0\n"
		" extru,TR  %0,15,16,%0\n"	/* xxxx0000 -> 0000xxxx */
		" addi    -16,%1,%1\n"
		" extru,<>  %0,31,8,%%r0\n"
		" extru,TR  %0,23,8,%0\n"	/* 0000xx00 -> 000000xx */
		" addi    -8,%1,%1\n"
		" extru,<>  %0,31,4,%%r0\n"
		" extru,TR  %0,27,4,%0\n"	/* 000000x0 -> 0000000x */
		" addi    -4,%1,%1\n"
		" extru,<>  %0,31,2,%%r0\n"
		" extru,TR  %0,29,2,%0\n"	/* 0000000y, 1100b -> 0011b */
		" addi    -2,%1,%1\n"
		" extru,=  %0,31,1,%%r0\n"	/* check last bit */
		" addi    -1,%1,%1\n"
			: "+r" (x), "=r" (ret) );

	return ret;
}

/*
 * Every architecture must define this function. It's the fastest
 * way of searching a 140-bit bitmap where the first 100 bits are
 * unlikely to be set. It's guaranteed that at least one of the 140
 * bits is cleared.
 */
static inline int sched_find_first_bit_pa(const unsigned long long *b)
{
#ifndef __LP64__
	if (unlikely(b[0]))
		return __ffs(b[0]);
	if (unlikely(b[1]))
		return __ffs(b[1]) + 32;
	if (unlikely(b[2]))
		return __ffs(b[2]) + 64;
	if (b[3])
		return __ffs(b[3]) + 96;
	return __ffs(b[4]) + 128;
#else
	if (unlikely(b[0]))
		return __ffs(b[0]);
	if (unlikely(((unsigned int)b[1])))
		return __ffs(b[1]) + 64;
	if (b[1] >> 32)
		return __ffs(b[1] >> 32) + 96;
	return __ffs(b[2]) + 128;
#endif
}

static inline int sched_find_first_bit_ppc64(const unsigned long long *b)
{
#ifndef __LP64__
	if (unlikely(b[0]))
		return __ffs(b[0]);
	if (unlikely(b[1]))
		return __ffs(b[1]) + 32;
	if (unlikely(b[2]))
		return __ffs(b[2]) + 64;
	if (b[3])
		return __ffs(b[3]) + 96;
	return __ffs(b[4]) + 128;
#else
	if (unlikely(b[0]))
		return __ffs(b[0]);
	if (unlikely(b[1]))
		return __ffs(b[1]) + 64;
	return __ffs(b[2]) + 128;
#endif
}

#ifndef __LP64__
#define BITMAP_SIZE	5
#else
#define BITMAP_SIZE	3
#endif

#define LOOP_SIZE	0x80000000ULL

main()
{
	char buf[512];
	int m,n;
	unsigned long long i, Extrd;

	struct prio_array_sample {
		unsigned long long bitmap[BITMAP_SIZE];
	} s_array;

	for (m=0; m<BITMAP_SIZE; m++) {
		s_array.bitmap[m] = 0ULL;
	}

#ifdef VORIG
	printf("Computing sched_find_first_bit_pa() for i = %u to %llu...\n", 0, LOOP_SIZE);
#else
	printf("Computing sched_find_first_bit_ppc64() for i = %u to %llu...\n", 0, LOOP_SIZE);
#endif
	printf("LOOP_SIZE = %#018llx.\n", LOOP_SIZE);

	for (m=0; m<BITMAP_SIZE; m++) {
		s_array.bitmap[m] = 0x123456789abcde0fULL;
	}

	for (i=0x0ULL; i<LOOP_SIZE; i++) {
#ifdef VORIG
		sched_find_first_bit_pa(s_array.bitmap);
#else
		sched_find_first_bit_ppc64(s_array.bitmap);
#endif
	}

}


[-- Attachment #4: Type: text/plain, Size: 169 bytes --]

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] some other small bitops.h suggestion?

[Grant Grundler]

On Tue, Apr 05, 2005 at 11:28:26AM +0200, Joel Soete wrote:
...
> -#define hweight32(x) generic_hweight32(x)
> -#define hweight16(x) generic_hweight16(x)
> -#define hweight8(x) generic_hweight8(x)
> +#define hweight64(x)   generic_hweight64(x)
> +#define hweight32(x)   generic_hweight32(x)
> +#define hweight16(x)   generic_hweight16(x)
> +#define hweight8(x)    generic_hweight8(x)

This bit is fine.

>   * Every architecture must define this function. It's the fastest
> @@ -337,10 +330,8 @@
>  #else
>         if (unlikely(b[0]))
>                 return __ffs(b[0]);
> -       if (unlikely(((unsigned int)b[1])))
> +       if (unlikely(b[1]))
>                 return __ffs(b[1]) + 64;
> -       if (b[1] >> 32)
> -               return __ffs(b[1] >> 32) + 96;
>         return __ffs(b[2]) + 128;
>  #endif
...
> The second hunk just because I didn't understand why this form (looks like
> sparc64) and not another (e.g. ppc64).

I think it's just for performance.
Sparc implementation of __ffs isn't very fast and it's quicker
to test the high/low parts of the word seperately because of which
bits are most likely to be set.

I'm pretty sure on parisc it will only cost two more cycles to check
the extra 32-bits. The test for top/bottom seperately would likely
cost us more if we don't predict the branches correctly.

But becuase of how sparc64 does it, I'm wondering if we should
use "likely(b[1])". Any comments?


sched_find_first_bit(), __clear_bit() and find_next_bit() just
all need to agree how bits are numbered in am in-memory bitmap.

Code like this in kernel/sched.c:

skip_bitmap:
        if (!idx)
                idx = sched_find_first_bit(array->bitmap);
        else
                idx = find_next_bit(array->bitmap, MAX_PRIO, idx);

requires we number the bits the same way in both.
And __clear_bit() has to agree as well:

static void dequeue_task(struct task_struct *p, prio_array_t *array)
{
        array->nr_active--;
        list_del(&p->run_list);
        if (list_empty(array->queue + p->prio))
                __clear_bit(p->prio, array->bitmap);
}


parisc __clear_bit also uses unsigned long to access the array:

static __inline__ void __clear_bit(unsigned long nr, volatile unsigned long * address)
{
        unsigned long mask;
        unsigned long *addr = (unsigned long *) address;

        addr += (nr >> SHIFT_PER_LONG);
        mask = 1UL << CHOP_SHIFTCOUNT(nr);
        *addr &= ~mask;
}

ugh...I think I'm just going to use the sparc64 version here.
I'm not comfortable with the "volatile" attribute getting dropped.

thanks,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] some other small bitops.h suggestion?

[Joel Soete]

> -- Original Message --
> Date: Wed, 13 Apr 2005 00:14:30 -0600
> From: Grant Grundler <grundler@parisc-linux.org>
> To: Joel Soete <soete.joel@tiscali.be>
> Cc: Randolph Chung <randolph@tausq.org>,
> 	parisc-linux@lists.parisc-linux.org
> Subject: Re: [parisc-linux] some other small bitops.h suggestion?
> 
> 
> On Tue, Apr 05, 2005 at 11:28:26AM +0200, Joel Soete wrote:
> ...
> > -#define hweight32(x) generic_hweight32(x)
> > -#define hweight16(x) generic_hweight16(x)
> > -#define hweight8(x) generic_hweight8(x)
> > +#define hweight64(x)   generic_hweight64(x)
> > +#define hweight32(x)   generic_hweight32(x)
> > +#define hweight16(x)   generic_hweight16(x)
> > +#define hweight8(x)    generic_hweight8(x)
> 
> This bit is fine.
> 
> >   * Every architecture must define this function. It's the fastest
> > @@ -337,10 +330,8 @@
> >  #else
> >         if (unlikely(b[0]))
> >                 return __ffs(b[0]);
> > -       if (unlikely(((unsigned int)b[1])))
> > +       if (unlikely(b[1]))
> >                 return __ffs(b[1]) + 64;
> > -       if (b[1] >> 32)
> > -               return __ffs(b[1] >> 32) + 96;
> >         return __ffs(b[2]) + 128;
> >  #endif
> ...
> > The second hunk just because I didn't understand why this form (looks=

like
> > sparc64) and not another (e.g. ppc64).
> 
> I think it's just for performance.
> Sparc implementation of __ffs isn't very fast and it's quicker
> to test the high/low parts of the word seperately because of which
> bits are most likely to be set.
> 
That's what I thought too but not sure.

> I'm pretty sure on parisc it will only cost two more cycles to check
> the extra 32-bits. The test for top/bottom seperately would likely
> cost us more if we don't predict the branches correctly.
> 
> But becuase of how sparc64 does it, I'm wondering if we should
> use "likely(b[1])". Any comments?
> 
> 
> sched_find_first_bit(), __clear_bit() and find_next_bit() just
> all need to agree how bits are numbered in am in-memory bitmap.
> 
> Code like this in kernel/sched.c:
> 
> skip_bitmap:
>         if (!idx)
>                 idx =3D sched_find_first_bit(array->bitmap);
>         else
>                 idx =3D find_next_bit(array->bitmap, MAX_PRIO, idx);
> 
> requires we number the bits the same way in both.
> And __clear_bit() has to agree as well:
> 
> static void dequeue_task(struct task_struct *p, prio_array_t *array)
> {
>         array->nr_active--;
>         list_del(&p->run_list);
>         if (list_empty(array->queue + p->prio))
>                 __clear_bit(p->prio, array->bitmap);
> }
> 
> 
> parisc __clear_bit also uses unsigned long to access the array:
> 
> static __inline__ void __clear_bit(unsigned long nr, volatile unsigned
long
> * address)
> {
>         unsigned long mask;
>         unsigned long *addr =3D (unsigned long *) address;
> 
>         addr +=3D (nr >> SHIFT_PER_LONG);
>         mask =3D 1UL << CHOP_SHIFTCOUNT(nr);
>         *addr &=3D ~mask;
> }
> 
> ugh...I think I'm just going to use the sparc64 version here.
> I'm not comfortable with the "volatile" attribute getting dropped.
> 
Good for me ;-)

Thanks,
    Joel


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] some other small bitops.h suggestion?

[Grant Grundler]

On Tue, Apr 05, 2005 at 11:28:26AM +0200, Joel Soete wrote:
> Here is some other change to suggest (even thought it doesn't fix anything
> :-( ):
...

Here is what I'd like to commit for include/parisc/bitops.h.

Summary of changes:
o uses generic_hweight64
o uses CONFIG_64BIT where neccessary
o make our __clear_bit and __set_bit look like ppc64 instead of sparc.
o simplify sched_find_first_bit()

Any comments before I commit this?

(Joel, additional changes can go in another commit please :^)

Beware, touching bitops.h will cause a full recompile.

thanks,
grant


Index: include/asm-parisc/bitops.h
===================================================================
RCS file: /var/cvs/linux-2.6/include/asm-parisc/bitops.h,v
retrieving revision 1.18
diff -u -p -r1.18 bitops.h
--- include/asm-parisc/bitops.h	4 Apr 2005 17:54:41 -0000	1.18
+++ include/asm-parisc/bitops.h	13 Apr 2005 17:44:13 -0000
@@ -12,7 +12,7 @@
  * to include/asm-i386/bitops.h or kerneldoc
  */
 
-#ifdef __LP64__
+#ifdef CONFIG_64BIT
 #   define SHIFT_PER_LONG 6
 #ifndef BITS_PER_LONG
 #   define BITS_PER_LONG 64
@@ -43,37 +43,29 @@ static __inline__ void set_bit(int nr, v
 	_atomic_spin_unlock_irqrestore(addr, flags);
 }
 
-static __inline__ void __set_bit(int nr, volatile unsigned long * address)
+static __inline__ void __set_bit(unsigned long nr, volatile unsigned long * addr)
 {
-	unsigned long mask;
-	unsigned long *addr = (unsigned long *) address;
+	volatile unsigned long *m = addr + (((unsigned) nr) >> SHIFT_PER_LONG);
 
-	addr += (nr >> SHIFT_PER_LONG);
-	mask = 1UL << CHOP_SHIFTCOUNT(nr);
-	*addr |= mask;
+	*m |= 1UL << CHOP_SHIFTCOUNT(nr);
 }
 
 static __inline__ void clear_bit(int nr, volatile unsigned long * address)
 {
-	unsigned long mask;
-	unsigned long *addr = (unsigned long *) address;
+	unsigned long mask = 1UL << CHOP_SHIFTCOUNT((unsigned int) nr);
+	volatile unsigned long *addr = address + (((unsigned int) nr) >> SHIFT_PER_LONG);
 	unsigned long flags;
 
-	addr += (nr >> SHIFT_PER_LONG);
-	mask = 1UL << CHOP_SHIFTCOUNT(nr);
 	_atomic_spin_lock_irqsave(addr, flags);
 	*addr &= ~mask;
 	_atomic_spin_unlock_irqrestore(addr, flags);
 }
 
-static __inline__ void __clear_bit(unsigned long nr, volatile unsigned long * address)
+static __inline__ void __clear_bit(unsigned long nr, volatile unsigned long * addr)
 {
-	unsigned long mask;
-	unsigned long *addr = (unsigned long *) address;
+	volatile unsigned long *m = addr + (nr >> SHIFT_PER_LONG);
 
-	addr += (nr >> SHIFT_PER_LONG);
-	mask = 1UL << CHOP_SHIFTCOUNT(nr);
-	*addr &= ~mask;
+	*m &= ~(1UL << CHOP_SHIFTCOUNT(nr));
 }
 
 static __inline__ void change_bit(int nr, volatile unsigned long * address)
@@ -89,14 +81,11 @@ static __inline__ void change_bit(int nr
 	_atomic_spin_unlock_irqrestore(addr, flags);
 }
 
-static __inline__ void __change_bit(int nr, volatile unsigned long * address)
+static __inline__ void __change_bit(unsigned long nr, volatile unsigned long * addr)
 {
-	unsigned long mask;
-	unsigned long *addr = (unsigned long *) address;
+	volatile unsigned long *m = addr + (nr >> SHIFT_PER_LONG);
 
-	addr += (nr >> SHIFT_PER_LONG);
-	mask = 1UL << CHOP_SHIFTCOUNT(nr);
-	*addr ^= mask;
+	*m ^= 1UL << CHOP_SHIFTCOUNT(nr);
 }
 
 static __inline__ int test_and_set_bit(int nr, volatile unsigned long * address)
@@ -229,7 +218,7 @@ static __inline__ unsigned long __ffs(un
 	unsigned long ret;
 
 	__asm__(
-#if BITS_PER_LONG > 32
+#ifdef CONFIG_64BIT
 		" ldi       63,%1\n"
 		" extrd,u,*<>  %0,63,32,%%r0\n"
 		" extrd,u,*TR  %0,31,32,%0\n"	/* move top 32-bits down */
@@ -304,14 +293,7 @@ static __inline__ int fls(int x)
  * hweightN: returns the hamming weight (i.e. the number
  * of bits set) of a N-bit word
  */
-#define hweight64(x)						\
-({								\
-	unsigned long __x = (x);				\
-	unsigned int __w;					\
-	__w = generic_hweight32((unsigned int) __x);		\
-	__w += generic_hweight32((unsigned int) (__x>>32));	\
-	__w;							\
-})
+#define hweight64(x) generic_hweight64(x)
 #define hweight32(x) generic_hweight32(x)
 #define hweight16(x) generic_hweight16(x)
 #define hweight8(x) generic_hweight8(x)
@@ -324,7 +306,13 @@ static __inline__ int fls(int x)
  */
 static inline int sched_find_first_bit(const unsigned long *b)
 {
-#ifndef __LP64__
+#ifdef CONFIG_64BIT
+	if (unlikely(b[0]))
+		return __ffs(b[0]);
+	if (unlikely(b[1]))
+		return __ffs(b[1]) + 64;
+	return __ffs(b[2]) + 128;
+#else
 	if (unlikely(b[0]))
 		return __ffs(b[0]);
 	if (unlikely(b[1]))
@@ -334,14 +322,6 @@ static inline int sched_find_first_bit(c
 	if (b[3])
 		return __ffs(b[3]) + 96;
 	return __ffs(b[4]) + 128;
-#else
-	if (unlikely(b[0]))
-		return __ffs(b[0]);
-	if (unlikely(((unsigned int)b[1])))
-		return __ffs(b[1]) + 64;
-	if (b[1] >> 32)
-		return __ffs(b[1] >> 32) + 96;
-	return __ffs(b[2]) + 128;
 #endif
 }
 
@@ -445,7 +425,7 @@ found_middle:
  * test_and_{set,clear}_bit guarantee atomicity without
  * disabling interrupts.
  */
-#ifdef __LP64__
+#ifdef CONFIG_64BIT
 #define ext2_set_bit(nr, addr)		__test_and_set_bit((nr) ^ 0x38, (unsigned long *)addr)
 #define ext2_set_bit_atomic(l,nr,addr)  test_and_set_bit((nr) ^ 0x38, (unsigned long *)addr)
 #define ext2_clear_bit(nr, addr)	__test_and_clear_bit((nr) ^ 0x38, (unsigned long *)addr)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] some other small bitops.h suggestion?

[Randolph Chung]

> One might argue that the contents pointed to by addr can be volatile,
> but in that case shouldn't it be "unsigned long * volatile addr"?

no, this part is not right. pls ignore.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] some other small bitops.h suggestion?

[Grant Grundler]

On Wed, Apr 13, 2005 at 06:31:05PM -0700, Randolph Chung wrote:
> One might argue that the contents pointed to by addr can be volatile,
> but in that case shouldn't it be "unsigned long * volatile addr"?

Originally it's to make sure gcc doesn't optimize the read/modify/write
completely away if it thinks no one is using the result.

> In this case, we are doing a single operation to *addr, and this
> function is explicitly not atomic, so I am not quite sure why we need
> volatile at all.

James Bottomley dug up the original thread:
	http://marc.theaimsgroup.com/?t=108826637900003

If __set_bit() doesn't need volatile, then is the same true
for __clear_bit and __change_bit?

grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] some other small bitops.h suggestion?

[John David Anglin]

> > In this case, we are doing a single operation to *addr, and this
> > function is explicitly not atomic, so I am not quite sure why we need
> > volatile at all.
> 
> James Bottomley dug up the original thread:
> 	http://marc.theaimsgroup.com/?t=108826637900003
> 
> If __set_bit() doesn't need volatile, then is the same true
> for __clear_bit and __change_bit?

The above discussion bothers me a lot:

  So the rule has always been (and this has nothing to do with parisc, and 
  parisc DOES NOT GET TO SET THE RULES!) that "test_bit()" acts in a 
  volatile manner, and that you traditionally could write

     while (test_and_set_bit(xxx, field))
       while (test_bit(xx, field)) /* Nothing */;

  to do a lock.

  NOTE! There are no volatile data structures _anywhere_, because as
  mentioned, I think that whole notion is a total piece of crap, and is not
  even a well-defined part of the C language. But the test_bit() function
  has to act as if the data it is passed down can change. To repeat:  
  _codepaths_ may have volatility attributes depending on usage of the data.

I don't believe that a lock can be implemented as shown above on
PA-RISC as we don't have an atomic test_and_set_bit.  The only atomic
ops are ldcw and ldcd (load and clear word/double).  So, if test_and_set_bit
needs locking semantics, it will have to be implemented with spinlocks.

Secondly, I'm not convinced of the concept of volatile code paths
and using the volatile keyword to keep loops from being optimized
away.  I think this approach results in bad code.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] some other small bitops.h suggestion?

[Grant Grundler]

On Thu, Apr 14, 2005 at 10:39:08AM -0400, John David Anglin wrote:
...
> I don't believe that a lock can be implemented as shown above on
> PA-RISC as we don't have an atomic test_and_set_bit.  The only atomic
> ops are ldcw and ldcd (load and clear word/double).  So, if test_and_set_bit
> needs locking semantics, it will have to be implemented with spinlocks.

I think linus was just defining what he expects from test_and_set_bit().
If parisc implementation doesn't work that way, he considers it a bug
in the parisc implemenation (vs redefining the interface).

> Secondly, I'm not convinced of the concept of volatile code paths
> and using the volatile keyword to keep loops from being optimized
> away.  I think this approach results in bad code.

My take is "volatile" is just a way to tell gcc something about the
code/data that it can't see. I'm not going to quibble with linus
about whether data is volatile or code is volatile. I think in some
cases it's one (e.g accessing memory mapped HW) or the other
(accessing shared data). Key thing is gcc be able to optimize code
but not remove it (especially in the latter case).

We do use volatile for accessing memory mapped HW in all our readl/writel
implementations. Those are uncached accesses and thus shouldn't
ever get removed. This is the obvious case.

I just realized we often use mb() variants in the kernel to mark at least
boundary of lockless access to shared data. But volatile is almost
never mentioned for many of these accesses.
E.g. tg3.[ch] driver messes around with shared memory areas (descriptor
rings) but doesn't have "volatile" keyword in it.

Though we do NOT mark those accesses (memory writes in particular)
with volatile, it sounds like we should.

grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] some other small bitops.h suggestion?

[John David Anglin]

> My take is "volatile" is just a way to tell gcc something about the
> code/data that it can't see. I'm not going to quibble with linus
> about whether data is volatile or code is volatile. I think in some
> cases it's one (e.g accessing memory mapped HW) or the other
> (accessing shared data). Key thing is gcc be able to optimize code
> but not remove it (especially in the latter case).

The problem here is that there are some conventions regarding the use
of "volatile" in GCC C that are rather poorly documented.  You might
look at this discussion regarding volatile and C++ to get a flavor
for what I mean <http://gcc.gnu.org/ml/gcc/2005-04/msg00724.html>.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] some other small bitops.h suggestion?

[Grant Grundler]

On Fri, Apr 15, 2005 at 05:41:22PM -0400, John David Anglin wrote:
> > My take is "volatile" is just a way to tell gcc something about the
> > code/data that it can't see. I'm not going to quibble with linus
> > about whether data is volatile or code is volatile. I think in some
> > cases it's one (e.g accessing memory mapped HW) or the other
> > (accessing shared data). Key thing is gcc be able to optimize code
> > but not remove it (especially in the latter case).
> 
> The problem here is that there are some conventions regarding the use
> of "volatile" in GCC C that are rather poorly documented.  You might
> look at this discussion regarding volatile and C++ to get a flavor
> for what I mean <http://gcc.gnu.org/ml/gcc/2005-04/msg00724.html>.

In this followup, I think Nathan Sidwell got at least one bit:
| It seems to me that threads require barriers _within_ the abstract machine,
| and currently there is no mechanism to specify just that.  Volatile is all
| we have, and AFAICT those are only ordered WRT other volatile accesses
| separated by a sequence point.

(See http://gcc.gnu.org/ml/gcc/2005-04/msg00748.html)

And that's a difference: the kernel has defined a set of barriers.
Linux kernel generally doesn't depend on current semantics of volatile
for accessing memory mapped IO.
At least I don't think it does since ia64-linux is using ld.acq
and st.rel instructions today.  While the compiler is observing
the ordering, the CPU may not.  e.g. The CPU doesn't wait for a
regular store to complete before starting sucessive ld.acq.

This is a rare for IO drivers to do this. More discussion about
volatile and acq/rel semantics in "IA-64 Linux Kernel" by
David Mosberger and Stephane Eranian.

I learned one more thing about ia64 not in the book when trying
to understand how ld.rel works WRT to fixing posted write problems
(st.rel).  I summarize it in my OLS2004 paper:
	http://iou.parisc-linux.org/ols2004/www/

See http://iou.parisc-linux.org/ols2004/www/2_2_Eh_Memory_Reads.html

  "Memory ordering imposes no constraint on non-load/store instructions."

This is critical for changing CPU state (enable/disable I-bit) or
reading CPU state (e.g. ITC).

ia64 has a weakly ordered memory subsystem but executes instructions
in order. parisc is strongly ordered for both and is less complicated
in this regard. I think because of this parisc could use volatile
keyword for telling the compiler certain instructions *must* be kept
in the stream, and then use memory barriers to constrain how the
optimizer can reorder the instruction stream.

But changing the semantics of volatile will break some code
in both the kernel and in multithreaded applications.
I strongly suspect this is going to need to fall into
the "use with caution" compiler flags (like -O4).

I'm glad they are having this discussion now *before*
widespread adoption of RDMA technologies.

hth,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux