All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: cl@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, David Howells <dhowells@redhat.com>,
	Ingo Molnar <mingo@elte.hu>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Eric Dumazet <dada1@cosmosbay.com>,
	davem@davemloft.net
Subject: Re: [this_cpu_xx 01/11] Introduce this_cpu_ptr() and generic this_cpu_* operations
Date: Wed, 17 Jun 2009 17:19:37 +0900	[thread overview]
Message-ID: <4A38A719.2030709@kernel.org> (raw)
In-Reply-To: <20090605191850.441840884@gentwo.org>

Hello,

cl@linux-foundation.org wrote:
> +#ifndef this_cpu_write
> +# define this_cpu_write(pcp, val)	__this_cpu_write((pcp), (val))
> +#endif

Is this safe?  Write itself would always be atomic but this means that
a percpu variable may change its value while a thread is holding the
processor by disabling preemption.  ie,

0. v contains A for cpu0

1. task0 on cpu0 does this_cpu_write(v, B), looks up cpu but gets
   preemted out.

2. task1 gets scheduled on cpu1, disables preemption and does
   __this_cpu_read(v) and gets A and goes on with preemtion disabled.

3. task0 gets scheduled on cpu1 and executes the assignment.

4. task1 does __this_cpu_read(v) again and oops gets B this time.

Please note that this can also happen between addition or other
modifying ops and cause incorrect result.

Also, these macros depricate percpu_OP() macros, right?

Thanks.

-- 
tejun

  parent reply	other threads:[~2009-06-17  8:20 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-05 19:18 [this_cpu_xx 00/11] Introduce this_cpu_xx operations cl
2009-06-05 19:18 ` [this_cpu_xx 01/11] Introduce this_cpu_ptr() and generic this_cpu_* operations cl
2009-06-10  5:12   ` Tejun Heo
2009-06-11 15:10     ` Christoph Lameter
2009-06-12  2:09       ` Tejun Heo
2009-06-12 14:18         ` Christoph Lameter
2009-06-17  8:09           ` Tejun Heo
2009-06-17  8:19   ` Tejun Heo [this message]
2009-06-17 18:41     ` Christoph Lameter
2009-06-18  1:08       ` Tejun Heo
2009-06-18  3:01       ` Rusty Russell
2009-06-05 19:18 ` [this_cpu_xx 02/11] Use this_cpu operations for SNMP statistics cl
2009-06-05 19:18 ` [this_cpu_xx 03/11] Use this_cpu operations for NFS statistics cl
2009-06-05 19:18 ` [this_cpu_xx 04/11] Use this_cpu ops for network statistics cl
2009-06-08 11:27   ` Robin Holt
2009-06-08 20:49     ` Christoph Lameter
2009-06-08 20:54       ` Ingo Molnar
2009-06-05 19:18 ` [this_cpu_xx 05/11] this_cpu_ptr: Straight transformations cl
2009-06-05 19:18 ` [this_cpu_xx 06/11] Eliminate get/put_cpu cl
2009-06-05 19:34   ` Dan Williams
2009-06-09 14:02     ` Sosnowski, Maciej
2009-06-05 19:18 ` [this_cpu_xx 07/11] xfs_icsb_modify_counters does not need "cpu" variable cl
2009-06-05 19:22   ` Christoph Hellwig
2009-06-05 19:36     ` Christoph Lameter
2009-06-05 19:18 ` [this_cpu_xx 08/11] Use this_cpu_ptr in crypto subsystem cl
2009-06-05 19:18 ` [this_cpu_xx 09/11] X86 optimized this_cpu operations cl
2009-06-05 19:18 ` [this_cpu_xx 10/11] Use this_cpu ops for vm statistics cl
2009-06-05 19:18 ` [this_cpu_xx 11/11] RCU: Use this_cpu operations cl
2009-06-10 17:42   ` Paul E. McKenney

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=4A38A719.2030709@kernel.org \
    --to=tj@kernel.org \
    --cc=cl@linux-foundation.org \
    --cc=dada1@cosmosbay.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --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 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.