[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1907181103120.1984@nanos.tec.linutronix.de>
Date: Thu, 18 Jul 2019 11:04:57 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Joerg Roedel <jroedel@...e.de>
cc: Joerg Roedel <joro@...tes.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 2/3] x86/mm: Sync also unmappings in vmalloc_sync_one()
Joerg,
On Thu, 18 Jul 2019, Joerg Roedel wrote:
> On Wed, Jul 17, 2019 at 11:43:43PM +0200, Thomas Gleixner wrote:
> > On Wed, 17 Jul 2019, Joerg Roedel wrote:
> > > +
> > > + if (!pmd_present(*pmd_k))
> > > + return NULL;
> > > else
> > > BUG_ON(pmd_pfn(*pmd) != pmd_pfn(*pmd_k));
> >
> > So in case of unmap, this updates only the first entry in the pgd_list
> > because vmalloc_sync_all() will break out of the iteration over pgd_list
> > when NULL is returned from vmalloc_sync_one().
> >
> > I'm surely missing something, but how is that supposed to sync _all_ page
> > tables on unmap as the changelog claims?
>
> No, you are right, I missed that. It is a bug in this patch, the code
> that breaks out of the loop in vmalloc_sync_all() needs to be removed as
> well. Will do that in the next version.
I assume that p4d/pud do not need the pmd treatment, but a comment
explaining why would be appreciated.
Thanks,
tglx
Powered by blists - more mailing lists