[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen: arm: clear the exclusive monitor on exception return



On Thu, 2013-07-18 at 17:48 +0100, Tim Deegan wrote:
> At 09:31 +0100 on 18 Jul (1374139884), Ian Campbell wrote:
> > On Wed, 2013-07-17 at 20:48 +0100, Tim Deegan wrote:
> > > At 12:18 +0100 on 17 Jul (1374063531), Ian Campbell wrote:
> > > > Otherwise context switching between two vcpus which are contending the 
> > > > same
> > > > lock can result in a spurious success.
> > > 
> > > Shouldn't this go in ctxt_swicth_to(), then?  I think any use that Xen
> > > itself makes of the monitor should end with it cleared.
> > 
> > Our atomic read/set which we stole^Winherited from Linux relies on this
> > behaviour (interlocking with atomic_add_and_blah stuff).
> >         /*
> >          * On ARM, ordinary assignment (str instruction) doesn't clear the 
> > local
> >          * strex/ldrex monitor on some implementations. The reason we can 
> > use it for
> >          * atomic_set() is the clrex or dummy strex done on every exception 
> > return.
> >          */
> 
> Ah, OK.  So, Ack, but if it's not already committed can you edit the
> commit message to refer to this?

Thanks and Yes Sure.

> > As well as atomics our spin unlock (also inherited) is just a plain
> > store.
> 
> Well, we already avoid having locks shared between interrupt/exception
> handlers and plain code,

We do? Plain code can use the irqsave/restore variants if it wants to
coexist with irq handlers which take the same locks, can't they? e.g.
the gic lock is handled this way... If that's not valid then we might
have a problem ;-)

>  but I guess it can't hurt.
> 
> Tim.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.