A question on preemption during local_irq_disable() in non-mipsr2 multiprocessor

[Jim Quinlan <jim2101024@gmail.com>]

A while ago, this question was posted

    
http://old.nabble.com/Is-local_irq_disable%28%29-preemption-safe---td16599731.html

which basically asked, 'what happens if preemption occurs between the
"mfc0" and the "mtc0" in the non-mipsr2 code of
arch_local_irq_disable() in irqflags.h':

    mfc0    $1,c0_status
    ori    $1,0x1f
    xori    $1,0x1f
    mtc0    $1,c0_status

If preemption occurs, it appears that a possibly stale value of the
status register will be stored.  I am seeing this exact situation with
a BMIPS 5000 multiprocessor --  one processor has different
c0_status.IM settings than the other processor, and when this
situation occurs, the processor that is expecting certain interrupts
no longer gets them because its status.IM field is hosed.  The exact
location of this issue is occurring in the write_lock_irq() invocation
in the function release_task() in the file exit.c.  However,
arch_local_irq_disable() is not the only function like this; others
exist in irqflags.h and asmmacro.h.

Can someone confirm that this is indeed an issue?  I would post a
patch I am using but (1) I would like to hear feedback first and (2)
the patch has its own issues as it involves using preemption macros in
irqflags.h.

Thanks,
Jim Quinlan