We've run into a small bug in switch_mm() which results in a process
running with a 'stale' ldt.
The following timeline explains how the bug can occur
Process A begins its life on cpu 0.
Process A is context switched OFF of cpu 0 and replaced by
the idle task (perhaps because of a slow system call).
Process A next runs on cpu 1, where it calls modify_ldt,
to establish an ldt
Process A is context switched OFF of cpu 1
Process A is selected to run on cpu 0.
If cpu 0 has been continually running the idle task, then when
switch_mm() compares the next and prev mm_struct pointers, it will
find they are equal and NOT call load_LDT().
Process A will begin running, with the ldt pointing at default_ldt rather
than its private ldt ( mm->context.segments ).
We have two possible fixes for this problem, and welcome comments as to
which would be 'best'.
The first fix would be to patch switch_mm(), so that when the next and
prev mm pointers are equal, it checks to see if mm->context.segments
is non-null, if so, it calls load_LDT(). This will unfortunately lead
to many unnecessary calls to load_LDT(). An enhanced version of this
fix, would involve introducing a bit array into the mm_struct, one
bit per cpu. When write_ldt() first allocates the ldt for this mm_struct,
it would set all bits. Subsequently, in switch_mm(), we could
introduce a test such as
if(next->context.segments &&
test_and_clear_bit(cpu,&next->ldtupdate))load_LDT(next);
so that as each engine switchs to this mm_struct, a load_LDT() is
guaranteed.
The second fix would introduce yet another IPI. When write_ldt() first
creates a new ldt, it would send an IPI to all other cpu's, passing the
mm pointer as an arg. If the other cpu's were using the mm, they would
then call load_LDT().
Which fix is better depends on the system and application. On a system
with hundreds of processes sharing the same mm_struct, the first fix
will result in quite a few calls to load_LDT(). On a system with a large
number of cpus, and short lived programs using segments, the IPI will
be wasteful.
Please respond with comments as to which patch seems best to you, or
alternative patches if you have suggestions.
thanks
Judy Barkal and Jim Washer
jbarkal@us.ibm.com washer@us.ibm.com
p.s. This problem presented itself in a small application linked to
libpthread (for those that don't know, some versions of libpthread use
segmentation on i386 platforms). Occasionally, the application would
die from a SIGSEGV.
Investigation found that it was dying when the kernel attempted to
restore the gs register. Further investigation showed that the ldt
entry in the gdt pointed to the default_ldt, leading to the
segmentation violation.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:19 EST