On Fri, Jun 28, 2019 at 11:44:11AM -0400, Steven Rostedt wrote: > On Fri, 28 Jun 2019 19:40:45 +0900 > Byungchul Park <byungchul.park@xxxxxxx> wrote: > > > Wait.. I got a little bit confused on recordering. > > > > This 'STORE rcu_read_lock_nesting = 0' can happen before > > 'STORE rcu_read_unlock_special.b.exp_hint = false' regardless of the > > order a compiler generated to by the barrier(), because anyway they > > are independent so it's within an arch's right. > > > > Then.. is this scenario possible? Or all archs properly deal with > > interrupts across this kind of reordering? > > As Paul stated, interrupts are synchronization points. Archs can only > play games with ordering when dealing with entities outside the CPU > (devices and other CPUs). But if you have assembly that has two stores, > and an interrupt comes in, the arch must guarantee that the stores are > done in that order as the interrupt sees it. > > If this is not the case, there's a hell of a lot more broken in the > kernel than just this, and "barrier()" would also be meaningless, as > that is used mostly to deal with interrupts. Clear. Dear Paul and Steve, Thank you. > -- Steve
