Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1570013 > unrolled thread
| Started by | Fabian Frederick <fabf@skynet.be> |
|---|---|
| First post | 2017-01-30 19:50 +0100 |
| Last post | 2017-02-01 20:30 +0100 |
| Articles | 8 — 3 participants |
Back to article view | Back to linux.kernel
[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
| From | Fabian Frederick <fabf@skynet.be> |
|---|---|
| Date | 2017-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]
| From | Ingo Molnar <mingo@kernel.org> |
|---|---|
| Date | 2017-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]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2017-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]
| From | Fabian Frederick <fabf@skynet.be> |
|---|---|
| Date | 2017-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]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2017-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]
| From | Fabian Frederick <fabf@skynet.be> |
|---|---|
| Date | 2017-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]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2017-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]
| From | Fabian Frederick <fabf@skynet.be> |
|---|---|
| Date | 2017-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