linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* i386 mm: Is the BUILD_BUG() macro broken?
@ 2017-01-17 16:32 Delien, Robert
  2017-01-17 20:08 ` Randy Dunlap
  0 siblings, 1 reply; 2+ messages in thread
From: Delien, Robert @ 2017-01-17 16:32 UTC (permalink / raw)
  To: linux-kernel

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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: i386 mm: Is the BUILD_BUG() macro broken?
  2017-01-17 16:32 i386 mm: Is the BUILD_BUG() macro broken? Delien, Robert
@ 2017-01-17 20:08 ` Randy Dunlap
  0 siblings, 0 replies; 2+ messages in thread
From: Randy Dunlap @ 2017-01-17 20:08 UTC (permalink / raw)
  To: Delien, Robert, linux-kernel

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-01-17 20:09 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-17 16:32 i386 mm: Is the BUILD_BUG() macro broken? Delien, Robert
2017-01-17 20:08 ` Randy Dunlap

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).