[parisc-linux-cvs] DIFF 2.6.0-test5-pa6 cleanup round 2

[Grant Grundler]

On Sun, Sep 14, 2003 at 12:42:27AM -0600, Grant Grundler wrote:
> Linux version 2.6.0-test5-pa5 (grundler@gsyprf11.external.hp.com) (gcc version 3
...

> EXT3 FS on sda3, internal journal
> ip_conntrack version 2.1 (3992 buckets, 31936 max) - 440 bytes per conntrack
> kjournald starting.  Commit interval 5 seconds
> EXT3 FS on sda4, internal journal
> EXT3-fs: mounted filesystem with ordered data mode.
> drivers/usb/core/usb.c: registered new driver usbfs
> drivers/usb/core/usb.c: registered new driver hub
> drivers/usb/core/usb.c: deregistering driver usbfs
> drivers/usb/core/usb.c: deregistering driver hub
> ip_tables: (C) 2000-2002 Netfilter core team
> 
> Stack Dump:
...

> Kernel addresses on the stack:
>  [<0000000010161d94>]  [<000000001017a500>]  [<000000001019b6d8>]  [<0000000010
>  [<000000001019b6d8>]  [<0000000010161d94>]  [<00000000000a9da0>]  [<0000000010
>  [<00000000000aa1ac>]  [<00000000102fe06c>]  [<000000001016155c>]  [<0000000010
>  [<0000000010313094>]  [<000000001010d89c>]  [<0000000010170884>]  [<0000000010
>  [<000000001017100c>]  [<00000000103351fc>]  [<000000001033fe2c>]  [<0000000010
>  [<00000000102ffce4>]  [<000000001010ef1c>]  [<00000000102fff6c>]  [<0000000010
>  [<000000001010a094>]

0x10161d94 __free_pages+e4
0x1017a500 map_area_pte+e0
0x1019b6d8 locate_fd+130
0x1019b6d8 locate_fd+130
0x10161d94 __free_pages+e4
0xa9da0 _DYNAMIC+a9da0			<-- any clue what this is?  See GR02
0x102fe06c nf_sockopt+2b4
0x1016155c buffered_rmqueue+e4
0x10313094 ip_setsockopt+adc
0x1010d89c update_mmu_cache+4c
0x10170884 do_anonymous_page+25c
0x1017100c do_no_page+65c
0x103351fc raw_setsockopt+4c
0x1033fe2c inet_setsockopt+3c
0x102ffce4 do_netfilter_replace+25c
0x1010ef1c handle_interruption+2ec
0x102fff6c compat_sys_setsockopt+5c
0x1010a094 intr_check_sig+0

> Kernel Fault: Code=15 regs=000000004f250b80 (Addr=000000000002f838)

code 15 == Data page fault

> 
>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00001000000011000000000000001111 Not tainted
> r00-03  0000000000000000 0000000000000000 00000000000a9dc0 00000000000a6000

GR02 is the return address. WTH is 0x000a9dc0?

> r04-07  00000000000a6000 0000000000000070 00000000000987b0 0000000000098000
> r08-11  00000000000a6000 0000000000000820 00000000000a6000 000000000009a000
> r12-15  0000000000000003 0000000000000000 0000000000000040 00000000faf00548
> r16-19  00000000faf005d0 0000000000004000 0000000000016000 000000000000002c
> r20-23  000000004ffff170 0000000000000078 0000000000000000 000000000000002d
> r24-27  00000000000000cf 000000000009a001 000000000002f838 0000000010474a20
> r28-31  000000004f2b5d40 000000004f250b70 000000004f250b80 0000000000000000
> sr0-3   0000000000000300 0000000000000000 0000000000000000 0000000000000300
> sr4-7   0000000000000000 0000000000000000 0000000000000000 0000000000000000
> 
> IASQ: 0000000000000000 0000000000000000 IAOQ: 000000001023dd74 000000001023dd6c

ok...here's the victim:

0x1023dd74 $lctu_loop+8

lcopy_to_user:
...
        comib,=,n   0,%r24,$lctu_done
	get_sr
$lctu_loop:
	ldbs,ma     1(%r25),%r1
	addib,<>    -1,%r24,$lctu_loop
1:      stbs,ma     %r1,1(%sr1,%r26)
$lctu_done:
        bv          %r0(%r2)
        copy        %r24,%r28

(sr1,r26) don't point to a valid address.
Someone needs to look get_sr and understand if/how TI_SEGMENT
flag should have been set (or cleared). Considering this is
copy *to* user, I would expect SR1 to be non-zero...unless
"user" in this case already has a kernel mapped address.

grant


>  IIR: 0f415222    ISR: 0000000000000000  IOR: 000000000002f838
>  CPU:        0   CR30: 000000004f250000 CR31: 000000001043f000
>  ORIG_R28: 000000004f250d00
> <2><2>