lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 19 Jun 2014 15:42:07 -0500 (CDT)
From:	Christoph Lameter <>
To:	"Paul E. McKenney" <>
cc:	Tejun Heo <>, David Howells <>,
	Linus Torvalds <>,
	Andrew Morton <>,
	Oleg Nesterov <>,
Subject: Re: [PATCH RFC] percpu: add data dependency barrier in percpu
 accessors and operations

On Tue, 17 Jun 2014, Paul E. McKenney wrote:

> > Similar in swapon(). The percpu allocation is performed before access to
> > the containing structure (via enable_swap_info).
> Those are indeed common use cases.  However...
> There is code where one CPU writes to another CPU's per-CPU variables.
> One example is RCU callback offloading, where a kernel thread (which
> might be running anywhere) dequeues a given CPU's RCU callbacks and
> processes them.  The act of dequeuing requires write access to that
> CPU's per-CPU rcu_data structure.  And yes, atomic operations and memory
> barriers are of course required to make this work.

In that case special care needs to be taken to get this right. True.

I typically avoid these scenarios by sending an IPI with a pointer to the
data structure. The modification is done by the cpu for which the per cpu
data is local.

Maybe rewrite the code to avoid writing to other processors percpu data
would be the right approach?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists