Messages in this thread | | | Date | Mon, 1 Apr 2019 08:44:14 -0700 | From | "Paul E. McKenney" <> | Subject | Re: Potentially missing "memory" clobbers in bitops.h for x86 |
| |
On Mon, Apr 01, 2019 at 12:53:48PM +0200, Peter Zijlstra wrote: > On Fri, Mar 29, 2019 at 03:05:54PM -0700, Paul E. McKenney wrote: > > On Fri, Mar 29, 2019 at 02:51:26PM -0700, H. Peter Anvin wrote: > > > On 3/29/19 2:09 PM, Paul E. McKenney wrote: > > > >> > > > >> Note: the atomic versions of these functions obviously need to have > > > >> "volatile" and the clobber anyway, as they are by definition barriers > > > >> and moving memory operations around them would be a very serious error. > > > > > > > > The atomic functions that return void don't need to order anything except > > > > the input and output arguments. The oddness with clear_bit() is that the > > > > memory changed isn't necessarily the quantity referenced by the argument, > > > > if the number of bits specified is large. > > > > > > > > So (for example) atomic_inc() does not need a "memory" clobber, right? > > Correct, and many implementations do not, including x86: > > static __always_inline void arch_atomic_inc(atomic_t *v) > { > asm volatile(LOCK_PREFIX "incl %0" > : "+m" (v->counter)); > }
Very good!
> > > I don't believe that is true: the code calling it has a reasonable > > > expectation that previous memory operations have finished and later > > > memory operations have not started from the point of view of another > > > processor. You are more of an expert on memory ordering than I am, but > > > I'm 89% sure that there is plenty of code in the kernel which makes that > > > assumption. > > > > From Documentation/core-api/atomic_ops.rst: > > We should delete that file.
Only if all of its content is fully present elsewhere. ;-)
Thanx, Paul
| |