On Thu, Mar 10, 2016 at 08:34:28PM +0000, Al Viro wrote: > Speaking of barriers - why do we need one there at all? In __d_alloc(), that > is. Look: callers of __d_alloc() are: > * d_alloc() - cycles parent's ->d_lock, inserts into the list of > parent's children. Anyone observing it on that list of children will be > holding the same parent's ->d_lock. And anyone finding it in any other way > will have to observe the effect of store done after the write barrier in > spin_unlock. ... which still leaves the possibility of both stores migrating inside the lock/unlock pair and past each other. IOW, lock parent's d_lock lock child's d_lock put into hash store terminating NUL in ->d_name unlock parent's d_lock unlock child's d_lock is a possible sequence of events, with RCU access on another CPU observing the damn without seeing the NUL-terminated name ;-/ Oh, well... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
