Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1560795 > unrolled thread

i386 mm: Is the BUILD_BUG() macro broken?

Back to article view | Back to linux.kernel

Contents

  i386 mm: Is the BUILD_BUG() macro broken? "Delien, Robert" <robert.delien@hbm.com> - 2017-01-17 17:50 +0100
    Re: i386 mm: Is the BUILD_BUG() macro broken? Randy Dunlap <rdunlap@infradead.org> - 2017-01-17 21:20 +0100

#1560795 — i386 mm: Is the BUILD_BUG() macro broken?

Hi,

I am building Kernel 4.9.4 i386_defconfig and I notice a lot of (unconditional) use of the macro HPAGE_PMD_NR:

In mm/huge_mm.h:
...
#define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
#define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)

#ifdef CONFIG_TRANSPARENT_HUGEPAGE
...
#else /* CONFIG_TRANSPARENT_HUGEPAGE */
#define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
#define HPAGE_PMD_MASK ({ BUILD_BUG(); 0; })
#define HPAGE_PMD_SIZE ({ BUILD_BUG(); 0; })
...

Using HPAGE_PMD_SHIFT with CONFIG_TRANSPARENT_HUGEPAGE  out-configured should trip the BUILD_BUG() macro, but somehow doesn't. Or, more likely, I am missing something.

However, the BUILD_BUG() macro _does_ trip as expected when trying to compile without inlines (-fno-inline), at the locations on the list below. If I replace the offending macros in the list below with '0', no other compiler errors occur. The Kernel still won't link, but that was expected.

When building with -fno-inline and CONFIG_TRANSPARENT_HUGEPAGE  configured-in, no BUILD_BUG() (or other compiler errors) occur, as expected. So I do think this is a valid test case for the BUILD_BUG() macro.

Am I missing something obvious here? Any hint is appreciated!

Thanks,

        Robert.


mm/filemap.c:338: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/truncate.c:161: 'HPAGE_PMD_SIZE' -> BUILD_BUG()
mm/truncate.c:502: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/truncate.c:503: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/truncate.c:505: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/shmem.c:557: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/shmem.c:562: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/shmem.c:567: 'THP_FILE_ALLOC' -> BUILD_BUG()
mm/shmem.c:791: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/shmem.c:800: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/shmem.c:801: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/shmem.c:892: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/shmem.c:896: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/shmem.c:905: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/shmem.c:906: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/shmem.c:1728: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/shmem.c:1764: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/shmem.c:2197: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/gup.c:311: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/memory.c:1240: 'HPAGE_PMD_SIZE' -> BUILD_BUG()
mm/mprotect.c:165: 'HPAGE_PMD_SIZE' -> BUILD_BUG()
mm/mprotect.c:174: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/mremap.c:216: 'HPAGE_PMD_SIZE' -> BUILD_BUG()
mm/rmap.c:1319: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
mm/rmap.c:1278: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()

HBM Netherlands B.V., Schutweg 15a, NL-5145 NP Waalwijk, The Netherlands | www.hbm.com

Registered as B.V. (Dutch limited liability company) in the Dutch commercial register 08183075 0000
Company domiciled in Waalwijk | Managing Directors : Ben Keetman, Peter Ackermans

The information in this email is confidential. It is intended solely for the addressee. If you are not the intended recipient, please let me know and delete this email.

[toc] | [next] | [standalone]

#1560984

Please wrap long text lines around column 70 or so. Thanks.

I'll take a shot at answering this. Maybe someone will correct me if
I am mistaken.


On 01/17/17 08:32, Delien, Robert wrote:
> Hi,
> 
> I am building Kernel 4.9.4 i386_defconfig and I notice a lot of (unconditional) use of the macro HPAGE_PMD_NR:
> 
> In mm/huge_mm.h:
> ...
> #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT)
> #define HPAGE_PMD_NR (1<<HPAGE_PMD_ORDER)
> 
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> ...
> #else /* CONFIG_TRANSPARENT_HUGEPAGE */
> #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
> #define HPAGE_PMD_MASK ({ BUILD_BUG(); 0; })
> #define HPAGE_PMD_SIZE ({ BUILD_BUG(); 0; })
> ...
> 
> Using HPAGE_PMD_SHIFT with CONFIG_TRANSPARENT_HUGEPAGE  out-configured should trip the BUILD_BUG() macro, but somehow doesn't. Or, more likely, I am missing something.
> 
> However, the BUILD_BUG() macro _does_ trip as expected when trying to compile without inlines (-fno-inline), at the locations on the list below. If I replace the offending macros in the list below with '0', no other compiler errors occur. The Kernel still won't link, but that was expected.
> 
> When building with -fno-inline and CONFIG_TRANSPARENT_HUGEPAGE  configured-in, no BUILD_BUG() (or other compiler errors) occur, as expected. So I do think this is a valid test case for the BUILD_BUG() macro.
> 
> Am I missing something obvious here? Any hint is appreciated!
> 
> Thanks,
> 
>         Robert.
> 
> 
> mm/filemap.c:338: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()

Use of HPAGE_PMD_NR is guarded by
	if (PageTransHuge(page) && !PageHuge(page)) {
which is always false, so the block contents are not compiled.

Look at the object code generated for delete_from_page_cache() [the usage above]
and you won't see code for that block.

> mm/truncate.c:161: 'HPAGE_PMD_SIZE' -> BUILD_BUG()
> mm/truncate.c:502: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
> mm/truncate.c:503: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
> mm/truncate.c:505: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()

above uses are guarded by PageTransHuge() [false]

OTOH, (still in truncate.c) if I use HPAGE_PMD_NR at the beginning of
invalidate_mapping_pages(), like this:
	///pagevec_init(&pvec, 0);
	pagevec_init(&pvec, HPAGE_PMD_NR);
it does cause a build-time error.

Or in delete_from_page_cache(), if I change the call to put_page() like this:
	} else {
		///put_page(page);
		put_page((struct page *)(HPAGE_PMD_NR));
	}
this also causes a build-time error.

Note that if I make a typo (e.g. HPAGE_PMD_RN) inside a [false] block,
that will still cause a syntax error.


> mm/shmem.c:557: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
> mm/shmem.c:562: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
> mm/shmem.c:567: 'THP_FILE_ALLOC' -> BUILD_BUG()
> mm/shmem.c:791: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
> mm/shmem.c:800: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
> mm/shmem.c:801: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
> mm/shmem.c:892: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
> mm/shmem.c:896: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
> mm/shmem.c:905: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
> mm/shmem.c:906: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
> mm/shmem.c:1728: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
> mm/shmem.c:1764: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
> mm/shmem.c:2197: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()

above are guarded by PageTransHuge() [false] or by
!IS_ENABLED(CONFIG_some_HUGE_whatever) [false]

> mm/gup.c:311: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
> mm/memory.c:1240: 'HPAGE_PMD_SIZE' -> BUILD_BUG()

> mm/mprotect.c:165: 'HPAGE_PMD_SIZE' -> BUILD_BUG()
> mm/mprotect.c:174: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()

above are guarded by pmd_trans_huge(), which is always false.

> mm/mremap.c:216: 'HPAGE_PMD_SIZE' -> BUILD_BUG()
> mm/rmap.c:1319: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()
> mm/rmap.c:1278: 'HPAGE_PMD_NR' - > 'HPAGE_PMD_ORDER' -> 'HPAGE_PMD_SHIFT' -> BUILD_BUG()

above are guarded by PageTransHuge(), which is always false.
or by:
	if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE))
		return;


> HBM Netherlands B.V., Schutweg 15a, NL-5145 NP Waalwijk, The Netherlands | www.hbm.com
> 
> Registered as B.V. (Dutch limited liability company) in the Dutch commercial register 08183075 0000
> Company domiciled in Waalwijk | Managing Directors : Ben Keetman, Peter Ackermans
> 
> The information in this email is confidential. It is intended solely for the addressee. If you are not the intended recipient, please let me know and delete this email.

Not!

-- 
~Randy

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web