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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 17 Jul 2014 09:39:10 -0500 (CDT)
From:	Christoph Lameter <>
To:	Pranith Kumar <>
Subject: Re: [PATCH v2 1/1] doc: Add remote CPU access details and others to

On Thu, 17 Jul 2014, Pranith Kumar wrote:

> > The use of atomic_t implies a remote write operation to a percpu area.
> >
> > atomic_t needs to be avoided. If data needs to be modified from multiple
> > cpus then it usually does not belong into a percpu area.
> >
> Yes, I think I made it pretty clear that remote accesses need to be avoided
> unless absolutely necessary. But, there will be scenarios where mostly local
> data will need to be have remote accesses. In such scenarios, isn't using
> atomic_t better? FYI, that is how RCU code currently works. It uses atomic_t in
> per cpu areas to ensure atomicity for remote accesses.

The RCU code has .... ummmm... some issues with percpu usage and should
not be taken as a good example. If you look at the RCU code it looks
horrible with numerous barriers around remote percpu read/wrirte
accesses and one wonders if that code is actually ok.

> If data needs to be modified from multiple cpus only very rarely, doesn't it
> make sense to use per-cpu areas?

I would suggest that this should not occur. You can always "modify" remote
percpu areas by generating an IPI on that cpu to make that processor
update its own per cpu data.

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