oops when reading /proc/locks

oops when reading /proc/locks

Post by Burton Windl » Fri, 20 Sep 2002 23:50:05

stock 2.5.36, non-preempt, non-smp.  After enabling and then disabling an
ethernet sniffer, then cat'ting /proc/locks, I can reproduce this oops

 <1>Unable to handle kernel NULL pointer dereference at virtual address 00000008
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0060:[<c01452aa>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 00000000   ebx: 00000000   ecx: 00000400   edx: 00000400
esi: c66c8000   edi: c8c1d894   ebp: c66c8000   esp: c7e77ea8
ds: 0068   es: 0068   ss: 0068
Stack: 00000000 00000001 00000000 c56b9344 00000004 00000400 c8c1d898 c8c1d894
       c01455dc c66c8000 c8c1d894 00000001 c0267b11 00000400 00000001 c66c8000
       00000000 00000400 00000400 00000400 c66c8000 c0155f0a c66c8000 c7e77f3c
Call Trace: [<c01455dc>] [<c0155f0a>] [<c0153a6d>] [<c01336c8>] [<c013ab6b>]
   [<c013389a>] [<c01071cf>]
Code: 8b 58 08 8b 44 24 30 50 8b 4c 24 30 51 68 2a 7a 26 c0 56 e8

Quote:>>EIP; c01452aa <lock_get_status+1a/260>   <=====

Trace; c01455dc <get_locks_status+5c/100>
Trace; c0155f0a <locks_read_proc+1a/40>
Trace; c0153a6d <proc_file_read+19d/1b0>
Trace; c01336c8 <vfs_read+98/120>
Trace; c013ab6b <sys_fstat64+2b/30>
Trace; c013389a <sys_read+2a/40>
Trace; c01071cf <syscall_call+7/b>

Code;  c01452aa <lock_get_status+1a/260>
00000000 <_EIP>:
Code;  c01452aa <lock_get_status+1a/260>   <=====
   0:   8b 58 08                  mov    0x8(%eax),%ebx   <=====
Code;  c01452ad <lock_get_status+1d/260>
   3:   8b 44 24 30               mov    0x30(%esp,1),%eax
Code;  c01452b1 <lock_get_status+21/260>
   7:   50                        push   %eax
Code;  c01452b2 <lock_get_status+22/260>
   8:   8b 4c 24 30               mov    0x30(%esp,1),%ecx
Code;  c01452b6 <lock_get_status+26/260>
   c:   51                        push   %ecx
Code;  c01452b7 <lock_get_status+27/260>
   d:   68 2a 7a 26 c0            push   $0xc0267a2a
Code;  c01452bc <lock_get_status+2c/260>
  12:   56                        push   %esi
Code;  c01452bd <lock_get_status+2d/260>
  13:   e8 00 00 00 00            call   18 <_EIP+0x18> c01452c2

Linux razor 2.5.36 #0 Thu Sep 19 09:32:59 EST 2002 i686 unknown unknown

Gnu C                  3.0.4
Gnu make               3.79.1
util-linux             2.11n
mount                  2.11n
modutils               2.4.15
e2fsprogs              1.27
Linux C Library        2.2.5
Dynamic linker (ldd)   2.2.5
Procps                 2.0.7
Net-tools              1.60
Console-tools          0.2.3
Sh-utils               2.0.12


Linux: the "grim reaper of innocent orphaned children."
          from /usr/src/linux-2.4.18/init/main.c:461

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


oops when reading /proc/locks

Post by Matthew Wilco » Sat, 21 Sep 2002 05:20:06

[note: please cc me or linux-fsdevel when reporting file locking bugs;
i only read linux-kernel on the web and as time permits]

It looks to me like your dereference comes from this line:

        if (fl->fl_file != NULL)
                inode = fl->fl_file->f_dentry->d_inode;

and, if my terribly weak x86 assembler isn't deceiving me, f_dentry
is NULL.  Since you can reproduce this at will, could you insert some
debugging for me?

        if (fl->fl_file != NULL) {
                if (fl->fl_file->f_dentry) {
                        inode = fl->fl_file->f_dentry->d_inode;
                } else {
                        printk(KERN_EMERG "null dentry at %d\n", id);

That will avoid the oops, and tell us who managed to set a file lock on
a file without a dentry.

Revolutions do not require corporate support.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


1. oops while read accessing to /proc/bus/pnp/escd

cat /proc/bus/pnp/escd couses an oops.
oops caused while executing this func.
static int __pnp_bios_read_escd(char *data, u32 nvram_base)
        u16 status;
        if (!pnp_bios_present())
                return ESCD_FUNCTION_NOT_SUPPORTED;
        status = call_pnp_bios(PNP_READ_ESCD, 0, PNP_TS1, PNP_TS2, PNP_DS, 0, 0, 0,
                               data, 65536, (void *)nvram_base, 65536);
        return status;
but i don't have access to my computer and can't send full oops.
I've tried to solve this problem myself, but couldn't.
I think that the problem is in nvram_base because we don't alocate
memory page for it. We get address from pnp_bios_escd_info, but in PnP
BIOS spec wrote that
  "In this case, it is the responsibility of the caller to construct a
16-bit data segment descriptor with base = NVStorageBase, a limit
of 64K and read/write access."
I didn't find something like memory aloc between getting escd info and
calling this func.
Best regards.
PS And please CC patch to me if it'll be fixed before I do it myself.
PS And last, any comments and explanations will be desirable.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Syncs for ATI-Graphics Ultra needed.

3. reading /proc/hermes/eth1/recs causes an oops in 2.5.69

4. Problem with NT integration, PDC

5. New: reading /proc/bus/pnp/escd results in oops

6. 100Mb lan tops out at 1.2Mb ?

7. "Can't read lock file /tmp/.X0-lock"

8. Linux Routing

9. PROPOSAL: /proc standards (was dot-proc interface [was: /proc

10. PROPOSAL: /proc standards (was dot-proc interface [was: /proc stuff])

11. Reader lock-free read/write lock

12. Oops in 2.4.3: cat /proc/tty/driver/serial

13. Oops in /proc/