From: Eric Dumazet <dada1@cosmosbay.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
Tejun Heo <htejun@gmail.com>,
linux kernel <linux-kernel@vger.kernel.org>,
Linux Netdev List <netdev@vger.kernel.org>,
Joe Perches <joe@perches.com>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH] x86: percpu_to_op() misses memory and flags clobbers
Date: Wed, 01 Apr 2009 19:13:38 +0200 [thread overview]
Message-ID: <49D3A0C2.9000403@cosmosbay.com> (raw)
In-Reply-To: <20090401161218.GB3859@elte.hu>
Ingo Molnar a écrit :
> * Eric Dumazet <dada1@cosmosbay.com> wrote:
>
>> Jeremy Fitzhardinge a écrit :
>>> Eric Dumazet wrote:
>>>> While playing with new percpu_{read|write|add|sub} stuff in network tree,
>>>> I found x86 asm was a litle bit optimistic.
>>>>
>>>> We need to tell gcc that percpu_{write|add|sub|or|xor} are modyfing
>>>> memory and possibly eflags. We could add another parameter to
>>>> percpu_to_op()
>>>> to separate the plain "mov" case (not changing eflags),
>>>> but let keep it simple for the moment.
>>>>
>>> Did you observe an actual failure that this patch fixed?
>>>
>> Not in current tree, as we dont use yet percpu_xxxx() very much.
>>
>> If deployed for SNMP mibs with hundred of call sites,
>> can you guarantee it will work as is ?
>
> Do we "guarantee" it for you? No.
>
> Is it expected to work just fine? Yes.
>
> Are there any known bugs in this area? No.
Good to know. So I shut up. I am a jerk and should blindly trust
linux kernel, sorry.
>
> Will we fix it if it's demonstrated to be broken? Of course! :-)
>
> [ Btw., it's definitely cool that you will make heavy use for it for
> SNMP mib statistics - please share with us your experiences with
> the facilities - good or bad experiences alike! ]
I tried but I miss kind of an indirect percpu_add() function.
because of Net namespaces, mibs are dynamically allocated, and
current percpu_add() works on static percpu only (because of added
per_cpu__ prefix)
#define percpu_add(var, val) percpu_to_op("add", per_cpu__##var, val)
I tried adding :
#define dyn_percpu_add(var, val) percpu_to_op("add", var, val)
But I dont know it this is the plan ?
Should we get rid of "per_cpu__" prefix and use a special ELF section/
marker instead ?
I have a patch to add percpu_inc() and percpu_dec(), I am not
sure its worth it...
[PATCH] percpu: Adds percpu_inc() and percpu_dec()
Increments and decrements are quite common operations for SNMP mibs.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index aee103b..248be11 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -103,6 +103,29 @@ do { \
} \
} while (0)
+#define percpu_to_op0(op, var) \
+do { \
+ switch (sizeof(var)) { \
+ case 1: \
+ asm(op "b "__percpu_arg(0) \
+ : "+m" (var)); \
+ break; \
+ case 2: \
+ asm(op "w "__percpu_arg(0) \
+ : "+m" (var)); \
+ break; \
+ case 4: \
+ asm(op "l "__percpu_arg(0) \
+ : "+m" (var)); \
+ break; \
+ case 8: \
+ asm(op "q "__percpu_arg(0) \
+ : "+m" (var)); \
+ break; \
+ default: __bad_percpu_size(); \
+ } \
+} while (0)
+
#define percpu_from_op(op, var) \
({ \
typeof(var) ret__; \
@@ -139,6 +162,8 @@ do { \
#define percpu_and(var, val) percpu_to_op("and", per_cpu__##var, val)
#define percpu_or(var, val) percpu_to_op("or", per_cpu__##var, val)
#define percpu_xor(var, val) percpu_to_op("xor", per_cpu__##var, val)
+#define percpu_inc(var) percpu_to_op0("inc", per_cpu__##var)
+#define percpu_dec(var) percpu_to_op0("dec", per_cpu__##var)
/* This is not atomic against other CPUs -- CPU preemption needs to be off */
#define x86_test_and_clear_bit_percpu(bit, var) \
diff --git a/include/asm-generic/percpu.h b/include/asm-generic/percpu.h
index 00f45ff..c57357e 100644
--- a/include/asm-generic/percpu.h
+++ b/include/asm-generic/percpu.h
@@ -120,6 +120,14 @@ do { \
# define percpu_sub(var, val) __percpu_generic_to_op(var, (val), -=)
#endif
+#ifndef percpu_inc
+# define percpu_inc(var) do { percpu_add(var, 1); } while (0)
+#endif
+
+#ifndef percpu_dec
+# define percpu_dec(var) do { percpu_sub(var, 1); } while (0)
+#endif
+
#ifndef percpu_and
# define percpu_and(var, val) __percpu_generic_to_op(var, (val), &=)
#endif
next prev parent reply other threads:[~2009-04-01 17:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-01 8:13 [PATCH] x86: percpu_to_op() misses memory and flags clobbers Eric Dumazet
2009-04-01 9:02 ` Jeremy Fitzhardinge
2009-04-01 10:14 ` Eric Dumazet
2009-04-01 16:12 ` Ingo Molnar
2009-04-01 16:41 ` Jeremy Fitzhardinge
2009-04-01 16:44 ` Ingo Molnar
2009-04-01 17:13 ` Eric Dumazet [this message]
2009-04-01 18:07 ` Jeremy Fitzhardinge
2009-04-01 18:47 ` Eric Dumazet
2009-04-02 9:52 ` Herbert Xu
2009-04-02 14:12 ` Jeremy Fitzhardinge
2009-04-01 18:44 ` [RFC] percpu: convert SNMP mibs to new infra Eric Dumazet
2009-04-02 0:13 ` Tejun Heo
2009-04-02 4:05 ` Ingo Molnar
2009-04-02 8:07 ` [PATCH] " Eric Dumazet
2009-04-03 0:39 ` Tejun Heo
2009-04-03 17:10 ` Ingo Molnar
2009-04-02 5:04 ` [RFC] " Rusty Russell
2009-04-02 5:19 ` Eric Dumazet
2009-04-02 11:46 ` Rusty Russell
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=49D3A0C2.9000403@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=htejun@gmail.com \
--cc=jeremy@goop.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).