linux-mips
[Top] [All Lists]

Re: [PATCH 04/36] Add Cavium OCTEON processor support files to arch/mips

To: David Daney <ddaney@caviumnetworks.com>
Subject: Re: [PATCH 04/36] Add Cavium OCTEON processor support files to arch/mips/mm.
From: Ralf Baechle <ralf@linux-mips.org>
Date: Wed, 29 Oct 2008 18:09:58 +0000
Cc: linux-mips@linux-mips.org, Tomaso Paoletti <tpaoletti@caviumnetworks.com>, Paul Gortmaker <Paul.Gortmaker@windriver.com>
In-reply-to: <49088E81.7080604@caviumnetworks.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <490655B6.4030406@caviumnetworks.com> <1225152181-3221-1-git-send-email-ddaney@caviumnetworks.com> <1225152181-3221-2-git-send-email-ddaney@caviumnetworks.com> <1225152181-3221-3-git-send-email-ddaney@caviumnetworks.com> <1225152181-3221-4-git-send-email-ddaney@caviumnetworks.com> <20081029160710.GB26256@linux-mips.org> <49088E81.7080604@caviumnetworks.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.18 (2008-05-17)
On Wed, Oct 29, 2008 at 09:25:37AM -0700, David Daney wrote:

>>  The probability is not so high
>> for typical apps but it's entirely possibly that on a preemptable kernel
>> the thread that wrote the trampoline code gets rescheduled to another
>> CPU before the flush is executed.  Or after the SYNCI happened on the one
>> core the thread is rescheduled to another CPU which then may try to
>> return with an inconsistent I-cache.  Boom.
>
>
> This is the problem I mentioned yesterday on IRC.  I had come to the  
> same conclusion and think we need to invalidate the icache on all cores  
> here.
>
> The real solution to this problem is to place the signal trampolines in  
> a VDSO.  But that is a project for another day.

Or we once more rely on abusing the address error exception.  Place an
address in the kernel space into $ra before jumping to the signal handler.
Once finished the signal handler then will trigger an address error.
Ugly.  Efficient.  And it would get rid of all the fun
"Don't let your children do this ..." stunts of sigreturn.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>