From: Randy Dunlap <rdunlap@infradead.org>
To: "Delien, Robert" <robert.delien@hbm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: i386 mm: Is the BUILD_BUG() macro broken?
Date: Tue, 17 Jan 2017 12:08:18 -0800 [thread overview]
Message-ID: <cdfdcde5-811e-2eb8-63de-df36ca174e43@infradead.org> (raw)
In-Reply-To: <E7453F1D17491249AF7EA9D69A5D40C50198B867@hbmdax11.hbm.com>
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
prev parent reply other threads:[~2017-01-17 20:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-17 16:32 Delien, Robert
2017-01-17 20:08 ` Randy Dunlap [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cdfdcde5-811e-2eb8-63de-df36ca174e43@infradead.org \
--to=rdunlap@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robert.delien@hbm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®