2000-11-24 11:26:00

by Mark Ellis

[permalink] [raw]
Subject: OOPS on bringing down ppp

Hi all, consistently getting the following when pppd is terminated. Happens
in 2.4.0-test11, fine in 2.4.0-test9, don't know about test10. Same happens
for pppd 2.4.0b4 and 2.4.0, both recompiled for test11. Is this related to
the modutils incompatability (modutils 2.3.19) ?

CONFIG_PPP and CONFIG_PPP_ASYNC are built in, CONFIG_PPP_DEFLATE and
CONFIG_PPP_BSDCOMP as modules, but oopses whether they are loaded or not.

ksymoops 2.3.4 on i686 2.4.0-test11. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test11/ (default)
-m /usr/src/linux/System.map (specified)

Warning (compare_maps): snd symbol pm_register not found in
/lib/modules/2.4.0-test11/sound/snd.o. Ignoring
/lib/modules/2.4.0-test11/sound/snd.o entry
Warning (compare_maps): snd symbol pm_send not found in
/lib/modules/2.4.0-test11/sound/snd.o. Ignoring
/lib/modules/2.4.0-test11/sound/snd.o entry
Warning (compare_maps): snd symbol pm_unregister not found in
/lib/modules/2.4.0-test11/sound/snd.o. Ignoring
/lib/modules/2.4.0-test11/sound/snd.o entry
c0114c6c
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<c0114c6c>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: c4bb1544 ebx: c4e72000 ecx: c5fe83a0 edx: 00000000
esi: 00000006 edi: 00000000 ebp: c5fe83a0 esp: c4e73fb8
ds: 0018 es: 0018 ss: 0018
Process pppd (pid: 1099, stackpage=c4e73000)
Stack: 00000100 c4e6delc c4e6de4c c5b27e20 c5fe83a0 c11c35c0 c11c35c0
c11c35c0 c11c35c0 c0114f60 c0225f60 c4e6dedc c4e6dec8 c0108914
c4e6de4c 00000078 c4e6dedc
Call Trace: [<c0114f60>] [<c0108914>]
Code: 8b 4f 08 39 ca 7d 22 8b 47 14 83 3c 90 00 74 14 89 f0 89 d3

>>EIP; c0114c6c <exec_usermodehelper+29c/368> <=====
Trace; c0114f60 <exec_helper+14/18>
Trace; c0108914 <kernel_thread+28/38>
Code; c0114c6c <exec_usermodehelper+29c/368>
00000000 <_EIP>:
Code; c0114c6c <exec_usermodehelper+29c/368> <=====
0: 8b 4f 08 mov 0x8(%edi),%ecx <=====
Code; c0114c6f <exec_usermodehelper+29f/368>
3: 39 ca cmp %ecx,%edx
Code; c0114c71 <exec_usermodehelper+2a1/368>
5: 7d 22 jge 29 <_EIP+0x29> c0114c95
<exec_usermodehelper+2c5/368>
Code; c0114c73 <exec_usermodehelper+2a3/368>
7: 8b 47 14 mov 0x14(%edi),%eax
Code; c0114c76 <exec_usermodehelper+2a6/368>
a: 83 3c 90 00 cmpl $0x0,(%eax,%edx,4)
Code; c0114c7a <exec_usermodehelper+2aa/368>
e: 74 14 je 24 <_EIP+0x24> c0114c90
<exec_usermodehelper+2c0/368>
Code; c0114c7c <exec_usermodehelper+2ac/368>
10: 89 f0 mov %esi,%eax
Code; c0114c7e <exec_usermodehelper+2ae/368>
12: 89 d3 mov %edx,%ebx


3 warnings issued. Results may not be reliable.


Any ideas ?

Mark



2000-11-24 12:58:59

by Andrew Morton

[permalink] [raw]
Subject: Re: OOPS on bringing down ppp

Mark Ellis wrote:
>
> Hi all, consistently getting the following when pppd is terminated.

When pppd downs the ppp0 device, unregister_netdevice() is
trying to run /sbin/hotplug in a new kernel thread. That
thread's `files' structure is copied from pppd, but it is
NULL. Presumably pppd's files pointer was also NULL.

Try this:

--- linux-2.4.0-test11-ac2/kernel/kmod.c Tue Nov 21 20:11:21 2000
+++ linux-akpm/kernel/kmod.c Fri Nov 24 23:03:34 2000
@@ -99,8 +99,10 @@
flush_signal_handlers(current);
spin_unlock_irq(&current->sigmask_lock);

- for (i = 0; i < current->files->max_fds; i++ ) {
- if (current->files->fd[i]) close(i);
+ if (current->files) {
+ for (i = 0; i < current->files->max_fds; i++ ) {
+ if (current->files->fd[i]) close(i);
+ }
}

/* Drop the "current user" thing */


Not my area, but I don't think exec_usermodehelper() should assume
that current->files is always valid.

Al, is this correct? If so, does daemonize() also need this test?
If not, then how did this thread get (current->files == NULL)?

2000-11-24 14:19:31

by Keith Owens

[permalink] [raw]
Subject: Re: OOPS on bringing down ppp

On Fri, 24 Nov 2000 10:55:39 +0000,
Mark Ellis <[email protected]> wrote:
>Hi all, consistently getting the following when pppd is terminated. Happens
>in 2.4.0-test11, fine in 2.4.0-test9, don't know about test10. Same happens
>for pppd 2.4.0b4 and 2.4.0, both recompiled for test11. Is this related to
>the modutils incompatability (modutils 2.3.19) ?

I don't think so. I cannot reproduce this oops on 2.4.0-test11 with
modutils 2.3.21, ppp 2.4.0. modutils 2.3.19 should be compatible with
kernel 2.4.0-test11, the incompatibility is between modutils <= 2.3.15
and kernel 2.4.0-test11.

It was difficult to find the right area of code, my compile with
egcs-2.91.66 and -march=i686 gives quite different Assembler, so take
this analysis with a pinch of salt. Is there any chance that you are
using the wrong compiler and/or compiler options?

The oops looks to be on line 102 of kmod.c

for (i = 0; i < current->files->max_fds; i++ ) {

current->files is NULL. That has nothing to do with modutils, rather
it points to an invalid or incomplete current context.

2000-11-24 14:35:10

by Alan Cox

[permalink] [raw]
Subject: Re: OOPS on bringing down ppp

> Not my area, but I don't think exec_usermodehelper() should assume
> that current->files is always valid.
>
> Al, is this correct? If so, does daemonize() also need this test?
> If not, then how did this thread get (current->files == NULL)?

exit_files() will leave it NULL yes. You may want to borrow (inherit ;)) the
files from init_task

2000-11-24 22:46:55

by Marc Heckmann

[permalink] [raw]
Subject: Re: OOPS on bringing down ppp

On Fri, Nov 24, 2000 at 10:55:39AM +0000, Mark Ellis wrote:
> Hi all, consistently getting the following when pppd is terminated. Happens
> in 2.4.0-test11, fine in 2.4.0-test9, don't know about test10. Same happens
> for pppd 2.4.0b4 and 2.4.0, both recompiled for test11. Is this related to
> the modutils incompatability (modutils 2.3.19) ?

I get the same oops w/ 2.4.0-test11pre7, pppd-2.3.11 and pppd-2.4.0, not
quite sure if it happens on _every_ pppd termination, but it does happen
a lot. Modutils-2.3.2[01]. ksymoops below, notice that it is preceded by
a waitpid failed, don't wether it is important or not... My kernel is
compiled on a fairly stock RH-7.0 with kgcc.

system:

-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux fsck.ikr.org 2.4.0-test11 #2 Sun Nov 19 00:16:38 EST 2000 i586
unknown
Kernel modules 2.3.20
Gnu C egcs-2.91.66
Gnu Make 3.79.1
Binutils 2.10.0.18
Linux C Library 2.1.94
Dynamic linker ldd (GNU libc) 2.1.94
Procps 2.0.7
Mount 2.10m
Net-tools 1.56
Console-tools 0.3.3
Sh-utils 2.0
Modules Loaded ppp_deflate bsd_comp ppp_async ppp_generic slhc
ide-cd cdrom soundcore de4x5 raid1 BusLogic


Nov 23 16:05:13 fsck kernel: waitpid(1808) failed, -512
Nov 23 16:05:13 fsck kernel: Unable to handle kernel NULL pointer
dereference at
virtual address 00000008
Nov 23 16:05:13 fsck kernel: printing eip:
Nov 23 16:05:13 fsck kernel: c011556e
Nov 23 16:05:13 fsck kernel: *pde = 00000000
Nov 23 16:05:13 fsck kernel: Oops: 0000
Nov 23 16:05:13 fsck kernel: CPU: 0
Nov 23 16:05:13 fsck kernel: EIP: 0010:[exec_usermodehelper+734/944]
Nov 23 16:05:13 fsck kernel: EFLAGS: 00010246
Nov 23 16:05:13 fsck kernel: eax: 00000000 ebx: c1177b20 ecx: c1fb4fb0
edx: c1fb4fa4
Nov 23 16:05:13 fsck kernel: esi: c2694000 edi: c2694000 ebp: 00000000
esp: c2695fb0
Nov 23 16:05:13 fsck kernel: ds: 0018 es: 0018 ss: 0018
Nov 23 16:05:13 fsck kernel: Process pppd (pid: 1808, stackpage=c2695000)
Nov 23 16:05:13 fsck kernel: Stack: 00000100 c34e7d90 c34e6000 c1a640c0
c3eca9a0 c36fc160 c1177b20 c3eca9a0
Nov 23 16:05:13 fsck kernel: c3eca9a0 c1177b20 c3eca9a0 c3eca9a0
c0115890 c0222840 c34e7e4c c34e7e38
Nov 23 16:05:13 fsck kernel: c0108e87 c34e7dbc c34e7dbc c34e7e4c
Nov 23 16:05:13 fsck kernel: Call Trace: [exec_helper+20/24]
[kernel_thread+35/48]
Nov 23 16:05:13 fsck kernel: Code: 3b 68 08 7d 2a 8b 40 14 83 3c a8 00 74
15 b8 06 00 00 00 89


ksymoops:

ksymoops 2.3.5 on i586 2.2.16-22. Options used
-v /usr/src/linux/vmlinux (specified)
-K (specified)
-L (specified)
-o /lib/modules/2.4.0-test11/ (specified)
-m /usr/src/linux/System.map (specified)

No modules in ksyms, skipping objects
Nov 23 16:05:13 fsck kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000008
Nov 23 16:05:13 fsck kernel: c011556e
Nov 23 16:05:13 fsck kernel: *pde = 00000000
Nov 23 16:05:13 fsck kernel: Oops: 0000
Nov 23 16:05:13 fsck kernel: CPU: 0
Nov 23 16:05:13 fsck kernel: EIP: 0010:[exec_usermodehelper+734/944]
Nov 23 16:05:13 fsck kernel: EFLAGS: 00010246
Nov 23 16:05:13 fsck kernel: eax: 00000000 ebx: c1177b20 ecx: c1fb4fb0
edx: c1fb4fa4
Nov 23 16:05:13 fsck kernel: esi: c2694000 edi: c2694000 ebp: 00000000
esp: c2695fb0
Nov 23 16:05:13 fsck kernel: ds: 0018 es: 0018 ss: 0018
Nov 23 16:05:13 fsck kernel: Process pppd (pid: 1808, stackpage=c2695000)
Nov 23 16:05:13 fsck kernel: Stack: 00000100 c34e7d90 c34e6000 c1a640c0
c3eca9a0 c36fc160 c1177b20 c3eca9a0
Nov 23 16:05:13 fsck kernel: c3eca9a0 c1177b20 c3eca9a0 c3eca9a0
c0115890 c0222840 c34e7e4c c34e7e38
Nov 23 16:05:13 fsck kernel: c0108e87 c34e7dbc c34e7dbc c34e7e4c
Nov 23 16:05:13 fsck kernel: Call Trace: [exec_helper+20/24]
[kernel_thread+35/48]
Nov 23 16:05:13 fsck kernel: Code: 3b 68 08 7d 2a 8b 40 14 83 3c a8 00 74
15 b8 06 00 00 00 89
Using defaults from ksymoops -t elf32-i386 -a i386

Code; 00000000 Before first symbol
00000000 <_EIP>:
Code; 00000000 Before first symbol
0: 3b 68 08 cmp 0x8(%eax),%ebp
Code; 00000003 Before first symbol
3: 7d 2a jge 2f <_EIP+0x2f> 0000002f Before
first symbol
Code; 00000005 Before first symbol
5: 8b 40 14 mov 0x14(%eax),%eax
Code; 00000008 Before first symbol
8: 83 3c a8 00 cmpl $0x0,(%eax,%ebp,4)
Code; 0000000c Before first symbol
c: 74 15 je 23 <_EIP+0x23> 00000023 Before
first symbol
Code; 0000000e Before first symbol
e: b8 06 00 00 00 mov $0x6,%eax
Code; 00000013 Before first symbol
13: 89 00 mov %eax,(%eax)

-Marc

> CONFIG_PPP and CONFIG_PPP_ASYNC are built in, CONFIG_PPP_DEFLATE and
> CONFIG_PPP_BSDCOMP as modules, but oopses whether they are loaded or not.
>
> ksymoops 2.3.4 on i686 2.4.0-test11. Options used
> -V (default)
> -k /proc/ksyms (default)
> -l /proc/modules (default)
> -o /lib/modules/2.4.0-test11/ (default)
> -m /usr/src/linux/System.map (specified)
>
> Warning (compare_maps): snd symbol pm_register not found in
> /lib/modules/2.4.0-test11/sound/snd.o. Ignoring
> /lib/modules/2.4.0-test11/sound/snd.o entry
> Warning (compare_maps): snd symbol pm_send not found in
> /lib/modules/2.4.0-test11/sound/snd.o. Ignoring
> /lib/modules/2.4.0-test11/sound/snd.o entry
> Warning (compare_maps): snd symbol pm_unregister not found in
> /lib/modules/2.4.0-test11/sound/snd.o. Ignoring
> /lib/modules/2.4.0-test11/sound/snd.o entry
> c0114c6c
> *pde = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<c0114c6c>]
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010246
> eax: c4bb1544 ebx: c4e72000 ecx: c5fe83a0 edx: 00000000
> esi: 00000006 edi: 00000000 ebp: c5fe83a0 esp: c4e73fb8
> ds: 0018 es: 0018 ss: 0018
> Process pppd (pid: 1099, stackpage=c4e73000)
> Stack: 00000100 c4e6delc c4e6de4c c5b27e20 c5fe83a0 c11c35c0 c11c35c0
> c11c35c0 c11c35c0 c0114f60 c0225f60 c4e6dedc c4e6dec8 c0108914
> c4e6de4c 00000078 c4e6dedc
> Call Trace: [<c0114f60>] [<c0108914>]
> Code: 8b 4f 08 39 ca 7d 22 8b 47 14 83 3c 90 00 74 14 89 f0 89 d3
>
> >>EIP; c0114c6c <exec_usermodehelper+29c/368> <=====
> Trace; c0114f60 <exec_helper+14/18>
> Trace; c0108914 <kernel_thread+28/38>
> Code; c0114c6c <exec_usermodehelper+29c/368>
> 00000000 <_EIP>:
> Code; c0114c6c <exec_usermodehelper+29c/368> <=====
> 0: 8b 4f 08 mov 0x8(%edi),%ecx <=====
> Code; c0114c6f <exec_usermodehelper+29f/368>
> 3: 39 ca cmp %ecx,%edx
> Code; c0114c71 <exec_usermodehelper+2a1/368>
> 5: 7d 22 jge 29 <_EIP+0x29> c0114c95
> <exec_usermodehelper+2c5/368>
> Code; c0114c73 <exec_usermodehelper+2a3/368>
> 7: 8b 47 14 mov 0x14(%edi),%eax
> Code; c0114c76 <exec_usermodehelper+2a6/368>
> a: 83 3c 90 00 cmpl $0x0,(%eax,%edx,4)
> Code; c0114c7a <exec_usermodehelper+2aa/368>
> e: 74 14 je 24 <_EIP+0x24> c0114c90
> <exec_usermodehelper+2c0/368>
> Code; c0114c7c <exec_usermodehelper+2ac/368>
> 10: 89 f0 mov %esi,%eax
> Code; c0114c7e <exec_usermodehelper+2ae/368>
> 12: 89 d3 mov %edx,%ebx
>
>
> 3 warnings issued. Results may not be reliable.
>
>
> Any ideas ?
>
> Mark
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/

2000-11-26 21:30:54

by Mark Ellis

[permalink] [raw]
Subject: Re: OOPS on bringing down ppp


Nope that didn't help. I'm using gcc 2.95.2, didn't think of it before
since it has never caused me any problems. I'll get around to trying
2.91.66 at some point.

A quick aside, anyone know of a problem with the list, I seem to be being
cut off at random intervals :)

Mark

On Fri, 24 Nov 2000 12:28:44 Andrew Morton wrote:
> Mark Ellis wrote:
> >
> > Hi all, consistently getting the following when pppd is terminated.
>
> When pppd downs the ppp0 device, unregister_netdevice() is
> trying to run /sbin/hotplug in a new kernel thread. That
> thread's `files' structure is copied from pppd, but it is
> NULL. Presumably pppd's files pointer was also NULL.
>
> Try this:
>
> --- linux-2.4.0-test11-ac2/kernel/kmod.c Tue Nov 21 20:11:21 2000
> +++ linux-akpm/kernel/kmod.c Fri Nov 24 23:03:34 2000
> @@ -99,8 +99,10 @@
> flush_signal_handlers(current);
> spin_unlock_irq(&current->sigmask_lock);
>
> - for (i = 0; i < current->files->max_fds; i++ ) {
> - if (current->files->fd[i]) close(i);
> + if (current->files) {
> + for (i = 0; i < current->files->max_fds; i++ ) {
> + if (current->files->fd[i]) close(i);
> + }
> }
>
> /* Drop the "current user" thing */
>
>
> Not my area, but I don't think exec_usermodehelper() should assume
> that current->files is always valid.
>
> Al, is this correct? If so, does daemonize() also need this test?
> If not, then how did this thread get (current->files == NULL)?
>