> > > 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) ?
Hi Gabriel,
In my comment I meant only that the value in the ldtr is consistent with
the value in tr (i.e. ldtr = tr + 8, so that they were loaded from the
gdt). This is different from the previous ldt-related oops.
The ldt is supposed to be freed only when the last thread exits and the
mm count goes to 0, so something is wrong if it's getting freed
prematurely. (Or the mm->segments value has been trashed somehow,
causing both the oops and the vfree message.)
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu