From: konrad.wilk@oracle.com (Konrad Rzeszutek Wilk)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
Date: Tue, 5 Mar 2013 09:04:52 -0500 [thread overview]
Message-ID: <20130305140452.GE2589@phenom.dumpdata.com> (raw)
In-Reply-To: <1362455801.8941.24.camel@hastur.hellion.org.uk>
On Tue, Mar 05, 2013 at 03:56:41AM +0000, Ian Campbell wrote:
> > > diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> > > index 94b4e90..5c27696 100644
> > > --- a/arch/arm/include/asm/xen/events.h
> > > +++ b/arch/arm/include/asm/xen/events.h
> > > @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> > > return raw_irqs_disabled_flags(regs->ARM_cpsr);
> > > }
> > >
> > > +/*
> > > + * We cannot use xchg because it does not support 8-byte
> > > + * values. However it is safe to use {ldr,dtd}exd directly because all
> > > + * platforms which Xen can run on support those instructions.
> >
> > Why does atomic64_cmpxchg not work here?
>
> Just that we don't want/need the cmp aspect, we don't mind if an extra
> bit gets set as we read the value, so long as we atomically read and set
> to zero.
>
> > > + */
> > > +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> > > +{
> > > + xen_ulong_t oldval;
> > > + unsigned int tmp;
> > > +
> > > + wmb();
> >
> > Based on atomic64_cmpxchg implementation, you could use smp_mb here
> > which avoids an outer cache flush.
>
> Good point.
>
> > > + asm volatile("@ xchg_xen_ulong\n"
> > > + "1: ldrexd %0, %H0, [%3]\n"
> > > + " strexd %1, %2, %H2, [%3]\n"
> > > + " teq %1, #0\n"
> > > + " bne 1b"
> > > + : "=&r" (oldval), "=&r" (tmp)
> > > + : "r" (val), "r" (ptr)
> > > + : "memory", "cc");
> >
> > And a smp_mb is needed here.
>
> I think for the specific caller which we have here it isn't strictly
> necessary, but for generic correctness I think you are right.
>
> Thanks for reviewing.
>
> Konrad, IIRC you have already picked this up (and sent to Linus?) so an
Yes.
> incremental fix is required? See below.
Why don't I wait a bit and wait until you are back from conferences and
can post a nice series that fixes the smp_wmb() and also the atomic one
and has been run-time tested with Xen on ARM.
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: Rob Herring <robherring2@gmail.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
"Keir (Xen.org)" <keir@xen.org>,
Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
"Tim (Xen.org)" <tim@xen.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jan Beulich <JBeulich@suse.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Nicolas Pitre <nico@fluxnic.net>,
Will Deacon <will.deacon@arm.com>
Subject: Re: [PATCH LINUX v5] xen: event channel arrays are xen_ulong_t and not unsigned long
Date: Tue, 5 Mar 2013 09:04:52 -0500 [thread overview]
Message-ID: <20130305140452.GE2589@phenom.dumpdata.com> (raw)
In-Reply-To: <1362455801.8941.24.camel@hastur.hellion.org.uk>
On Tue, Mar 05, 2013 at 03:56:41AM +0000, Ian Campbell wrote:
> > > diff --git a/arch/arm/include/asm/xen/events.h b/arch/arm/include/asm/xen/events.h
> > > index 94b4e90..5c27696 100644
> > > --- a/arch/arm/include/asm/xen/events.h
> > > +++ b/arch/arm/include/asm/xen/events.h
> > > @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
> > > return raw_irqs_disabled_flags(regs->ARM_cpsr);
> > > }
> > >
> > > +/*
> > > + * We cannot use xchg because it does not support 8-byte
> > > + * values. However it is safe to use {ldr,dtd}exd directly because all
> > > + * platforms which Xen can run on support those instructions.
> >
> > Why does atomic64_cmpxchg not work here?
>
> Just that we don't want/need the cmp aspect, we don't mind if an extra
> bit gets set as we read the value, so long as we atomically read and set
> to zero.
>
> > > + */
> > > +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
> > > +{
> > > + xen_ulong_t oldval;
> > > + unsigned int tmp;
> > > +
> > > + wmb();
> >
> > Based on atomic64_cmpxchg implementation, you could use smp_mb here
> > which avoids an outer cache flush.
>
> Good point.
>
> > > + asm volatile("@ xchg_xen_ulong\n"
> > > + "1: ldrexd %0, %H0, [%3]\n"
> > > + " strexd %1, %2, %H2, [%3]\n"
> > > + " teq %1, #0\n"
> > > + " bne 1b"
> > > + : "=&r" (oldval), "=&r" (tmp)
> > > + : "r" (val), "r" (ptr)
> > > + : "memory", "cc");
> >
> > And a smp_mb is needed here.
>
> I think for the specific caller which we have here it isn't strictly
> necessary, but for generic correctness I think you are right.
>
> Thanks for reviewing.
>
> Konrad, IIRC you have already picked this up (and sent to Linus?) so an
Yes.
> incremental fix is required? See below.
Why don't I wait a bit and wait until you are back from conferences and
can post a nice series that fixes the smp_wmb() and also the atomic one
and has been run-time tested with Xen on ARM.
next prev parent reply other threads:[~2013-03-05 14:04 UTC|newest]
Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-19 14:48 [PATCH V2] xen: event channel arrays are xen_ulong_t and not unsigned long Ian Campbell
2013-02-19 14:48 ` Ian Campbell
2013-02-19 14:49 ` [PATCH LINUX] " Ian Campbell
2013-02-19 14:49 ` Ian Campbell
2013-02-19 17:11 ` Stefano Stabellini
2013-02-19 17:11 ` Stefano Stabellini
2013-02-19 17:11 ` Stefano Stabellini
2013-02-19 17:17 ` Ian Campbell
2013-02-19 17:17 ` Ian Campbell
2013-02-19 17:17 ` Ian Campbell
2013-02-19 17:26 ` Tim Deegan
2013-02-19 17:26 ` Tim Deegan
2013-02-19 17:28 ` Ian Campbell
2013-02-19 17:28 ` Ian Campbell
2013-02-19 17:28 ` Ian Campbell
2013-02-19 17:26 ` Tim Deegan
2013-02-19 14:49 ` Ian Campbell
2013-02-19 14:49 ` [PATCH XEN] " Ian Campbell
2013-02-19 14:49 ` Ian Campbell
2013-02-19 16:42 ` Stefano Stabellini
2013-02-19 16:42 ` Stefano Stabellini
2013-02-19 16:42 ` Stefano Stabellini
2013-02-21 17:16 ` Ian Campbell
2013-02-21 17:16 ` Ian Campbell
2013-02-21 18:43 ` Keir Fraser
2013-02-21 18:43 ` Keir Fraser
2013-02-22 8:28 ` Ian Campbell
2013-02-22 8:28 ` Ian Campbell
2013-02-22 8:28 ` Ian Campbell
2013-02-21 18:43 ` Keir Fraser
2013-02-22 8:12 ` Jan Beulich
2013-02-22 8:12 ` Jan Beulich
2013-02-22 8:12 ` Jan Beulich
2013-02-22 8:28 ` Ian Campbell
2013-02-22 8:28 ` Ian Campbell
2013-02-22 8:28 ` Ian Campbell
2013-02-22 8:48 ` Jan Beulich
2013-02-22 8:48 ` Jan Beulich
2013-02-22 8:55 ` Ian Campbell
2013-02-22 8:55 ` Ian Campbell
2013-02-22 9:05 ` Jan Beulich
2013-02-22 9:05 ` Jan Beulich
2013-02-22 9:05 ` Jan Beulich
2013-02-22 8:55 ` Ian Campbell
2013-02-22 8:48 ` Jan Beulich
2013-02-21 17:16 ` Ian Campbell
2013-02-19 14:49 ` Ian Campbell
2013-02-19 17:27 ` [PATCH LINUX v3] " Ian Campbell
2013-02-19 17:27 ` Ian Campbell
2013-02-19 17:27 ` Ian Campbell
2013-02-19 17:29 ` [PATCH LINUX v4] " Ian Campbell
2013-02-19 17:29 ` Ian Campbell
2013-02-19 18:12 ` Stefano Stabellini
2013-02-19 18:12 ` Stefano Stabellini
2013-02-19 18:43 ` Konrad Rzeszutek Wilk
2013-02-19 18:43 ` Konrad Rzeszutek Wilk
2013-02-19 18:43 ` Konrad Rzeszutek Wilk
2013-02-19 18:12 ` Stefano Stabellini
2013-02-20 2:07 ` Konrad Rzeszutek Wilk
2013-02-20 2:07 ` Konrad Rzeszutek Wilk
2013-02-20 2:07 ` Konrad Rzeszutek Wilk
2013-02-20 3:09 ` Konrad Rzeszutek Wilk
2013-02-20 3:09 ` Konrad Rzeszutek Wilk
2013-02-20 3:09 ` Konrad Rzeszutek Wilk
2013-02-20 9:13 ` Ian Campbell
2013-02-20 9:13 ` Ian Campbell
2013-02-20 9:13 ` Ian Campbell
2013-02-19 17:29 ` Ian Campbell
2013-02-20 11:48 ` [PATCH LINUX v5] " Ian Campbell
2013-02-20 11:48 ` Ian Campbell
2013-02-20 11:48 ` Ian Campbell
2013-02-21 17:11 ` Stefano Stabellini
2013-02-21 17:11 ` Stefano Stabellini
2013-02-21 17:11 ` Stefano Stabellini
2013-03-04 2:45 ` Rob Herring
2013-03-04 2:45 ` Rob Herring
2013-03-04 2:45 ` Rob Herring
2013-03-05 3:04 ` Will Deacon
2013-03-05 3:04 ` Will Deacon
2013-03-05 3:45 ` Ian Campbell
2013-03-05 3:45 ` Ian Campbell
2013-03-05 3:45 ` Ian Campbell
2013-03-05 6:55 ` Rob Herring
2013-03-05 6:55 ` Rob Herring
2013-03-05 6:55 ` Rob Herring
2013-03-05 7:03 ` Ian Campbell
2013-03-05 7:03 ` Ian Campbell
2013-03-05 7:03 ` Ian Campbell
2013-03-05 8:08 ` Will Deacon
2013-03-05 8:08 ` Will Deacon
2013-03-05 8:08 ` Will Deacon
2013-03-05 9:29 ` Ian Campbell
2013-03-05 9:29 ` Ian Campbell
2013-03-05 9:29 ` Ian Campbell
2013-03-07 3:17 ` Will Deacon
2013-03-07 3:17 ` Will Deacon
2013-03-07 3:17 ` Will Deacon
2013-03-07 7:17 ` Ian Campbell
2013-03-07 7:17 ` Ian Campbell
2013-03-07 7:17 ` Ian Campbell
2013-03-05 3:04 ` Will Deacon
2013-03-05 3:56 ` Ian Campbell
2013-03-05 3:56 ` Ian Campbell
2013-03-05 3:56 ` Ian Campbell
2013-03-05 14:04 ` Konrad Rzeszutek Wilk [this message]
2013-03-05 14:04 ` Konrad Rzeszutek Wilk
2013-03-05 14:04 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130305140452.GE2589@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.