Re: linux-next: Tree for Apr 14 (mm/shmem.c)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 14 Apr 2020, Andrew Morton wrote:
> On Tue, 14 Apr 2020 07:18:01 -0700 Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote:
> > On 4/13/20 7:39 PM, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Changes since 20200413:
> > > 
> > > New tree: mhi
> > > 
> > > My fixes tree contains:
> > > 
> > >   6b038bdcd3d1 sh: mm: Fix build error
> > > 
> > > Non-merge commits (relative to Linus' tree): 1154
> > >  1160 files changed, 31764 insertions(+), 13498 deletions(-)
> > > 
> > > ----------------------------------------------------------------------------
> > 
> > on x86_64:
> > # CONFIG_TRANSPARENT_HUGEPAGE is not set
> 
> Thanks.  hm, this took a long time to be discovered.
> 
> > In file included from ../include/linux/export.h:43:0,
> >                  from ../include/linux/linkage.h:7,
> >                  from ../include/linux/fs.h:5,
> >                  from ../mm/shmem.c:24:
> > ../mm/shmem.c: In function ‘shmem_undo_range’:
...
> > ../mm/shmem.c:961:26: note: in expansion of macro ‘HPAGE_PMD_NR’
> >           round_up(start, HPAGE_PMD_NR))
> >                           ^~~~~~~~~~~~
> 
> That's
> 					if (index <
> 					    round_up(start, HPAGE_PMD_NR))
> 						start = index + 1;
> 
> from Hugh's 71725ed10c40696 ("mm: huge tmpfs: try to split_huge_page()
> when punching hole").

Sorry about that.  Yes, odd that it should only hit now: the false
PageTransCompound in shmem_punch_compound() has always been good
enough to handle it for me, but maybe Randy is trying a less able
compiler, or maybe unrelated changes in linux-next have just made
it harder for the compiler to see the optimization.

I hope the patch below fixes it?

[PATCH] mm/shmem: fix build without THP

Some optimizers don't notice that shmem_punch_compound() is always true
(PageTransCompound() being false) without CONFIG_TRANSPARENT_HUGEPAGE=y:
use IS_ENABLED to help them to avoid the BUILD_BUG inside HPAGE_PMD_NR.

Fixes: 71725ed10c40 ("mm: huge tmpfs: try to split_huge_page() when punching hole")
Reported-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx>
---

 mm/shmem.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 5.7-rc1/mm/shmem.c	2020-04-11 12:58:26.415524805 -0700
+++ linux/mm/shmem.c	2020-04-14 23:20:25.517656174 -0700
@@ -952,7 +952,7 @@ static void shmem_undo_range(struct inod
 				VM_BUG_ON_PAGE(PageWriteback(page), page);
 				if (shmem_punch_compound(page, start, end))
 					truncate_inode_page(mapping, page);
-				else {
+				else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) {
 					/* Wipe the page and don't get stuck */
 					clear_highpage(page);
 					flush_dcache_page(page);

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux