linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Huang, Ying" <ying.huang@intel.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>
Cc: kernel test robot <lkp@intel.com>,
	 oe-kbuild-all@lists.linux.dev,
	Linux Memory Management List <linux-mm@kvack.org>,
	 Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [linux-next:master 10352/10516] include/linux/mm.h:101:35: error: 'MAX_PHYSMEM_BITS' undeclared
Date: Wed, 11 Sep 2024 09:06:53 +0800	[thread overview]
Message-ID: <87ttenvw0i.fsf@yhuang6-desk2.ccr.corp.intel.com> (raw)
In-Reply-To: <20240910104056.343d7154134fb7fc6942075a@linux-foundation.org> (Andrew Morton's message of "Tue, 10 Sep 2024 10:40:56 -0700")

Andrew Morton <akpm@linux-foundation.org> writes:

> On Tue, 10 Sep 2024 13:42:30 +0800 "Huang, Ying" <ying.huang@intel.com> wrote:
>
>> >>       93 |         ({ type ux = (x); type uy = (y); __cmp(op, ux, uy); })
>> >>          |                                      ^
>> >
>> > Thanks. "resource, kunit: add test case for region_intersects" is the culprit.
>> 
>> Yes.  Although the definition in include/linux/mm.h introduced in
>> 
>>   commit ea72ce5da228 ("x86/kaslr: Expose and use the end of the physical memory address space")
>> 
>> doesn't compile on m68k.  There are no users of PHYSMEM_END before patch
>> "resource, kunit: add test case for region_intersects".  This can be
>> fixed via the following patch.
>> 
>> ---------------------------------8<--------------------------------------
>> >From 00d176e0cd07e3df1ea37a5e56ca576c819b585a Mon Sep 17 00:00:00 2001
>> From: Huang Ying <ying.huang@intel.com>
>> Date: Tue, 10 Sep 2024 13:20:40 +0800
>> Subject: [PATCH] mm: fix PHYSMEM_END build error on m68k
>> 
>> 0Day build system reported build error on m68k architecture for missing
>> the definition of MAX_PHYSMEM_BITS when defining PHYSMEM_END.  Fixed it
>> via making PHYSMEM_END definition depends on MAX_PHYSMEM_BITS definition
>> conditionally.
>> 
>> Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Closes: https://lore.kernel.org/oe-kbuild-all/202409100913.RxkfrKU6-lkp@intel.com/
>> ---
>>  include/linux/mm.h | 6 +++++-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>> 
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 147073601716..62bb7e7e0a17 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -98,7 +98,11 @@ extern int mmap_rnd_compat_bits __read_mostly;
>>  #endif
>>  
>>  #ifndef PHYSMEM_END
>> -# define PHYSMEM_END	((1ULL << MAX_PHYSMEM_BITS) - 1)
>> +# ifdef MAX_PHYSMEM_BITS
>> +#  define PHYSMEM_END		((1ULL << MAX_PHYSMEM_BITS) - 1)
>> +# else
>> +#  define PHYSMEM_END		(-1ULL)
>> +# endif
>>  #endif
>>  
>>  #include <asm/page.h>
>
> I'm not really understanding.  This patch (which I assume is against
> linux-next?) requires the presence of ea72ce5da228 ("x86/kaslr: Expose
> and use the end of the physical memory address space"), which is not
> present in mm.git.  Yet mm.git exhibits the build failure.

The original test report is against linux-next tree instead mm tree.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

The first bad commit (bisection result) is:

5f445800cbdfc4b4185d496a43dfd78df63d2265 [10352/10516] Merge branch 'mm-everything' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

That is, mm tree is merged in linux-next, and commit ea72ce5da228
("x86/kaslr: Expose and use the end of the physical memory address
space") is merged in linux-next too.  In fact, there's a merge conflict
for MAX_PHYSMEM_BITS related code.  Maybe this can be part of merge
conflict resolving patch?

Hi, Stephen,

Can you use the patch above as part of merged conflict resolving patch
for patch

e2941fe697c8 ("resource, kunit: add test case for region_intersects()")

You have resolved it in

https://lore.kernel.org/lkml/20240909100043.60668995@canb.auug.org.au/

--
Best Regards,
Huang, Ying


  reply	other threads:[~2024-09-11  1:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-10  1:33 kernel test robot
2024-09-10  3:45 ` Andrew Morton
2024-09-10  5:42   ` Huang, Ying
2024-09-10 17:40     ` Andrew Morton
2024-09-11  1:06       ` Huang, Ying [this message]
2024-09-11  2:32         ` Stephen Rothwell
2024-09-11  3:45         ` Andrew Morton
2024-09-11  5:18           ` Huang, Ying

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=87ttenvw0i.fsf@yhuang6-desk2.ccr.corp.intel.com \
    --to=ying.huang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=sfr@canb.auug.org.au \
    --cc=tglx@linutronix.de \
    /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