linux-mips
[Top] [All Lists]

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

To: linux-mips@linux-mips.org
Subject: A question on preemption during local_irq_disable() in non-mipsr2 multiprocessor
From: Jim Quinlan <jim2101024@gmail.com>
Date: Fri, 17 Aug 2012 17:04:29 -0400
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=F29++MBiu3TohPMTwiBlVViinVGWRvMiXk1EZtTU0lU=; b=HRNnFC1kmxYXp3rHfvkfBqXau1aJDS4DC8LPNaXuXFeypUspV/ZE2qOHG5XxnupISD qbIQGrJEvDUQDs79VziH37ddYj08BeuJgREigpeZufFkeBvhJdV/3m55QI+LIDIcnXEv +H9jvCqWL1qakPlzmQyoBwRvyiU2OAonZ5r6jTt94Oqhdjvd/GzMihBaLbjr650HpMT1 HVJ/VmG++FV/ewv9QJNYuI6/AyrvhsqjUZJjZ/d88566T/vApHpr/VBcTQ+Qui1U/juQ 7LP8LXzU3Z4fkAUSxU0D6p6NNbPRzmHurfm/aEmfvorg4Z+YoHF1XLCmVuuGVDvTPfyv +tSw==
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Sender: linux-mips-bounce@linux-mips.org
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

<Prev in Thread] Current Thread [Next in Thread>
  • A question on preemption during local_irq_disable() in non-mipsr2 multiprocessor, Jim Quinlan <=