linux-mips
[Top] [All Lists]

Re: CVS Update@oss.sgi.com: linux

To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Subject: Re: CVS Update@oss.sgi.com: linux
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Wed, 3 Oct 2001 19:50:59 +0200
Cc: linux-mips@oss.sgi.com
In-reply-to: <Pine.GSO.3.96.1011003125730.15867A-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Wed, Oct 03, 2001 at 01:02:56PM +0200
References: <200109300029.f8U0TZv12410@oss.sgi.com> <Pine.GSO.3.96.1011003125730.15867A-100000@delta.ds2.pg.gda.pl>
Sender: owner-linux-mips@oss.sgi.com
User-agent: Mutt/1.2.5i
On Wed, Oct 03, 2001 at 01:02:56PM +0200, Maciej W. Rozycki wrote:

> > Modified files:
> >     arch/mips/kernel: scall_o32.S sysmips.c 
> > 
> > Log message:
> >     Barf.
> 
>  The new mips_atomic_set() doesn't mask interrupts in the non-ll/sc case. 
> Thus it may fail to keep coherency.  Is it intentional? 

Yes.  Assuming do_page_fault did it's job successfully the address which
has been passed as argument to sysmips() is now writable and thus we
won't take any pagefaults.

There are two remaining failure scenarios which probably are't very
interesting for practical usage.  It's when an interrupt is accessing
the same address.  This could be fixed by disabling interrupts.
The other case is missaligned words.

>  Also the bad_stack exit point for the ll/sc case looks suspicient to me.

Indeed, the symbol deserves a better name.  Cut'n'paste happens ;-)

  Ralf

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