From: Barry Song <21cnbao@gmail.com>
To: wale zhang <wale.zhang.ftd@gmail.com>
Cc: akpm@linux-foundation.org, lorenzo.stoakes@oracle.com,
chrisl@kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/1] mm,swapops: Fix compile error on set_pmd_migration_entry.
Date: Sat, 27 Dec 2025 21:16:35 +1300 [thread overview]
Message-ID: <CAGsJ_4zg_DgQnQthTqWOnwUrhm-MygVB6mOwmgK=ey2dYogb+Q@mail.gmail.com> (raw)
In-Reply-To: <CAHrEdeuBk_MoPj1jWdtdLODK0JOWrb2orTZ77Cbp1vZ3PM3x9g@mail.gmail.com>
On Sat, Dec 27, 2025 at 8:51 PM wale zhang <wale.zhang.ftd@gmail.com> wrote:
>
> On Sat, Dec 27, 2025 at 2:43 AM Barry Song <21cnbao@gmail.com> wrote:
> >
> > On Sat, Dec 27, 2025 at 12:46 AM wale zhang <wale.zhang.ftd@gmail.com> wrote:
> > >
> > > On Thu, Dec 25, 2025 at 6:22 PM Barry Song <21cnbao@gmail.com> wrote:
> > > >
> > > > On Thu, Dec 25, 2025 at 10:41 PM Wale Zhang <wale.zhang.ftd@gmail.com> wrote:
> > > > >
> > > > > ../include/linux/swapops.h: In function ‘set_pmd_migration_entry’:
> > > > > ../include/linux/swapops.h:346:1: error: no return statement in function returning non-void [-Werror=return-type]
> > > > > 346 | }
> > > > > | ^
> > > > > cc1: some warnings being treated as errors
> > > > >
> > > > > Signed-off-by: Wale Zhang <wale.zhang.ftd@gmail.com>
> > > >
> > > > Sorry. NAK.
> > > >
> > > > This looks odd. We already have a BUILD_BUG(), so no fix is needed.
> > > >
> > > > we should already have:
> > > > ././include/linux/compiler_types.h:631:45: error: call to
> > > > ‘__compiletime_assert_907’ declared with attribute error: BUILD_BUG
> > > > failed
> > > > 631 | _compiletime_assert(condition, msg,
> > > > __compiletime_assert_, __COUNTER__)
> > > > | ^
> > > > ././include/linux/compiler_types.h:612:25: note: in definition of
> > > > macro ‘__compiletime_assert’
> > > > 612 | prefix ## suffix();
> > > > \
> > > > | ^~~~~~
> > > >
> > > > Do you actually see this being built? If so, please help identify why it
> > > > gets built.
> > >
> > > Hello Barry,
> > >
> > > I compile the 6.19-rc2 for arm64 with -O0, this kind of error log will appear.
> > > In file included from /home/wale/repo/linux/master/include/linux/leafops.h:11,
> > > from
> > > /home/wale/repo/linux/master/include/linux/userfaultfd_k.h:19,
> > > from /home/wale/repo/linux/master/include/linux/mm_inline.h:10,
> > > from /home/wale/repo/linux/master/mm/internal.h:13,
> > > from /home/wale/repo/linux/master/mm/fadvise.c:24:
> > > /home/wale/repo/linux/master/include/linux/swapops.h: In function
> > > ‘set_pmd_migration_entry’:
> > > /home/wale/repo/linux/master/include/linux/swapops.h:346:1: error: no
> > > return statement in function returning non-void [-Werror=return-type]
> > > 346 | }
> > > | ^
> > > cc1: some warnings being treated as errors
> > > make[4]: *** [/home/wale/repo/linux/master/scripts/Makefile.build:287:
> > > mm/fadvise.o] Error 1
> > > make[4]: *** Waiting for unfinished jobs....
> > >
> > > There is an example on my
> > > github(https://github.com/wale-ftd/linux/commits/linux-6.12/) that
> > > used -O0 to compile the 6.12 kernel. If you're interested, you can
> > > check them out.
> >
> > This is not my question. The BUILD_BUG here means this code
> > should never be built. If it is built, then that indicates a bug.
> > So my question is: under what kernel configuration would this
> > code actually get built?
>
> Hello Barry,
>
> I'm very sorry for misunderstanding your meaning.
No. You still don’t understand my point. The BUILD_BUG means this
code will never have a chance to be compiled under any possible
kernel configuration. That makes it dead code. If there is any
kernel .config in which it can be built, then we should fix it.
This set_pmd_migration_entry() has no chance of ever being built.
let me give you an example:
#if 0
aaa;
#endif
main()
{
}
Imagine this set_pmd_migration_entry() as aaa.
>
> For -O0, __OPTIMIZE__ isn't defined, so line 615 is hit.
>
> 595 #ifdef __OPTIMIZE__
> 602 # define __compiletime_assert(condition, msg, prefix, suffix) \
> 612 prefix ## suffix();
> 614 #else
> 615 # define __compiletime_assert(condition, msg, prefix, suffix)
> ((void)(condition))
> 616 #endif
>
> Finally, set_pmd_migration_entry is defined as follow:
> static inline int set_pmd_migration_entry(struct page_vma_mapped_walk *pvmw,
> struct page *page)
> {
> - BUILD_BUG();
> + ((void)(0));
> }
>
Thanks
Barry
next prev parent reply other threads:[~2025-12-27 8:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-25 9:40 Wale Zhang
2025-12-25 10:22 ` Barry Song
2025-12-26 11:45 ` wale zhang
2025-12-26 18:43 ` Barry Song
2025-12-27 7:51 ` wale zhang
2025-12-27 8:16 ` Barry Song [this message]
2025-12-27 9:58 ` wale zhang
2025-12-27 11:25 ` Barry Song
2025-12-28 21:37 ` Andrew Morton
2025-12-28 22:07 ` Barry Song
2025-12-29 11:37 ` wale zhang
2025-12-30 5:00 ` Matthew Wilcox
2025-12-30 8:05 ` wale zhang
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='CAGsJ_4zg_DgQnQthTqWOnwUrhm-MygVB6mOwmgK=ey2dYogb+Q@mail.gmail.com' \
--to=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chrisl@kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=wale.zhang.ftd@gmail.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