> David B. Rees wrote:
> >
> > I get the following Oops after running wine and wine crashes. I'm using kernel
> > 2.1.103 + 104 pre-patch1. Hmm... I saw the patch for this a while back, and
> > that patch is also installed. The name of that patch is arch386_ldt103-patch.
>
> > Jun 2 01:56:11 oto kernel: Unable to handle kernel paging request at virtual
> > address c3820090
> > Jun 2 01:56:11 oto kernel: current->tss.cr3 = 01068000, ^Lr3 = 01068000
> > Jun 2 01:56:11 oto kernel: *pde = 00002063
> > Jun 2 01:56:11 oto kernel: *pte = 00000000
> > Jun 2 01:56:11 oto kernel: Oops: 0000
> > Jun 2 01:56:11 oto kernel: CPU: 0
> > Jun 2 01:56:12 oto kernel: EIP: 0010:[<c0110b5c>]
> > Jun 2 01:56:12 oto kernel: EFLAGS: 00000246
> > Jun 2 01:56:12 oto kernel: eax: 00000028 ebx: c168a000 ecx: c0106000
> > edx: 00000028
> > Jun 2 01:56:12 oto kernel: esi: c194e000 edi: 00000000 ebp: c168bea4
> > esp: c168be7c
> > Jun 2 01:56:12 oto kernel: ds: 0018 es: 0018 ss: 0018 fs: 0097 gs: 002b
> > Jun 2 01:56:12 oto kernel: Process wine (pid: 18276, process nr: 35,
> > stackpage=c168b000)
> > Jun 2 01:56:12 oto kernel: ldt: 0298 tss.ldt: 0298 LDT: 0298 tr: 0290
> ^^^ ^^^ ^^^
> ^^^
> An interesting oops -- it appears that this one is a case not with the
> ldt being out of sync with the tss, but that one of the entries in the
> ldt is bad. The patch for the ldt code takes care of a problem with the
> ldt not being reloaded properly, but it has no way to ensure that
> changes to the ldt will be valid for _all_ tasks using the ldt.
I disagree, it seems that the ldt area has been freed (vfree) while the
segment in fs still needs the ldt. That's why it ends in a page fault when
accessing the ldt entry. Then theree is the mysterious (for me) bad vfree
message, which can happen when trying to free twice the same area (seem to
be the case). So the question is: when is the ldt freed (I thought it was
when the mm context is freed, i.e., when its reference count drops to 0) ?
How is it possible to trigger this type of situation (and was the machine
SMP) ?
Note that fs=0097 means and the opcode (pop fs) means that we are trying
to access the 8 bytes at address ldt_base+0x0090 which and that the
invalid vfree is exactly at ldt_base address also, so it looks like
(but only looks like) double freeing of the ldt.
Regards,
Gabriel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu