On Fri, 19 Jul 2019, Joerg Roedel wrote: > On Thu, Jul 18, 2019 at 11:04:57AM +0200, Thomas Gleixner wrote: > > 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. > > Actually there is already a comment in this function explaining why p4d > and pud don't need any treatment: > > /* > * set_pgd(pgd, *pgd_k); here would be useless on PAE > * and redundant with the set_pmd() on non-PAE. As would > * set_p4d/set_pud. > */ Indeed. Why did I think there was none? > I couldn't say it with less words :) It's perfectly fine. Thanks, tglx
