On Fri, Jan 03, 2020 at 11:24:20AM +0100, Petr Mladek wrote: > On Mon 2019-12-23 17:01:00, John Ogness wrote: > > Hi Andrea, > > > > On 2019-12-21, Andrea Parri <parri.andrea@xxxxxxxxx> wrote: > > >> + *desc_out = READ_ONCE(*desc); > > >> + > > >> + /* Load data before re-checking state. */ > > >> + smp_rmb(); /* matches LMM_REF(desc_reserve:A) */ > > > > > > I looked for a matching WRITE_ONCE() or some other type of marked write, > > > but I could not find it. What is the rationale? Or what did I miss? > > Good question. READ_ONCE() looks superfluous here because it is > surrounded by two read barriers. In each case, there is no > corresponding WRITE_ONCE(). > > Note that we are copying the entire struct prb_desc here. All values > are written only when state_val is in desc_reserved state. It happens > between two full write barriers: > > + A writer is allowed to modify the descriptor after successful > cmpxchg in desc_reserve(), see LMM_TAG(desc_reserve:A). > > + The writer must not touch the descriptor after changing > state_var to committed state, see > LMM_TAG(prb_commit:A) in prb_commit(). > > These barriers are mentioned in the comments for the two > read barriers here. Thanks for these remarks. As usual, I'd recommend to (try to) map those comments into litmus tests and check with the LKMM simulator. > BTW: Documentation/memory-barriers.txt describes various aspects of > the memory barriers. It describes implicit barriers provided > by spin locks, mutexes, semaphores, and various scheduler-related > operations. > > But I can't find any explanation of the various variants of the atomic > operations: acquire, release, fetch, return, try, relaxed. I can find > some clues here and there but it is hard to get the picture. Documentation/atomic_t.txt could serve this purpose. Please have a look there and let me know if you have any comments. Thanks, Andrea _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
