On Thu, Jun 10, 2021 at 12:06:17PM +0300, Kirill A. Shutemov wrote: > On Wed, Jun 09, 2021 at 11:38:11PM -0700, Hugh Dickins wrote: > > page_vma_mapped_walk() cleanup: use pmd_read_atomic() with barrier() > > instead of READ_ONCE() for pmde: some architectures (e.g. i386 with PAE) > > have a multi-word pmd entry, for which READ_ONCE() is not good enough. > > > > Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx> > > Cc: <stable@xxxxxxxxxxxxxxx> > > mm/page_vma_mapped.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c > > index 7c0504641fb8..973c3c4e72cc 100644 > > +++ b/mm/page_vma_mapped.c > > @@ -182,13 +182,16 @@ bool page_vma_mapped_walk(struct page_vma_mapped_walk *pvmw) > > pud = pud_offset(p4d, pvmw->address); > > if (!pud_present(*pud)) > > return false; > > + > > pvmw->pmd = pmd_offset(pud, pvmw->address); > > /* > > * Make sure the pmd value isn't cached in a register by the > > * compiler and used as a stale value after we've observed a > > * subsequent update. > > */ > > - pmde = READ_ONCE(*pvmw->pmd); > > + pmde = pmd_read_atomic(pvmw->pmd); > > + barrier(); > > + > > Hm. It makes me wounder if barrier() has to be part of pmd_read_atomic(). > mm/hmm.c uses the same pattern as you are and I tend to think that the > rest of pmd_read_atomic() users may be broken. > > Am I wrong? I agree with you, something called _atomic should not require the caller to provide barriers. I think the issue is simply that the two implementations of pmd_read_atomic() should use READ_ONCE() internally, no? Jason
