switch_mm() can fail to load ldt on SMP - causing SIGSEGV

[Judy Barkal]

The bug description below was submitted to the linux kernel mailing list
this week and it was suggested to us that we also submit this report to
bug-glibc.  From the ps text below, the bug might lead someone to believe
the problem was in libc.

A patch for kernel 2.4.5-7 can be found at
http://oss.software.ibm.com/developer/opensource/linux/patches/misc.php

Linus' patch is in testing/patch-2.4.8-pre1.

Thanks,
Jim Washer and Judy Barkal
     address@hidden        address@hidden

============
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
           address@hidden   address@hidden


 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.