Hi,
I think the following is a bug that can affect kernels patched with
lowlatency, such as Audio? and RedHat AS2.1.
lowlatency patch added conditional_schedule() to be called from
close_files(?) at kernel/exit.c, which seems to raise a problem if the
process had LDT entries.
If it had LDT, at the stage of close_files(?) the tsk->mm already zeroed
(__exit_mm(?), which comes before __exit_files(?) in do_exit(?)).? If
conditional_schedule() at close_files(?) will succeed, switching back into
this process (that now have zeroed tsk->mm) will fail since the kernel will
not use the right LDT (since tsk->mm was zeroed, so switch_mm(?) will not be
called to load the LDT at schedule()).
Switching back to a process that had a register that used the LDT will fail
since the register probably points to non-valid LDT entry (since we are
using the wrong LDT), which will lead to a segmentation fault.
?
--Shai
> lowlatency patch added conditional_schedule() to be called from
> close_files() at kernel/exit.c, which seems to raise a problem if the
> process had LDT entries.
> If it had LDT, at the stage of close_files() the tsk->mm already zeroed
> (__exit_mm(), which comes before __exit_files() in do_exit()). If
> conditional_schedule() at close_files() will succeed, switching back into
> this process (that now have zeroed tsk->mm) will fail since the kernel will
> not use the right LDT (since tsk->mm was zeroed, so switch_mm() will not be
> called to load the LDT at schedule()).
since closing of files can sleep anyway I don't see how this schedule
point could introduce a bug.
> Switching back to a process that had a register that used the LDT will fail
> since the register probably points to non-valid LDT entry (since we are
> using the wrong LDT), which will lead to a segmentation fault.
Do you have an oops? Could you file that in RH bugzilla
(bugzilla.redhat.com) ? RH bugzilla is a far more appropriate place to
report bugs in the RH vendor kernels than lkml is.
Greetings,
Arjan van de Ven