linux-kernel - Re: i386 mm: Is the BUILD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <cdfdcde5-811e-2eb8-63de-df36ca174e43@infradead.org>
Date:   Tue, 17 Jan 2017 12:08:18 -0800
From:   Randy Dunlap <rdunlap@...radead.org>
To:     "Delien, Robert" <robert.delien@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: i386 mm: Is the BUILD_BUG() macro broken?

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