Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1570013 > unrolled thread

[PATCH 01/14] locking/atomic: import atomic_dec_not_zero()

Started byFabian Frederick <fabf@skynet.be>
First post2017-01-30 19:50 +0100
Last post2017-02-01 20:30 +0100
Articles 8 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 01/14] locking/atomic: import atomic_dec_not_zero() Fabian Frederick <fabf@skynet.be> - 2017-01-30 19:50 +0100
    Re: [PATCH 01/14] locking/atomic: import atomic_dec_not_zero() Ingo Molnar <mingo@kernel.org> - 2017-01-31 08:40 +0100
    Re: [PATCH 01/14] locking/atomic: import atomic_dec_not_zero() Peter Zijlstra <peterz@infradead.org> - 2017-01-31 11:50 +0100
      Re: [PATCH 01/14] locking/atomic: import atomic_dec_not_zero() Fabian Frederick <fabf@skynet.be> - 2017-01-31 18:50 +0100
        Re: [PATCH 01/14] locking/atomic: import atomic_dec_not_zero() Peter Zijlstra <peterz@infradead.org> - 2017-01-31 20:20 +0100
          Re: [PATCH 01/14] locking/atomic: import atomic_dec_not_zero() Fabian Frederick <fabf@skynet.be> - 2017-01-31 22:00 +0100
            Re: [PATCH 01/14] locking/atomic: import atomic_dec_not_zero() Peter Zijlstra <peterz@infradead.org> - 2017-02-01 10:30 +0100
              Re: [PATCH 01/14] locking/atomic: import atomic_dec_not_zero() Fabian Frederick <fabf@skynet.be> - 2017-02-01 20:30 +0100

#1570013 — [PATCH 01/14] locking/atomic: import atomic_dec_not_zero()

FromFabian Frederick <fabf@skynet.be>
Date2017-01-30 19:50 +0100
Subject[PATCH 01/14] locking/atomic: import atomic_dec_not_zero()
Message-ID<t5pbA-7p2-35@gated-at.bofh.it>
complementary definition to atomic_inc_not_zero() featured in
lib/fault-inject.c

Signed-off-by: Fabian Frederick <fabf@skynet.be>
---
 include/linux/atomic.h | 2 ++
 lib/fault-inject.c     | 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/atomic.h b/include/linux/atomic.h
index e71835b..d8e6551 100644
--- a/include/linux/atomic.h
+++ b/include/linux/atomic.h
@@ -517,6 +517,8 @@ static inline int atomic_add_unless(atomic_t *v, int a, int u)
 #define atomic_inc_not_zero(v)		atomic_add_unless((v), 1, 0)
 #endif
 
+#define atomic_dec_not_zero(v)          atomic_add_unless((v), -1, 0)
+
 #ifndef atomic_andnot
 static inline void atomic_andnot(int i, atomic_t *v)
 {
diff --git a/lib/fault-inject.c b/lib/fault-inject.c
index 6a823a5..4ad5dcc 100644
--- a/lib/fault-inject.c
+++ b/lib/fault-inject.c
@@ -52,8 +52,6 @@ static void fail_dump(struct fault_attr *attr)
 	}
 }
 
-#define atomic_dec_not_zero(v)		atomic_add_unless((v), -1, 0)
-
 static bool fail_task(struct fault_attr *attr, struct task_struct *task)
 {
 	return !in_interrupt() && task->make_it_fail;
-- 
2.9.3

[toc] | [next] | [standalone]


#1570455

FromIngo Molnar <mingo@kernel.org>
Date2017-01-31 08:40 +0100
Message-ID<t5BcJ-6lb-7@gated-at.bofh.it>
In reply to#1570013
* Fabian Frederick <fabf@skynet.be> wrote:

> complementary definition to atomic_inc_not_zero() featured in
> lib/fault-inject.c
> 
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
> ---
>  include/linux/atomic.h | 2 ++
>  lib/fault-inject.c     | 2 --
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/atomic.h b/include/linux/atomic.h
> index e71835b..d8e6551 100644
> --- a/include/linux/atomic.h
> +++ b/include/linux/atomic.h
> @@ -517,6 +517,8 @@ static inline int atomic_add_unless(atomic_t *v, int a, int u)
>  #define atomic_inc_not_zero(v)		atomic_add_unless((v), 1, 0)
>  #endif
>  
> +#define atomic_dec_not_zero(v)          atomic_add_unless((v), -1, 0)
> +
>  #ifndef atomic_andnot
>  static inline void atomic_andnot(int i, atomic_t *v)
>  {
> diff --git a/lib/fault-inject.c b/lib/fault-inject.c
> index 6a823a5..4ad5dcc 100644
> --- a/lib/fault-inject.c
> +++ b/lib/fault-inject.c
> @@ -52,8 +52,6 @@ static void fail_dump(struct fault_attr *attr)
>  	}
>  }
>  
> -#define atomic_dec_not_zero(v)		atomic_add_unless((v), -1, 0)
> -

Why did you convert the tabs to spaces?

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]


#1570595

FromPeter Zijlstra <peterz@infradead.org>
Date2017-01-31 11:50 +0100
Message-ID<t5EaC-84y-21@gated-at.bofh.it>
In reply to#1570013
On Mon, Jan 30, 2017 at 07:39:38PM +0100, Fabian Frederick wrote:
> complementary definition to atomic_inc_not_zero() featured in
> lib/fault-inject.c

Why?

[toc] | [prev] | [next] | [standalone]


#1570934

FromFabian Frederick <fabf@skynet.be>
Date2017-01-31 18:50 +0100
Message-ID<t5KJ4-3yR-21@gated-at.bofh.it>
In reply to#1570595

> On 31 January 2017 at 11:41 Peter Zijlstra <peterz@infradead.org> wrote:
>
>
> On Mon, Jan 30, 2017 at 07:39:38PM +0100, Fabian Frederick wrote:
> > complementary definition to atomic_inc_not_zero() featured in
> > lib/fault-inject.c
>
> Why?

Maybe this commit message should be ok ?

complementary definition to atomic_inc_not_zero() featured in lib/fault-inject.c
and is more readable than atomic_add_unless((v), -1, 0) used in different
places.

Andrew, do I have to submit this patch again replacing spaces with tabs in code
line ?

Regards,
Fabian

[toc] | [prev] | [next] | [standalone]


#1571014

FromPeter Zijlstra <peterz@infradead.org>
Date2017-01-31 20:20 +0100
Message-ID<t5M89-4ww-3@gated-at.bofh.it>
In reply to#1570934
On Tue, Jan 31, 2017 at 06:41:28PM +0100, Fabian Frederick wrote:
> 
> 
> > On 31 January 2017 at 11:41 Peter Zijlstra <peterz@infradead.org> wrote:
> >
> >
> > On Mon, Jan 30, 2017 at 07:39:38PM +0100, Fabian Frederick wrote:
> > > complementary definition to atomic_inc_not_zero() featured in
> > > lib/fault-inject.c
> >
> > Why?
> 
> Maybe this commit message should be ok ?
> 
> complementary definition to atomic_inc_not_zero() featured in lib/fault-inject.c
> and is more readable than atomic_add_unless((v), -1, 0) used in different
> places.

I still don't see why such a primitive makes sense. Yes there's a few
usage sites, but from them I don't see a sensible pattern.

What sane pattern desires this?

[toc] | [prev] | [next] | [standalone]


#1571077

FromFabian Frederick <fabf@skynet.be>
Date2017-01-31 22:00 +0100
Message-ID<t5NGV-5im-7@gated-at.bofh.it>
In reply to#1571014

> On 31 January 2017 at 20:17 Peter Zijlstra <peterz@infradead.org> wrote:
>
>
> On Tue, Jan 31, 2017 at 06:41:28PM +0100, Fabian Frederick wrote:
> >
> >
> > > On 31 January 2017 at 11:41 Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > >
> > > On Mon, Jan 30, 2017 at 07:39:38PM +0100, Fabian Frederick wrote:
> > > > complementary definition to atomic_inc_not_zero() featured in
> > > > lib/fault-inject.c
> > >
> > > Why?
> >
> > Maybe this commit message should be ok ?
> >
> > complementary definition to atomic_inc_not_zero() featured in
> > lib/fault-inject.c
> > and is more readable than atomic_add_unless((v), -1, 0) used in different
> > places.
>
> I still don't see why such a primitive makes sense. Yes there's a few
> usage sites, but from them I don't see a sensible pattern.
>
> What sane pattern desires this?

Once again it's just about readability:

"add -1 unless value is zero" looks more complex in code than "dec not zero"
but maybe it's just a matter of taste :) It it's not the case why would there be
more sense about having
atomic_inc_not_zero() globally ?

Regards,
Fabian

[toc] | [prev] | [next] | [standalone]


#1571356

FromPeter Zijlstra <peterz@infradead.org>
Date2017-02-01 10:30 +0100
Message-ID<t5ZoK-46P-27@gated-at.bofh.it>
In reply to#1571077
On Tue, Jan 31, 2017 at 09:55:08PM +0100, Fabian Frederick wrote:
> Once again it's just about readability:

I feel APIs should be about common use-cases, not about sporadic weird cases.

> "add -1 unless value is zero" looks more complex in code than "dec not zero"
> but maybe it's just a matter of taste :) It it's not the case why would there be
> more sense about having
> atomic_inc_not_zero() globally ?

inc_not_zero() has a very strong use-case, its for lockless refcount
increment. Incrementing a 0 reference count is bad because the object
will be freed and you'll have a use-after-free.

Arguably, once we move reference counting over to its own type, it would
make sense to remove it from atomic, specifically to discourage that use
case.

[toc] | [prev] | [next] | [standalone]


#1571910

FromFabian Frederick <fabf@skynet.be>
Date2017-02-01 20:30 +0100
Message-ID<t68Ln-1wJ-7@gated-at.bofh.it>
In reply to#1571356

> On 01 February 2017 at 10:25 Peter Zijlstra <peterz@infradead.org> wrote:
>
>
> On Tue, Jan 31, 2017 at 09:55:08PM +0100, Fabian Frederick wrote:
> > Once again it's just about readability:
>
> I feel APIs should be about common use-cases, not about sporadic weird cases.
>
> > "add -1 unless value is zero" looks more complex in code than "dec not zero"
> > but maybe it's just a matter of taste :) It it's not the case why would
> > there be
> > more sense about having
> > atomic_inc_not_zero() globally ?
>
> inc_not_zero() has a very strong use-case, its for lockless refcount
> increment. Incrementing a 0 reference count is bad because the object
> will be freed and you'll have a use-after-free.
>
> Arguably, once we move reference counting over to its own type, it would
> make sense to remove it from atomic, specifically to discourage that use
> case.

Do you know about some commit doing such conversion or could you give me 2
distinct models
so I could compare ? btw atomic_inc_not_zero() is also adviced in
Documentation/RCU/rcuref.txt

Regards,
Fabian

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web