From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965565AbcAUTTX (ORCPT ); Thu, 21 Jan 2016 14:19:23 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:50667 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759762AbcAUTTV (ORCPT ); Thu, 21 Jan 2016 14:19:21 -0500 Date: Thu, 21 Jan 2016 11:19:19 -0800 From: Andrew Morton To: Gerald Schaefer Cc: kbuild test robot , Michael Holzheu , kbuild-all@01.org, Martin Schwidefsky , Heiko Carstens , linux-mm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] numa: fix /proc//numa_maps on s390 Message-Id: <20160121111919.8327b22f04e790147eefc043@linux-foundation.org> In-Reply-To: <20160121155732.49431112@thinkpad> References: <1453313879-62521-1-git-send-email-holzheu@linux.vnet.ibm.com> <201601210354.l5qn10aD%fengguang.wu@intel.com> <20160120122631.e9c8a842d36d6dba4bb25964@linux-foundation.org> <20160121155732.49431112@thinkpad> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 21 Jan 2016 15:57:32 +0100 Gerald Schaefer wrote: > > --- a/fs/proc/task_mmu.c~numa-fix-proc-pid-numa_maps-on-s390-fix > > +++ a/fs/proc/task_mmu.c > > @@ -1523,6 +1523,7 @@ static int gather_pte_stats(pmd_t *pmd, > > pte_t *pte; > > > > ptl = pmd_trans_huge_lock(pmd, vma); > > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE > > if (ptl) { > > pte_t huge_pte = huge_ptep_get((pte_t *)pmd); > > struct page *page; > > @@ -1534,6 +1535,7 @@ static int gather_pte_stats(pmd_t *pmd, > > spin_unlock(ptl); > > return 0; > > } > > +#endif > > > > if (pmd_trans_unstable(pmd)) > > return 0; > > Hi Andrew, > > Unfortunately this seems to be a lot more complicated than we thought. > huge_ptep_get() is only defined when CONFIG_HUGETLB_PAGE=y, independent > from CONFIG_TRANSPARENT_HUGEPAGE. This is because asm/hugetlb.h is only > included from linux/hugetlb.h when CONFIG_HUGETLB_PAGE=y. > > So this fix won't fix the build error when CONFIG_HUGETLBFS=n and > CONFIG_TRANSPARENT_HUGEPAGE=y. > > Since the THP code did not repeat the flaws of the hugtelbfs code, i.e. > it is actually working on PMD entries and not PTE entries, there was > no need for huge_ptep_get() for THP so far. > > Now it seems that the THP code in gather_pte_stats() is an exception to > this, as it is not working on a PMD like the rest of the THP code, but > also on a fake "PTE" like the hugetlbfs code. > > I guess this needs more thinking, two options are crossing my mind: > - Fix the THP code in gather_pte_stats() to properly use a PMD instead of > PTE. This would probably require something like a "_pmd" version of > "can_gather_numa_stats()" and a pmd_dirty() check for the > gather_stats() parameter. > - Make huge_ptep_get() also available for CONFIG_HUGETLBFS=n, perhaps > by introducing something like HAVE_ARCH_HUGE_PTEP_GET and implementing > the default NOP version in linux/hugetlbfs.h instead of the individual > asm/hugetlbfs.h files for all archs. > > The first option seems more correct, but it might entail other problems. > The second option would also introduce new problems on s390, where the > implementation of huge_ptep_get() in arch/s390/mm/hugetlbpage.c is currently > only built with CONFIG_HUGETLBFS=y, but I guess we could handle that. > > Any thoughts / more ideas? > The first option does of course sound better. But you need numa_maps fixed, presumably in 4.5 and possibly backported into -stable? (The changelog doesn't describe the end-user-visible effects of the bug. Naughty changelog!) So is there some minimal thing we can do for now to get things working properly and fix it for-real in 4.6?