On Tue, May 28, 2019 at 12:47:19PM +0200, Peter Zijlstra wrote:
> On Sat, May 25, 2019 at 12:43:40AM +0200, Andrea Parri wrote:
> > > ---
> > > Subject: Documentation/atomic_t.txt: Clarify pure non-rmw usage
> > >
> > > Clarify that pure non-RMW usage of atomic_t is pointless, there is
> > > nothi
On Sat, May 25, 2019 at 12:43:40AM +0200, Andrea Parri wrote:
> > ---
> > Subject: Documentation/atomic_t.txt: Clarify pure non-rmw usage
> >
> > Clarify that pure non-RMW usage of atomic_t is pointless, there is
> > nothing 'magical' about atomic_set() / atomic_read().
> >
> > This is something
> ---
> Subject: Documentation/atomic_t.txt: Clarify pure non-rmw usage
>
> Clarify that pure non-RMW usage of atomic_t is pointless, there is
> nothing 'magical' about atomic_set() / atomic_read().
>
> This is something that seems to confuse people, because I happen upon it
> semi-regularly.
>
On Fri, May 24, 2019 at 12:42:20PM +0100, Will Deacon wrote:
> > diff --git a/Documentation/atomic_t.txt b/Documentation/atomic_t.txt
> > index dca3fb0554db..125c95ddbbc0 100644
> > --- a/Documentation/atomic_t.txt
> > +++ b/Documentation/atomic_t.txt
> > @@ -83,6 +83,9 @@ The non-RMW ops are (typ
On Fri, May 24, 2019 at 01:18:07PM +0200, Peter Zijlstra wrote:
> On Fri, May 24, 2019 at 12:37:31PM +0200, Peter Zijlstra wrote:
> > On Thu, May 23, 2019 at 11:19:26AM +0100, Mark Rutland wrote:
> >
> > > [mark@lakrids:~/src/linux]% git grep '\(return\|=\)\s\+atomic\(64\)\?_set'
> > > include/lin
On Fri, May 24, 2019 at 01:18:07PM +0200, Peter Zijlstra wrote:
> On Fri, May 24, 2019 at 12:37:31PM +0200, Peter Zijlstra wrote:
> > On Thu, May 23, 2019 at 11:19:26AM +0100, Mark Rutland wrote:
> >
> > > [mark@lakrids:~/src/linux]% git grep '\(return\|=\)\s\+atomic\(64\)\?_set'
> > > include/lin
On Fri, May 24, 2019 at 12:37:31PM +0200, Peter Zijlstra wrote:
> On Thu, May 23, 2019 at 11:19:26AM +0100, Mark Rutland wrote:
>
> > [mark@lakrids:~/src/linux]% git grep '\(return\|=\)\s\+atomic\(64\)\?_set'
> > include/linux/vmw_vmci_defs.h: return atomic_set((atomic_t *)var,
> > (u32)new_val)
On Thu, May 23, 2019 at 11:19:26AM +0100, Mark Rutland wrote:
> [mark@lakrids:~/src/linux]% git grep '\(return\|=\)\s\+atomic\(64\)\?_set'
> include/linux/vmw_vmci_defs.h: return atomic_set((atomic_t *)var,
> (u32)new_val);
> include/linux/vmw_vmci_defs.h: return atomic64_set(var, new_val);
>
> > While reading the series, I realized that the following expression:
> >
> > atomic64_t v;
> > ...
> > typeof(v.counter) my_val = atomic64_set(&v, VAL);
> >
> > is a valid expression on some architectures (in part., on architectures
> > which #define atomic64_set() to WRITE_ONC
On Wed, May 22, 2019 at 11:18:59PM +0200, Arnd Bergmann wrote:
> On Wed, May 22, 2019 at 3:23 PM Mark Rutland wrote:
> >
> > Currently architectures return inconsistent types for atomic64 ops. Some
> > return
> > long (e..g. powerpc), some return long long (e.g. arc), and some return s64
> > (e.g
On Thu, May 23, 2019 at 10:30:13AM +0200, Andrea Parri wrote:
> Hi Mark,
Hi Andrea,
> On Wed, May 22, 2019 at 02:22:32PM +0100, Mark Rutland wrote:
> > Currently architectures return inconsistent types for atomic64 ops. Some
> > return
> > long (e..g. powerpc), some return long long (e.g. arc),
Hi Mark,
On Wed, May 22, 2019 at 02:22:32PM +0100, Mark Rutland wrote:
> Currently architectures return inconsistent types for atomic64 ops. Some
> return
> long (e..g. powerpc), some return long long (e.g. arc), and some return s64
> (e.g. x86).
(only partially related, but probably worth askin
On Wed, May 22, 2019 at 3:23 PM Mark Rutland wrote:
>
> Currently architectures return inconsistent types for atomic64 ops. Some
> return
> long (e..g. powerpc), some return long long (e.g. arc), and some return s64
> (e.g. x86).
>
> This is a bit messy, and causes unnecessary pain (e.g. as value
13 matches
Mail list logo
