Re: [parisc-linux] killing a set of user processes causes system

Re: [parisc-linux] killing a set of user processes causes system

[John David Anglin]

> this is an updated patch, where only the absolute necessary pieces were changed.
> It applies to current git tree...

2.6.20-rc1-gd13bc210-dirty boots with the patch but su/pam authentication
is somehow broken for root.  I used the defaults for all config updates.
The only bad things that I see in the log files is some unaligned accesses
by hald.

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

Re: [parisc-linux] killing a set of user processes causes system

[John David Anglin]

> this is an updated patch, where only the absolute necessary pieces were changed.

The patch doesn't help.  Still getting hung java processes.

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

Re: [parisc-linux] killing a set of user processes causes system

[John David Anglin]

> > Also, X is broken again.  It seems the card is outputing at higher

> I'll look into this when I find time, but compiling X is not my favorite task :-)

As of yesterday (xserver-xorg 7.1.0-10), the frame buffer and mouse
were working again.  However, keyboard input doesn't work.

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

Re: [parisc-linux] killing a set of user processes causes system

[Helge Deller]

On Wednesday 20 December 2006 23:42, John David Anglin wrote:
> > > FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
> > > 
> > > which may be a kernel problem since the fail doesn't occur using
> > > a 64-bit kernel.  The test also doesn't fail under hpux, so it's
> > > not likely a compilation issue.  The problem is in setting a
> > > date/time string.  Might have something to do with locale functions.
> > 
> > Can you provide an strace ?
>     ..[many lines of strace stripped]....
> 
> Don't see anything that's obvious.

Me neither.

Helge

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

Re: [parisc-linux] killing a set of user processes causes system

[John David Anglin]

> > FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
> > 
> > which may be a kernel problem since the fail doesn't occur using
> > a 64-bit kernel.  The test also doesn't fail under hpux, so it's
> > not likely a compilation issue.  The problem is in setting a
> > date/time string.  Might have something to do with locale functions.
> 
> Can you provide an strace ?

Don't see anything that's obvious.

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

execve("./4.xg", ["./4.xg"], [/* 18 vars */]) = 0
newuname({sys="Linux", node="hiauly6", ...}) = 0
brk(0)                                  = 0x13000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40000000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("PARISC/libstdc++.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("libstdc++.so.6", O_RDONLY)        = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/gcc/PARISC/libstdc++.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/dave/gnu/gcc-4.2/objdir/gcc/PARISC", 0xc01ce5c8) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/gcc/libstdc++.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/dave/gnu/gcc-4.2/objdir/gcc", {st_mode=0, st_size=4303557231594, ...}) = 0
open("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/PARISC/libstdc++.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/PARISC", 0xc01ce5c8) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\4.\360"..., 512) = 512
fstat64(3, {st_mode=0, st_size=4303557231594, ...}) = 0
mmap(NULL, 1081212, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x402a3000
mmap(0x4039e000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xfa000) = 0x4039e000
mmap(0x403a6000, 20348, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x403a6000
close(3)                                = 0
open("PARISC/libm.so.6", O_RDONLY)      = -1 ENOENT (No such file or directory)
open("libm.so.6", O_RDONLY)             = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/gcc/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/.libs/PARISC/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/.libs/PARISC", 0xc01ce608) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/.libs/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/.libs", 0xc01ce608) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libmudflap/.libs/PARISC/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libmudflap/.libs/PARISC", 0xc01ce608) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libmudflap/.libs/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libmudflap/.libs", {st_mode=0, st_size=4303557231594, ...}) = 0
open("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libssp/.libs/PARISC/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libssp/.libs/PARISC", 0xc01ce608) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libssp/.libs/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libssp/.libs", {st_mode=0, st_size=4303557231594, ...}) = 0
open("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libgomp/.libs/PARISC/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libgomp/.libs/PARISC", 0xc01ce608) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libgomp/.libs/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libgomp/.libs", {st_mode=0, st_size=4303557231594, ...}) = 0
open("/home/dave/gnu/gcc-4.2/objdir/./gcc/PARISC/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/dave/gnu/gcc-4.2/objdir/./gcc/PARISC", 0xc01ce608) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/./gcc/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/dave/gnu/gcc-4.2/objdir/./gcc", {st_mode=0, st_size=4303557231594, ...}) = 0
open("/home/dave/gnu/gcc-4.2/objdir/./prev-gcc/PARISC/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/dave/gnu/gcc-4.2/objdir/./prev-gcc/PARISC", 0xc01ce608) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/./prev-gcc/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/dave/gnu/gcc-4.2/objdir/./prev-gcc", {st_mode=0, st_size=4303557231594, ...}) = 0
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 83644, PROT_READ, MAP_PRIVATE, 3, 0) = 0x403da000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/libm.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\0\226"..., 512) = 512
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40001000
mmap(NULL, 573884, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40031000
mprotect(0x400ab000, 74172, PROT_NONE)  = 0
mmap(0x400ba000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x79000) = 0x400ba000
close(3)                                = 0
open("PARISC/libgcc_s.so.4", O_RDONLY)  = -1 ENOENT (No such file or directory)
open("libgcc_s.so.4", O_RDONLY)         = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/gcc/libgcc_s.so.4", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\0\27"..., 512) = 512
fstat64(3, {st_mode=0, st_size=4303557231594, ...}) = 0
mmap(NULL, 64160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x406ae000
mmap(0x406bd000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe000) = 0x406bd000
close(3)                                = 0
open("PARISC/libc.so.6", O_RDONLY)      = -1 ENOENT (No such file or directory)
open("libc.so.6", O_RDONLY)             = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/gcc/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libmudflap/.libs/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libssp/.libs/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libgomp/.libs/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/./gcc/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/dave/gnu/gcc-4.2/objdir/./prev-gcc/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\1\364"..., 512) = 512
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 1364696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40a63000
mprotect(0x40b93000, 119512, PROT_NONE) = 0
mmap(0x40ba2000, 53248, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12f000) = 0x40ba2000
mmap(0x40baf000, 4824, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40baf000
close(3)                                = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40002000
mmap(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40004000
munmap(0x403da000, 83644)               = 0
brk(0)                                  = 0x13000
brk(0x34000)                            = 0x34000
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40dd5000
mmap2(NULL, 835584, PROT_READ, MAP_PRIVATE, 3, 0x3116) = 0x405d5000
close(3)                                = 0
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 3
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 21568, PROT_READ, MAP_SHARED, 3, 0) = 0x40752000
close(3)                                = 0
open("/usr/lib/gconv/BIG5.so", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\0\10"..., 512) = 512
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 149404, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x401db000
mprotect(0x401f0000, 63388, PROT_NONE)  = 0
mmap(0x401ff000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0x401ff000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40008000
write(2, "4.xg: /home/dave/gnu/gcc-4.2/gcc"..., 1674.xg: /home/dave/gnu/gcc-4.2/gcc/libstdc++-v3/testsuite/22_locale/time_get/get_date/wchar_t/4.cc:55: void test01(): Assertion `errorstate == ios_base::eofbit' failed.
) = 167
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
getpid()                                = 16763
kill(16763, SIGABRT)                    = 0
--- SIGABRT (Aborted) @ 0 (0) ---
+++ killed by SIGABRT (core dumped) +++
Process 16763 detached

Re: [parisc-linux] killing a set of user processes causes system

[Helge Deller]

Hi Dave,

On Wednesday 20 December 2006 16:06, John David Anglin wrote:
> > The old patch didn't catched all syscalls and cases, e.g. all string-ops weren't handled.
> > Maybe you could git-pull and try again ?
> 
> This is looking promising.  su works and I had a full build of GCC
> last night without any hung java processes.  I still had one test
> failure in the libstdc++-v3 testsuite

That's great !

> FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
> 
> which may be a kernel problem since the fail doesn't occur using
> a 64-bit kernel.  The test also doesn't fail under hpux, so it's
> not likely a compilation issue.  The problem is in setting a
> date/time string.  Might have something to do with locale functions.

Can you provide an strace ?
 
> Also, X is broken again.  It seems the card is outputing at higher
> scan rate than the card can handle after X starts (no problem
> with penguin).  However, the rate shown in the log file seems fine:
> 
> (II) Setting vga for screen 0.
> (**) FBDEV(0): Depth 8, (--) framebuffer bpp 8
> (==) FBDEV(0): Default visual is PseudoColor
> (==) FBDEV(0): Using gamma correction (1.0, 1.0, 1.0)
> (II) FBDEV(0): hardware: stifb (video memory: 2048kB)
> (II) FBDEV(0): checking modes against framebuffer device...
> (II) FBDEV(0):  mode "1280x1024" ok
> (II) FBDEV(0): checking modes against monitor...
> (--) FBDEV(0): Virtual size is 1280x1024 (pitch 1280)
> (**) FBDEV(0):  Default mode "1280x1024": 108.0 MHz (scaled from 0.0 MHz), 64.0
> kHz, 60.0 Hz
> (II) FBDEV(0): Modeline "1280x1024"  108.00  1280 1328 1440 1688  1024 1025 1028
>  1066 +hsync +vsync
> 
> The monitor runs just fine at 64.0 kHz, 60 Hz.  The monitor says the
> output mode of the VIS EG is about 90 kHz, 75 Hz.
> 
> Don't think this has anything to do with your patch since older kernels
> have same problem.  However, thought you might have a suggestion as
> to what's wrong.  Running unstable.

That seems to be a generic problem in the Xorg FBDEV driver. I saw this problem as well.
It has nothing to do with monitor frequencies, since the FBDEV (Framebuffer device driver) can't change the monitor/graphics card frequencies anyway.
So I assume it's more a problem of FBDEV picking the wrong line length (which is always 2048 bytes).

I'll look into this when I find time, but compiling X is not my favorite task :-)

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

Re: [parisc-linux] killing a set of user processes causes system

[John David Anglin]

> The old patch didn't catched all syscalls and cases, e.g. all string-ops weren't handled.
> Maybe you could git-pull and try again ?

This is looking promising.  su works and I had a full build of GCC
last night without any hung java processes.  I still had one test
failure in the libstdc++-v3 testsuite

FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test

which may be a kernel problem since the fail doesn't occur using
a 64-bit kernel.  The test also doesn't fail under hpux, so it's
not likely a compilation issue.  The problem is in setting a
date/time string.  Might have something to do with locale functions.

Also, X is broken again.  It seems the card is outputing at higher
scan rate than the card can handle after X starts (no problem
with penguin).  However, the rate shown in the log file seems fine:

(II) Setting vga for screen 0.
(**) FBDEV(0): Depth 8, (--) framebuffer bpp 8
(==) FBDEV(0): Default visual is PseudoColor
(==) FBDEV(0): Using gamma correction (1.0, 1.0, 1.0)
(II) FBDEV(0): hardware: stifb (video memory: 2048kB)
(II) FBDEV(0): checking modes against framebuffer device...
(II) FBDEV(0):  mode "1280x1024" ok
(II) FBDEV(0): checking modes against monitor...
(--) FBDEV(0): Virtual size is 1280x1024 (pitch 1280)
(**) FBDEV(0):  Default mode "1280x1024": 108.0 MHz (scaled from 0.0 MHz), 64.0
kHz, 60.0 Hz
(II) FBDEV(0): Modeline "1280x1024"  108.00  1280 1328 1440 1688  1024 1025 1028
 1066 +hsync +vsync

The monitor runs just fine at 64.0 kHz, 60 Hz.  The monitor says the
output mode of the VIS EG is about 90 kHz, 75 Hz.

Don't think this has anything to do with your patch since older kernels
have same problem.  However, thought you might have a suggestion as
to what's wrong.  Running unstable.

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

Re: [parisc-linux] killing a set of user processes causes system

[Helge Deller]

Hi Dave,

On Monday 18 December 2006 21:17, John David Anglin wrote:
> > this is an updated patch, where only the absolute necessary pieces were changed.
> 
> The patch doesn't help.  Still getting hung java processes.

I just committed the final working patch to the parisc git-tree:
http://git.parisc-linux.org/?p=linux-2.6.git;a=commitdiff;h=0590a4f2beee1d489050cb0ca035294892a46a40
The old patch didn't catched all syscalls and cases, e.g. all string-ops weren't handled.
Maybe you could git-pull and try again ?

Helge

PS: Many thanks to Willy who helped me finding the real fix!
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] killing a set of user processes causes system

[Helge Deller]

On Saturday 16 December 2006 22:17, Helge Deller wrote:
> On Saturday 16 December 2006 22:10, John David Anglin wrote:
> > > > If not, maybe you could try my (ugly & temporary) kernel patch from http://lists.parisc-linux.org/pipermail/parisc-linux/2006-December/030967.html ?
> > > 
> > > I'll give it a try.
> > 
> > I get a bunch of messages like:
> > WARNING: "show_stack" [net/ipv6/ipv6.ko] undefined!
> 
> disable ipv6 for now... The problem is show_stack() in access_ok().
> I don't use modules atm.

this is an updated patch, where only the absolute necessary pieces were changed.
It applies to current git tree...

Helge

diff --git a/arch/parisc/lib/memcpy.c b/arch/parisc/lib/memcpy.c
index 5575e41..72a873d 100644
--- a/arch/parisc/lib/memcpy.c
+++ b/arch/parisc/lib/memcpy.c
@@ -56,6 +56,7 @@
 #include <linux/module.h>
 #include <linux/compiler.h>
 #include <asm/uaccess.h>
+#include <asm/io.h>
 #define s_space "%%sr1"
 #define d_space "%%sr2"
 #else
@@ -488,23 +489,37 @@ handle_store_error:
 #ifdef __KERNEL__
 unsigned long copy_to_user(void __user *dst, const void *src, unsigned long len)
 {
-	mtsp(get_kernel_space(), 1);
-	mtsp(get_user_space(), 2);
-	return pa_memcpy((void __force *)dst, src, len);
+	BUG_ON((long) len < 0);
+	if (access_ok(VERIFY_WRITE, dst, len)) {
+		mtsp(get_kernel_space(), 1);
+		mtsp(get_user_space(), 2);
+		len = pa_memcpy((void __force *)dst, src, len);
+	};
+	return len;
 }
 
 unsigned long copy_from_user(void *dst, const void __user *src, unsigned long len)
 {
-	mtsp(get_user_space(), 1);
-	mtsp(get_kernel_space(), 2);
-	return pa_memcpy(dst, (void __force *)src, len);
+	BUG_ON((long) len < 0);
+	if (access_ok(VERIFY_READ, src, len)) {
+		mtsp(get_user_space(), 1);
+		mtsp(get_kernel_space(), 2);
+		len = pa_memcpy(dst, (void __force *)src, len);
+	} else
+		memset(dst, 0, len);
+	return len;
 }
 
 unsigned long copy_in_user(void __user *dst, const void __user *src, unsigned long len)
 {
-	mtsp(get_user_space(), 1);
-	mtsp(get_user_space(), 2);
-	return pa_memcpy((void __force *)dst, (void __force *)src, len);
+	BUG_ON((long) len < 0);
+        if (likely(access_ok(VERIFY_READ, src, len) &&
+            access_ok(VERIFY_WRITE, dst, len))) {
+		mtsp(get_user_space(), 1);
+		mtsp(get_user_space(), 2);
+		len = pa_memcpy((void __force *)dst, (void __force *)src, len);
+	}
+	return len;
 }
 
 
@@ -516,6 +531,24 @@ void * memcpy(void * dst,const void *src
 	return dst;
 }
 
+long access_ok(int type, const void __user * addr, unsigned long size)
+{
+	unsigned long a = (unsigned long __force) addr;
+	long ok;
+
+	if (segment_eq(get_fs(),KERNEL_DS))
+		ok = 1;
+	else
+		ok = (a < F_EXTEND(0xfff00000));
+	if (unlikely(!ok)) {
+		printk(KERN_ERR "function %s() FAILED for addr=%p len=%lx\n", __FUNCTION__, addr, size);
+		show_stack(NULL,NULL);
+	}
+	return (ok);
+}
+EXPORT_SYMBOL(access_ok);
+
+
 EXPORT_SYMBOL(copy_to_user);
 EXPORT_SYMBOL(copy_from_user);
 EXPORT_SYMBOL(copy_in_user);
diff --git a/include/asm-parisc/uaccess.h b/include/asm-parisc/uaccess.h
index 2e87e82..3dbac23 100644
--- a/include/asm-parisc/uaccess.h
+++ b/include/asm-parisc/uaccess.h
@@ -33,14 +33,7 @@ extern int __get_user_bad(void);
 extern int __put_kernel_bad(void);
 extern int __put_user_bad(void);
 
-static inline long access_ok(int type, const void __user * addr,
-		unsigned long size)
-{
-	return 1;
-}
-
-#define put_user __put_user
-#define get_user __get_user
+long access_ok(int type, const void __user * addr, unsigned long size);
 
 #if BITS_PER_LONG == 32
 #define LDD_KERNEL(ptr)		__get_kernel_bad();
@@ -254,6 +247,21 @@ struct exception_data {
 #endif /* !__LP64__ */
 
 
+/* Uh, these should become the main single-value transfer routines..
+ * They automatically use the right size if we just have the right
+ * pointer type..
+ */
+#define put_user(x,ptr) ({				\
+	__chk_user_ptr(ptr);				\
+	likely(access_ok(0,ptr,sizeof(*(ptr)))) ?	\
+	 __put_user(x,ptr) : -EFAULT; })
+
+#define get_user(x,ptr) ({				\
+	__chk_user_ptr(ptr);				\
+	likely(access_ok(0,ptr,sizeof(*(ptr)))) ?	\
+	__get_user(x,ptr) : ({ x=0; -EFAULT;});  })
+
+
 /*
  * Complex access routines -- external declarations
  */
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] killing a set of user processes causes system

[Helge Deller]

On Saturday 16 December 2006 22:10, John David Anglin wrote:
> > > If not, maybe you could try my (ugly & temporary) kernel patch from http://lists.parisc-linux.org/pipermail/parisc-linux/2006-December/030967.html ?
> > 
> > I'll give it a try.
> 
> I get a bunch of messages like:
> WARNING: "show_stack" [net/ipv6/ipv6.ko] undefined!

disable ipv6 for now... The problem is show_stack() in access_ok().
I don't use modules atm.

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

Re: [parisc-linux] killing a set of user processes causes system

[John David Anglin]

> > If not, maybe you could try my (ugly & temporary) kernel patch from http://lists.parisc-linux.org/pipermail/parisc-linux/2006-December/030967.html ?
> 
> I'll give it a try.

I get a bunch of messages like:
WARNING: "show_stack" [net/ipv6/ipv6.ko] undefined!

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

Re: [parisc-linux] killing a set of user processes causes system

[John David Anglin]

> does it happen on 64bit kernel as well ?

No, just 32-bit.

> If not, maybe you could try my (ugly & temporary) kernel patch from http://lists.parisc-linux.org/pipermail/parisc-linux/2006-December/030967.html ?

I'll give it a try.

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

Re: [parisc-linux] killing a set of user processes causes system

[Matthew Wilcox]

On Thu, Dec 14, 2006 at 02:14:28PM -0500, John David Anglin wrote:
> > Yes. We talked about this before. You have to set up a serial console
> > to your C3K, and issue a SYSRQ-T to show where the process is stuck in
> > the kernel.
> 
> I know but that's a problem.  Can't capture enough info to graphics
> console.  Don't have the right cable for a serial console, so I would
> probably have to build it.  The machine's downtown and I haven't been
> driving for the last two weeks.  Before that, Luxcom was sucking up
> most of my time.

I have a bunch of null-modem cables; you can borrow one if you like.
Heck, if you give me directions (and sort out access permissions),
I can go and install it for you.

> I've now using ethernet consoles for the servers but that's not an
> option for the c3k.  Really, it would be great if it were possible
> to do a SYSRQ-T over a standard ssh link.

Ah, /proc/sysrq-trigger is your friend here.

Best of luck with your eye problems!

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

Re: [parisc-linux] killing a set of user processes causes system

[John David Anglin]

> Yes. We talked about this before. You have to set up a serial console
> to your C3K, and issue a SYSRQ-T to show where the process is stuck in
> the kernel.

I know but that's a problem.  Can't capture enough info to graphics
console.  Don't have the right cable for a serial console, so I would
probably have to build it.  The machine's downtown and I haven't been
driving for the last two weeks.  Before that, Luxcom was sucking up
most of my time.

I've now using ethernet consoles for the servers but that's not an
option for the c3k.  Really, it would be great if it were possible
to do a SYSRQ-T over a standard ssh link.

The reason I haven't been driving is I had an eye operation two weeks
ago to correct a tear in my retina.  Not much warning, just an increase
in the number of floaters in the eye.  So, I booked an eye appointment.
The doctor saw the problem and referred me to another doctor in his
clinic who specializes in retina problems.  He looked at me and referred
me to a doctor at the General who specializes in surgery.  Went in the
same morning to the General and they did the first stage of the procedure
(laser welding + gas bubble to hold the retina in place and to dry out
fluid behind it).

Apparently, if the tear had got much larger, I would have had
to undergo major surgery.  There's no option since the tear would
have progressively got larger resulting in blindness in the eye.  This
problem apparently happens to about 1 in 10000 around 60.  So, far
the results of the surgery seem good but can't be certain until the
gas bubble disappears.

> FYI I've been running gcc builds on my c3k to reproduce this, but I
> haven't seen anything like this.

Java testsuite on head.  I think the binutils testsuite still has
problems when it is run when the machine is under load.

> Sorry to everyone who thinks I fell off the surface of the earth...
> it's true. I'm back on my thesis writing schedule, which means hours
> in the evenings are gone :(
> 
> I have a defense date in March! :)

Hey, spring graduation!  Good luck.

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