1.3.26 -> oops in get_write_access

Ricky Beam (jfbeam@lx1.tx.ncsu.edu)
Thu, 14 Sep 1995 05:28:51 -0400 (EDT)

>>> Linux dominion 1.3.26 #1 Thu Sep 14 03:54:12 EDT 1995 i486 <<<

kernel: Unable to handle kernel NULL pointer dereference at virtual address c0000060
kernel: current->tss.cr3 = 01116000, Kr3 = 01116000
kernel: *pde = 00102067
kernel: *pte = 00000027
kernel: Oops: 0000
kernel: EIP: 0010:001305fd (fs/namei.c:get_write_access)
kernel: EFLAGS: 00010202
kernel: eax: 00000000 ebx: 0008c4b0 ecx: 0116a460 edx: 001c0560
kernel: esi: 00000000 edi: 0116a460 ebp: bffff910 esp: 010e8f88
kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
kernel: Process lpd (pid: 83, process nr: 17, stackpage=010e8000)
kernel: Stack: 0012584b 0116a460 00000000 bffff994 00009044 0116a460 00125968 010df000
kernel: 00000041 000001a4 0122a018 010df000 0010af69 00003516 00000041 000001a4
kernel: bffff994 00009044 bffff910 ffffffda 0002002b 0004002b 0000002b 0000002b
kernel: Call Trace: 0012584b 00125968 0010af69 001b002b

Which equals the following section of code from the get_write_access part
of fs/namei.c:
if (!*p)
0x1305f0 <get_write_access+40>: cmpl $0x0,(%edx)
0x1305f3 <get_write_access+43>: je 0x13061f <get_write_access+87>

for(mpnt = (*p)->mm->mmap; mpnt; mpnt = mpnt->vm_next) {
0x1305f5 <get_write_access+45>: movl (%edx),%eax
0x1305f7 <get_write_access+47>: movl 0x398(%eax),%eax
0x1305fd <get_write_access+53>: movl 0x60(%eax),%eax
(NULL Pointer DeRef!)
0x130600 <get_write_access+56>: testl %eax,%eax
0x130602 <get_write_access+58>: je 0x13061f <get_write_access+87>

if (inode != mpnt->vm_inode)
0x130604 <get_write_access+60>: cmpl %ecx,0x30(%eax)
0x130607 <get_write_access+63>: jne 0x130618 <get_write_access+80>

if (mpnt->vm_flags & VM_DENYWRITE)
return -ETXTBSY;
0x130609 <get_write_access+65>: testb $0x8,0x11(%eax)
0x13060d <get_write_access+69>: je 0x130618 <get_write_access+80>
[<grin> I've been playing with too much assembly output from g++ OK!?]

Coming from lpd, I would suspect it is a problem in trying to access not
yet active hardware drivers -- lp.o isn't loaded yet. That has not caused
a problem before. I can recreate this GPF at will:
[tty1]dominion:src/linux/fs/[5:17am]:rmmod lp
---> kernel: general protection: 0000
---> kernel: EIP: 0010:00130604 ...
---> kernel: general protection: 0000
---> kernel: EIP: 0010:00130604 ...