From: Xishi Qiu <qiuxishi@huawei.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>,
Tang Chen <tangchen@cn.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: linux-next: build warnings after merge of the akpm-current tree
Date: Tue, 26 Aug 2014 18:19:30 +0800 [thread overview]
Message-ID: <53FC5F32.6060807@huawei.com> (raw)
In-Reply-To: <20140826172208.1dbc37db@canb.auug.org.au>
On 2014/8/26 15:22, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (arm
> defconfig) produced these warnings:
>
> In file included from /scratch/sfr/next/include/asm-generic/bug.h:13:0,
> from /scratch/sfr/next/arch/arm/include/asm/bug.h:61,
> from /scratch/sfr/next/include/linux/bug.h:4,
> from /scratch/sfr/next/include/linux/thread_info.h:11,
> from /scratch/sfr/next/include/asm-generic/preempt.h:4,
> from arch/arm/include/generated/asm/preempt.h:1,
> from /scratch/sfr/next/include/linux/preempt.h:18,
> from /scratch/sfr/next/include/linux/spinlock.h:50,
> from /scratch/sfr/next/include/linux/mmzone.h:7,
> from /scratch/sfr/next/include/linux/gfp.h:5,
> from /scratch/sfr/next/include/linux/slab.h:14,
> from /scratch/sfr/next/mm/nobootmem.c:13:
> /scratch/sfr/next/mm/nobootmem.c: In function 'free_low_memory_core_early':
> /scratch/sfr/next/include/linux/kernel.h:29:20: warning: large integer implicitly truncated to unsigned type [-Woverflow]
> #define ULLONG_MAX (~0ULL)
> ^
> /scratch/sfr/next/mm/nobootmem.c:122:28: note: in expansion of macro 'ULLONG_MAX'
> memblock_clear_hotplug(0, ULLONG_MAX);
> ^
>
> Introduced by commit 6e162b4c49f7 ("mem-hotplug: let memblock skip the
> hotpluggable memory regions in __next_mem_range()"). The second
> argument to memblock_clear_hotplug() is a phys_addr_t, which varies in
> size between architectures/platforms.
>
/arch/x86/mm/numa.c
numa_init()
...
WARN_ON(memblock_clear_hotplug(0, ULLONG_MAX));
...
This function has the same problem too, right?
#define ULLONG_MAX (~0ULL) -> always 64 bit, right?
#ifdef CONFIG_PHYS_ADDR_T_64BIT -> phys_addr_t is 32 or 64 bit
typedef u64 phys_addr_t;
#else
typedef u32 phys_addr_t;
#endif
Thanks,
Xishi Qiu
WARNING: multiple messages have this Message-ID (diff)
From: Xishi Qiu <qiuxishi@huawei.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>,
Tang Chen <tangchen@cn.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
<linux-next@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: build warnings after merge of the akpm-current tree
Date: Tue, 26 Aug 2014 18:19:30 +0800 [thread overview]
Message-ID: <53FC5F32.6060807@huawei.com> (raw)
In-Reply-To: <20140826172208.1dbc37db@canb.auug.org.au>
On 2014/8/26 15:22, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (arm
> defconfig) produced these warnings:
>
> In file included from /scratch/sfr/next/include/asm-generic/bug.h:13:0,
> from /scratch/sfr/next/arch/arm/include/asm/bug.h:61,
> from /scratch/sfr/next/include/linux/bug.h:4,
> from /scratch/sfr/next/include/linux/thread_info.h:11,
> from /scratch/sfr/next/include/asm-generic/preempt.h:4,
> from arch/arm/include/generated/asm/preempt.h:1,
> from /scratch/sfr/next/include/linux/preempt.h:18,
> from /scratch/sfr/next/include/linux/spinlock.h:50,
> from /scratch/sfr/next/include/linux/mmzone.h:7,
> from /scratch/sfr/next/include/linux/gfp.h:5,
> from /scratch/sfr/next/include/linux/slab.h:14,
> from /scratch/sfr/next/mm/nobootmem.c:13:
> /scratch/sfr/next/mm/nobootmem.c: In function 'free_low_memory_core_early':
> /scratch/sfr/next/include/linux/kernel.h:29:20: warning: large integer implicitly truncated to unsigned type [-Woverflow]
> #define ULLONG_MAX (~0ULL)
> ^
> /scratch/sfr/next/mm/nobootmem.c:122:28: note: in expansion of macro 'ULLONG_MAX'
> memblock_clear_hotplug(0, ULLONG_MAX);
> ^
>
> Introduced by commit 6e162b4c49f7 ("mem-hotplug: let memblock skip the
> hotpluggable memory regions in __next_mem_range()"). The second
> argument to memblock_clear_hotplug() is a phys_addr_t, which varies in
> size between architectures/platforms.
>
/arch/x86/mm/numa.c
numa_init()
...
WARN_ON(memblock_clear_hotplug(0, ULLONG_MAX));
...
This function has the same problem too, right?
#define ULLONG_MAX (~0ULL) -> always 64 bit, right?
#ifdef CONFIG_PHYS_ADDR_T_64BIT -> phys_addr_t is 32 or 64 bit
typedef u64 phys_addr_t;
#else
typedef u32 phys_addr_t;
#endif
Thanks,
Xishi Qiu
next prev parent reply other threads:[~2014-08-26 10:19 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-26 7:22 linux-next: build warnings after merge of the akpm-current tree Stephen Rothwell
2014-08-26 10:19 ` Xishi Qiu [this message]
2014-08-26 10:19 ` Xishi Qiu
-- strict thread matches above, loose matches on Subject: below --
2022-02-09 6:02 Stephen Rothwell
2022-02-09 16:03 ` Hugh Dickins
2022-03-28 23:04 ` Matthew Wilcox
2022-03-29 3:32 ` Hugh Dickins
2022-03-24 7:27 ` Stephen Rothwell
2022-03-28 19:54 ` Hugh Dickins
2022-03-28 22:10 ` Matthew Wilcox
2021-10-11 7:31 Stephen Rothwell
2021-10-11 17:46 ` Kees Cook
2021-06-15 10:50 Stephen Rothwell
2020-10-06 12:05 Stephen Rothwell
2020-10-06 20:01 ` Peter Xu
2020-10-06 22:03 ` Stephen Rothwell
2020-01-06 6:14 Stephen Rothwell
2017-08-24 7:41 Stephen Rothwell
2017-08-24 8:15 ` Changwei Ge
2017-08-25 21:23 ` Andrew Morton
2017-08-26 1:23 ` Changwei Ge
2017-03-20 5:22 Stephen Rothwell
2017-03-20 9:05 ` Dmitry Vyukov
2017-03-20 12:30 ` Jan Glauber
2017-03-20 17:06 ` Challa, Mahipal
2015-01-27 8:12 Stephen Rothwell
2015-01-27 8:27 ` Vladimir Davydov
2015-01-27 8:27 ` Vladimir Davydov
2014-10-03 7:30 Stephen Rothwell
2014-10-03 18:21 ` Andrew Morton
2014-10-03 19:28 ` Michal Nazarewicz
2014-09-23 8:18 Stephen Rothwell
2013-08-29 9:47 Stephen Rothwell
2013-08-29 11:24 ` Maxim Patlasov
2013-08-29 11:24 ` Maxim Patlasov
2013-08-29 19:42 ` Andrew Morton
2013-08-29 19:42 ` Andrew Morton
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=53FC5F32.6060807@huawei.com \
--to=qiuxishi@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=tangchen@cn.fujitsu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.