On Fri, Feb 22, 2019 at 02:00:14PM +0100, Peter Zijlstra wrote: > On Fri, Feb 22, 2019 at 12:21:28PM +0100, Andrea Parri wrote: > > > What I do object to is a model that's weaker than any possible sane > > > hardware. > > > > Not the first time I hear you calling this out. And inevitably, every > > time, other slogans come to my mind: "C is not an assembly language", > > But it bloody well should be ;-) Yeah, we had some debates about this sort of thing at the C++ Standards Committee meeting last week. Pointer provenance and concurrent algorithms, though for once not affecting RCU! We might actually be on the road to a fix that preserves the relevant optimizations while still allowing most (if not all) existing concurrent C/C++ code to continue working correctly. (The current thought is that loads and stores involving inline assembly, C/C++ atomics, or volatile get their provenance stripped. There may need to be some other mechanisms for plain C-language loads and stores in some cases as well.) But if you know of any code in the Linux kernel that needs to compare pointers, one of which might be in the process of being freed, please do point me at it. I thought that the smp_call_function() code fit, but it avoids the problem because only the sending CPU is allowed to push onto the stack of pending smp_call_function() invocations. That same concurrent linked stack pattern using cmpxchg() to atomically push and xchg() to atomically pop the full list -would- have this problem. The old pointer passed to cmpxchg() might reference an object that was freed between the time that the old pointer was loaded and the time that the cmpxchg() executed. One way to avoid this is to do the push operation in an RCU read-side critical section and use kfree_rcu() instead of kfree(). Of course, code in the idle loop or that might run on offline CPUs cannot use RCU, plus some data structures are not happy with kfree_rcu() delays, so... Again, if you know of any code in the Linux kernel that would have problems with aggressive optimizations based on pointer provenance, please let me know! Thanx, Paul
