On Thu, Oct 03, 2019 at 01:40:38PM -0700, John Hubbard wrote: > On 10/3/19 4:51 AM, Peter Zijlstra wrote: > > On Thu, Oct 03, 2019 at 09:11:45AM +0200, Peter Zijlstra wrote: > >> On Wed, Oct 02, 2019 at 10:33:15PM -0300, Leonardo Bras wrote: > ... > > > > I'm still really confused about this barrier. It just doesn't make > > sense. > > > > If an interrupt happens before the local_irq_disable()/save(), then it > > will discard any and all speculation that would be in progress to handle > > the exception. > > > > Hi Peter, > > So, would that imply that it's correct to apply approximately the following > patch: > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > index 1adbb8a371c7..cf41eff37e24 100644 > --- a/Documentation/memory-barriers.txt > +++ b/Documentation/memory-barriers.txt > @@ -2099,9 +2099,9 @@ INTERRUPT DISABLING FUNCTIONS > ----------------------------- > > Functions that disable interrupts (ACQUIRE equivalent) and enable interrupts > -(RELEASE equivalent) will act as compiler barriers only. So if memory or I/O > -barriers are required in such a situation, they must be provided from some > -other means. > +(RELEASE equivalent) will act as full memory barriers. This is because, for > +all supported CPU architectures, interrupt arrival causes all speculative > +memory accesses to be discarded. > > ? No, you're misunderstanding. They imply nothing of the sort.
