[OpenAFS-devel] Linux 2.6.12 kernel BUG at fs/namei.c:1189
Russ Allbery
rra@stanford.edu
Sat, 10 Dec 2005 16:30:23 -0800
Sent separately to openafs-devel and to openafs-bugs.
Russ Allbery <rra@stanford.edu> writes:
> Has anyone seen this before? I was moving a volume mount point using mv
> and got a segfault from mv and the following kernel BUG message in dmesg
> (which I've run through ksymoops).
Looks like this is to some degree reproducible. I rebooted and started
moving things around again, didn't have trouble for a while, and then got
another segfault from mv and another BUG report.
(I'm not sure why I don't have a /proc/ksyms.)
We were seeing this problem on another system as well, earlier, but
weren't sure why and other systems running the same version of the kernel
module didn't have trouble. I just started seeing it after upgrading to
a kernel module built from the latest Debian 1.4.0-2 packages. There
aren't any patches in the kernel code relative to the 1.4.0 release.
ksymoops 2.4.9 on i686 2.6.12-1-686. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.6.12-1-686/ (default)
-m /boot/System.map-2.6.12-1-686 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Error (regular_file): read_ksyms stat /proc/ksyms failed
ksymoops: No such file or directory
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
kernel BUG at fs/namei.c:1189!
invalid operand: 0000 [#1]
CPU: 0
EIP: 0060:[<c016a0c0>] Tainted: P VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010283 (2.6.12-1-686)
eax: e30017c4 ebx: ffffffd9 ecx: df4fa354 edx: 00000001
esi: e8bd4d80 edi: de5e98d4 ebp: df4fa2fc esp: de71dedc
ds: 007b es: 007b ss: 0068
Stack: 00000000 ffffffea dea95000 def42000 00000001 ffffffd9 dea95000 def42000
de71df68 c016a3b3 e8bd4d80 de5e98d4 e8bd4d80 df4fa2fc f704c8d4 f704c8d4
de5e98d4 df4fa2fc 00000000 f704c8d4 dfff4d00 547eeb27 00000019 def42000
Call Trace:
[<c016a3b3>] sys_rename+0x1f3/0x230
[<c01627d8>] sys_lstat64+0x18/0x40
[<c01030c5>] syscall_call+0x7/0xb
Code: 44 24 30 f6 80 0c 01 00 00 04 0f 84 7b fd ff ff ba 04 00 00 00 89 54 24 04 89 04 24 e8 da e2 01 00 e9 4f fd ff ff 90 8d 74 26 00 <0f> 0b a5 04 53 a6 2b c0 e9 20 fd ff ff c7 04 24 03 00 00 00 e8
>>EIP; c016a0c0 <vfs_rename+320/420> <=====
>>eax; e30017c4 <pg0+22c477c4/3fc44400>
>>ebx; ffffffd9 <__kernel_rt_sigreturn+1b99/????>
>>ecx; df4fa354 <pg0+1f140354/3fc44400>
>>esi; e8bd4d80 <pg0+2881ad80/3fc44400>
>>edi; de5e98d4 <pg0+1e22f8d4/3fc44400>
>>ebp; df4fa2fc <pg0+1f1402fc/3fc44400>
>>esp; de71dedc <pg0+1e363edc/3fc44400>
Trace; c016a3b3 <sys_rename+1f3/230>
Trace; c01627d8 <sys_lstat64+18/40>
Trace; c01030c5 <syscall_call+7/b>
This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.
Code; c016a095 <vfs_rename+2f5/420>
00000000 <_EIP>:
Code; c016a095 <vfs_rename+2f5/420>
0: 44 inc %esp
Code; c016a096 <vfs_rename+2f6/420>
1: 24 30 and $0x30,%al
Code; c016a098 <vfs_rename+2f8/420>
3: f6 80 0c 01 00 00 04 testb $0x4,0x10c(%eax)
Code; c016a09f <vfs_rename+2ff/420>
a: 0f 84 7b fd ff ff je fffffd8b <_EIP+0xfffffd8b>
Code; c016a0a5 <vfs_rename+305/420>
10: ba 04 00 00 00 mov $0x4,%edx
Code; c016a0aa <vfs_rename+30a/420>
15: 89 54 24 04 mov %edx,0x4(%esp)
Code; c016a0ae <vfs_rename+30e/420>
19: 89 04 24 mov %eax,(%esp)
Code; c016a0b1 <vfs_rename+311/420>
1c: e8 da e2 01 00 call 1e2fb <_EIP+0x1e2fb>
Code; c016a0b6 <vfs_rename+316/420>
21: e9 4f fd ff ff jmp fffffd75 <_EIP+0xfffffd75>
Code; c016a0bb <vfs_rename+31b/420>
26: 90 nop
Code; c016a0bc <vfs_rename+31c/420>
27: 8d 74 26 00 lea 0x0(%esi),%esi
This decode from eip onwards should be reliable
Code; c016a0c0 <vfs_rename+320/420>
00000000 <_EIP>:
Code; c016a0c0 <vfs_rename+320/420> <=====
0: 0f 0b ud2a <=====
Code; c016a0c2 <vfs_rename+322/420>
2: a5 movsl %ds:(%esi),%es:(%edi)
Code; c016a0c3 <vfs_rename+323/420>
3: 04 53 add $0x53,%al
Code; c016a0c5 <vfs_rename+325/420>
5: a6 cmpsb %es:(%edi),%ds:(%esi)
Code; c016a0c6 <vfs_rename+326/420>
6: 2b c0 sub %eax,%eax
Code; c016a0c8 <vfs_rename+328/420>
8: e9 20 fd ff ff jmp fffffd2d <_EIP+0xfffffd2d>
Code; c016a0cd <vfs_rename+32d/420>
d: c7 04 24 03 00 00 00 movl $0x3,(%esp)
Code; c016a0d4 <vfs_rename+334/420>
14: e8 .byte 0xe8
1 warning and 1 error issued. Results may not be reliable.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>