Re: stable-rc build: 72 warnings 1 failures (stable-rc/v4.4.30-35-gf821e08)

Re: stable-rc build: 72 warnings 1 failures (stable-rc/v4.4.30-35-gf821e08)

[Arnd Bergmann]

On Tuesday, November 8, 2016 9:16:28 AM CET Olof's autobuilder wrote:
> Here are the build results from automated periodic testing.
> 
> The tree being built was stable-rc, found at:
> 
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/
> 
> Topmost commit:
> 
> f821e08 Linux 4.4.31-rc1
> 
> Build logs (stderr only) can be found at the following link (experimental):
> 
> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-35-gf821e08/

These seem to be largely caused by building with gcc-6. It's probably
a good idea to keep supporting that configuration though and
backport the fixes. Here are the upstream commit IDs I've found.

> -------------------------------------------------------------------------------
> 
> Failed defconfigs:
> 	powerpc.pasemi_defconfig
> 
> -------------------------------------------------------------------------------
> 
> Errors:
> 
> 	powerpc.pasemi_defconfig:
> /work/build/batch/arch/powerpc/kernel/ptrace.c:378:104: error: index 32 denotes an offset greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' [-Werror=array-bounds]
> /work/build/batch/arch/powerpc/kernel/ptrace.c:406:104: error: index 32 denotes an offset greater than size of 'u64[32][1] {aka long long unsigned int[32][1]}' [-Werror=array-bounds]

1e407ee3b21f ("powerpc/ptrace: Fix out of bounds array access warning")


> Warnings:
> 
>       1 drivers/block/floppy.c:1777:44: warning: self-comparison always evaluates to true [-Wtautological-compare]
>       1 drivers/block/floppy.c:1779:44: warning: self-comparison always evaluates to true [-Wtautological-compare]
>       1 drivers/block/floppy.c:4479:45: warning: self-comparison always evaluates to true [-Wtautological-compare]
>       1 drivers/block/floppy.c:4487:45: warning: self-comparison always evaluates to true [-Wtautological-compare]

dd665be0e243 ("ARM: 8584/1: floppy: avoid gcc-6 warning")

>       1 drivers/of/of_reserved_mem.c:131:180: warning: comparison of distinct pointer types lacks a cast
>       1 drivers/of/of_reserved_mem.c:131:182: warning: comparison of distinct pointer types lacks a cast
>       1 drivers/of/of_reserved_mem.c:131:364: warning: comparison of distinct pointer types lacks a cast
>       1 drivers/of/of_reserved_mem.c:131:368: warning: comparison of distinct pointer types lacks a cast

aaaab56dba9a ("of: silence warnings due to max() usage")

>       1 fs/devpts/inode.c:462:23: warning: self-comparison always evaluates to false [-Wtautological-compare]

I think this was accidentally fixed by eedf265aa003 ("devpts: Make each mount of
devpts an independent filesystem."), which unfortunately is not a candidate for stable

>       1 kernel/sched/core.c:2941:26: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]
>       1 kernel/sched/core.c:2943:27: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address]

A number of patches went in for this one, the last one was

ef6000b4c670 ("Disable the __builtin_return_address() warning globally after all")


>       1 mm/cma.c:186:131: warning: comparison of distinct pointer types lacks a cast
>       1 mm/cma.c:269:193: warning: comparison of distinct pointer types lacks a cast
>       1 mm/cma.c:269:379: warning: comparison of distinct pointer types lacks a cast

badbda53e505 ("mm/cma: silence warnings due to max() usage")

>       1 net/netfilter/xt_owner.c:27:23: warning: self-comparison always evaluates to false [-Wtautological-compare]

Apparently also fixed as a side-effect of a larger patch:

9847371a84b0 ("netfilter: Allow xt_owner in any user namespace")

This one might be appropriate for a stable backport, Eric Biederman
would know for sure.

>       4 drivers/gpu/drm/exynos/exynos_drm_core.c:104:199: warning: self-comparison always evaluates to false [-Wtautological-compare]

55c4b906aa2a ("drm/exynos: fix error handling in exynos_drm_subdrv_open")

>       4 drivers/i2c/busses/i2c-imx.c:1007:10: warning: 'return' with a value, in function returning void

The same one showed up in linux-4.8.y-rc earlier today and is now gone, I assume
it was already fixed there.

>       9 kernel/cgroup.c:239:396: warning: array subscript is above array bounds [-Warray-bounds]

cfe02a8a973e ("cgroup: avoid false positive gcc-6 warning")

>      19 drivers/net/ethernet/smsc/smc91x.c:563:14: warning: self-comparison always evaluates to true [-Wtautological-compare]

e3ebd894f084 ("smc91x: avoid self-comparison warning")

>       1 include/uapi/linux/swab.h:14:33: warning: integer overflow in expression [-Woverflow]
>       5 kernel/audit.c:663:22: warning: self-comparison always evaluates to false [-Wtautological-compare]
>       6 kernel/taskstats.c:289:22: warning: self-comparison always evaluates to false [-Wtautological-compare]
>       4 drivers/connector/cn_proc.c:349:23: warning: self-comparison always evaluates to false [-Wtautological-compare]
>       2 fs/xfs/xfs_ioctl.c:1166:22: warning: self-comparison always evaluates to true [-Wtautological-compare]


No idea.

	Arnd

Re: stable-rc build: 72 warnings 1 failures (stable-rc/v4.4.30-35-gf821e08)

[Olof Johansson]

On Tue, Nov 8, 2016 at 2:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday, November 8, 2016 9:16:28 AM CET Olof's autobuilder wrote:
>> Here are the build results from automated periodic testing.
>>
>> The tree being built was stable-rc, found at:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/
>>
>> Topmost commit:
>>
>> f821e08 Linux 4.4.31-rc1
>>
>> Build logs (stderr only) can be found at the following link (experimental):
>>
>> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-35-gf821e08/
>
> These seem to be largely caused by building with gcc-6. It's probably
> a good idea to keep supporting that configuration though and
> backport the fixes. Here are the upstream commit IDs I've found.

That's a lot of noise. I'll move back to build with gcc 4.9.2 instead, for now.

It's not entirely reasonable to expect older releases to build with
new toolchains without warnings, and I'm not sure if it makes sense to
bring back those fixes to -stable (unless they fix real bugs, of
course).


-Olof

Re: stable-rc build: 72 warnings 1 failures (stable-rc/v4.4.30-35-gf821e08)

[Olof Johansson]

On Tue, Nov 8, 2016 at 2:17 PM, Olof Johansson <olof@lixom.net> wrote:
> On Tue, Nov 8, 2016 at 2:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Tuesday, November 8, 2016 9:16:28 AM CET Olof's autobuilder wrote:
>>> Here are the build results from automated periodic testing.
>>>
>>> The tree being built was stable-rc, found at:
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/
>>>
>>> Topmost commit:
>>>
>>> f821e08 Linux 4.4.31-rc1
>>>
>>> Build logs (stderr only) can be found at the following link (experimental):
>>>
>>> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-35-gf821e08/
>>
>> These seem to be largely caused by building with gcc-6. It's probably
>> a good idea to keep supporting that configuration though and
>> backport the fixes. Here are the upstream commit IDs I've found.
>
> That's a lot of noise. I'll move back to build with gcc 4.9.2 instead, for now.
>
> It's not entirely reasonable to expect older releases to build with
> new toolchains without warnings, and I'm not sure if it makes sense to
> bring back those fixes to -stable (unless they fix real bugs, of
> course).

A lot less noise with older gcc:

http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-44-gc5be865/


-Olof

Re: stable-rc build: 72 warnings 1 failures (stable-rc/v4.4.30-35-gf821e08)

[Arnd Bergmann]

On Tuesday, November 8, 2016 3:26:52 PM CET Olof Johansson wrote:
> On Tue, Nov 8, 2016 at 2:17 PM, Olof Johansson <olof@lixom.net> wrote:
> > On Tue, Nov 8, 2016 at 2:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Tuesday, November 8, 2016 9:16:28 AM CET Olof's autobuilder wrote:
> >>> Here are the build results from automated periodic testing.
> >>>
> >>> The tree being built was stable-rc, found at:
> >>>
> >>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/
> >>>
> >>> Topmost commit:
> >>>
> >>> f821e08 Linux 4.4.31-rc1
> >>>
> >>> Build logs (stderr only) can be found at the following link (experimental):
> >>>
> >>> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-35-gf821e08/
> >>
> >> These seem to be largely caused by building with gcc-6. It's probably
> >> a good idea to keep supporting that configuration though and
> >> backport the fixes. Here are the upstream commit IDs I've found.
> >
> > That's a lot of noise. I'll move back to build with gcc 4.9.2 instead, for now.
> >
> > It's not entirely reasonable to expect older releases to build with
> > new toolchains without warnings, and I'm not sure if it makes sense to
> > bring back those fixes to -stable (unless they fix real bugs, of
> > course).
> 
> A lot less noise with older gcc:
> 
> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-44-gc5be865/

Out of the ones I mentioned earlier, that leaves

aaaab56dba9a ("of: silence warnings due to max() usage")
badbda53e505 ("mm/cma: silence warnings due to max() usage")

but adds a couple of others:

| arch/powerpc/relocs_check.sh: line 46: ccache /usr/local/cross-4.9.2/bin/powerpc64-linux-objdump: No such file or directory
| arch/arm64/Makefile:25: LSE atomics not supported by binutils

These seem to be caused by an older binutils release in your cross-4.9.2 build

| In file included from /work/build/batch/drivers/isdn/hardware/eicon/message.c:30:0:
| /work/build/batch/drivers/isdn/hardware/eicon/message.c: In function 'mixer_notify_update':
| /work/build/batch/drivers/isdn/hardware/eicon/platform.h:333:18: warning: array subscript is above array bounds [-Warray-bounds]
|  *(__le16 *)addr = cpu_to_le16(v);

This looks like a false-positive bug caused by 4.9 that is no longer
present in newer compilers.

I assume this is the line

PUT_WORD(&(((CAPI_MSG *) msg)->info.facility_req.structs[1]), LI_REQ_SILENT_UPDATE);

	Arnd

Re: stable-rc build: 72 warnings 1 failures (stable-rc/v4.4.30-35-gf821e08)

[Eric W. Biederman]

Arnd Bergmann <arnd@arndb.de> writes:

> On Tuesday, November 8, 2016 9:16:28 AM CET Olof's autobuilder wrote:
>> Here are the build results from automated periodic testing.
>> 
>> The tree being built was stable-rc, found at:
>> 
>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/
>> 
>> Topmost commit:
>> 
>> f821e08 Linux 4.4.31-rc1
>> 
>> Build logs (stderr only) can be found at the following link (experimental):
>> 
>> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-35-gf821e08/
>
> These seem to be largely caused by building with gcc-6. It's probably
> a good idea to keep supporting that configuration though and
> backport the fixes. Here are the upstream commit IDs I've found.
>
>> -------------------------------------------------------------------------------
>> 
>> Failed defconfigs:
>> 	powerpc.pasemi_defconfig
>> 
>> -------------------------------------------------------------------------------
>> 
>
>>       1 fs/devpts/inode.c:462:23: warning: self-comparison always evaluates to false [-Wtautological-compare]
>
> I think this was accidentally fixed by eedf265aa003 ("devpts: Make each mount of
> devpts an independent filesystem."), which unfortunately is not a
> candidate for stable

Well eedf265aa003 ("devpts: Make each mount of devpts an independent
filesystem.") does contain a somewhat serious bug fix, and it was tested
to ensure it works everywhere so that might possibly be a canidate for
stable.

Certainly that is a change I would aim at vendor trees that care about
containers.

>>       1 net/netfilter/xt_owner.c:27:23: warning: self-comparison always evaluates to false [-Wtautological-compare]
>
> Apparently also fixed as a side-effect of a larger patch:
>
> 9847371a84b0 ("netfilter: Allow xt_owner in any user namespace")
>
> This one might be appropriate for a stable backport, Eric Biederman
> would know for sure.

Well it is a feature patch.  This sounds like an error message that is
only generated when user namespace support is disabled.  And we are
making it go away by making the code more expensive.

I am not a great fan of that warning being on by default, as it seems to
encourage more expensive code to be generated by macros.   Has that
warning caught any real bugs yet?

Eric

Re: stable-rc build: 72 warnings 1 failures (stable-rc/v4.4.30-35-gf821e08)

[Greg KH]

On Tue, Nov 08, 2016 at 02:17:41PM -0800, Olof Johansson wrote:
> On Tue, Nov 8, 2016 at 2:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday, November 8, 2016 9:16:28 AM CET Olof's autobuilder wrote:
> >> Here are the build results from automated periodic testing.
> >>
> >> The tree being built was stable-rc, found at:
> >>
> >> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/
> >>
> >> Topmost commit:
> >>
> >> f821e08 Linux 4.4.31-rc1
> >>
> >> Build logs (stderr only) can be found at the following link (experimental):
> >>
> >> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-35-gf821e08/
> >
> > These seem to be largely caused by building with gcc-6. It's probably
> > a good idea to keep supporting that configuration though and
> > backport the fixes. Here are the upstream commit IDs I've found.
> 
> That's a lot of noise. I'll move back to build with gcc 4.9.2 instead, for now.
> 
> It's not entirely reasonable to expect older releases to build with
> new toolchains without warnings, and I'm not sure if it makes sense to
> bring back those fixes to -stable (unless they fix real bugs, of
> course).

My test-builder system is using gcc-6, and I do keep track of warnings
as it is a good indication that an applied patch is wrong (found a bug
in an i2c patch just yesterday because of it.)

I'm currently seeing only 3 warnings on x86 for 4.4-stable and gcc-6,
and just found the fix for one of them, so I'll gladly take warning
fixes that resolve issues to make it easier for the real problems to
jump out at us.

thanks,

greg k-h

Re: stable-rc build: 72 warnings 1 failures (stable-rc/v4.4.30-35-gf821e08)

[Greg KH]

On Wed, Nov 09, 2016 at 10:44:47AM +0100, Greg KH wrote:
> On Tue, Nov 08, 2016 at 02:17:41PM -0800, Olof Johansson wrote:
> > On Tue, Nov 8, 2016 at 2:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Tuesday, November 8, 2016 9:16:28 AM CET Olof's autobuilder wrote:
> > >> Here are the build results from automated periodic testing.
> > >>
> > >> The tree being built was stable-rc, found at:
> > >>
> > >> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/
> > >>
> > >> Topmost commit:
> > >>
> > >> f821e08 Linux 4.4.31-rc1
> > >>
> > >> Build logs (stderr only) can be found at the following link (experimental):
> > >>
> > >> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-35-gf821e08/
> > >
> > > These seem to be largely caused by building with gcc-6. It's probably
> > > a good idea to keep supporting that configuration though and
> > > backport the fixes. Here are the upstream commit IDs I've found.
> > 
> > That's a lot of noise. I'll move back to build with gcc 4.9.2 instead, for now.
> > 
> > It's not entirely reasonable to expect older releases to build with
> > new toolchains without warnings, and I'm not sure if it makes sense to
> > bring back those fixes to -stable (unless they fix real bugs, of
> > course).
> 
> My test-builder system is using gcc-6, and I do keep track of warnings
> as it is a good indication that an applied patch is wrong (found a bug
> in an i2c patch just yesterday because of it.)
> 
> I'm currently seeing only 3 warnings on x86 for 4.4-stable and gcc-6,
> and just found the fix for one of them, so I'll gladly take warning
> fixes that resolve issues to make it easier for the real problems to
> jump out at us.

And now I'm down to 0 warnings thanks to Arnd's hints in this thread and
some more digging.  If there's anything else I should add to 4.4 to make
it "quieter", please let me know.

thanks,

greg k-h

Re: stable-rc build: 72 warnings 1 failures (stable-rc/v4.4.30-35-gf821e08)

[Arnd Bergmann]

On Tuesday, November 8, 2016 6:45:53 PM CET Eric W. Biederman wrote:
> Arnd Bergmann <arnd@arndb.de> writes:

> > On Tuesday, November 8, 2016 9:16:28 AM CET Olof's autobuilder wrote:
> >> Here are the build results from automated periodic testing.
> > I think this was accidentally fixed by eedf265aa003 ("devpts: Make each mount of
> > devpts an independent filesystem."), which unfortunately is not a
> > candidate for stable
> 
> Well eedf265aa003 ("devpts: Make each mount of devpts an independent
> filesystem.") does contain a somewhat serious bug fix, and it was tested
> to ensure it works everywhere so that might possibly be a canidate for
> stable.
> 
> Certainly that is a change I would aim at vendor trees that care about
> containers.
> 
> >>       1 net/netfilter/xt_owner.c:27:23: warning: self-comparison always evaluates to false [-Wtautological-compare]
> >
> > Apparently also fixed as a side-effect of a larger patch:
> >
> > 9847371a84b0 ("netfilter: Allow xt_owner in any user namespace")
> >
> > This one might be appropriate for a stable backport, Eric Biederman
> > would know for sure.
> 
> Well it is a feature patch.  This sounds like an error message that is
> only generated when user namespace support is disabled.  And we are
> making it go away by making the code more expensive.

Ah, so both of these were exactly the opposite of what I expected ;-)

> I am not a great fan of that warning being on by default, as it seems to
> encourage more expensive code to be generated by macros.   Has that
> warning caught any real bugs yet?

I fixed up all instanced I could find on ARM, see "git log --oneline
--grep=tautological". I'd categorize three of them as bugs:

0a938697d7fb drm/exynos: fix error handling in exynos_drm_subdrv_open
0fb504001192 [media] am437x-vfpe: fix typo in vpfe_get_app_input_index
86d65b7e7a0c nouveau: fix nv40_perfctr_next() cleanup regression

and four others as false-positive:

dd665be0e243 ARM: 8584/1: floppy: avoid gcc-6 warning
f419a08fb329 drivers/memstick/host/r592.c: avoid gcc-6 warning
e3ebd894f084 smc91x: avoid self-comparison warning
0335695dfa4d cred/userns: define current_user_ns() as a function

which is not a bad ratio at all. The last of those is probably
sufficient to address most of the gcc-6 warnings on stable-4.4.

I also did a patch to shut up four more warnings on x86, but never
got around to submitting them properly. These are all false-positive,
see patch below (I folded this into one).

	Arnd

commit 28624e5166a2d33c386b6d5b7f627d84939cabce
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Oct 7 14:15:06 2016 +0200

    x86: treewide: hide -Wtautological-compare warnings
    
    proc/kcore: hide a harmless warning
    
    fs/proc/kcore.c: In function ‘add_modules_range’:
    fs/proc/kcore.c:622:161: error: self-comparison always evaluates to false [-Werror=tautological-compare]
      if (/*MODULES_VADDR != VMALLOC_START && */MODULES_END != VMALLOC_END) {
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    
    acpi: thermal: fix gcc-6/ccache warning
    
    drivers/acpi/processor_thermal.c: In function ‘cpufreq_set_cur_state’:
    drivers/acpi/processor_thermal.c:137:36: error: self-comparison always evaluates to true [-Werror=tautological-compare]
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    
    x86: microcode/amd: avoid ccache/gcc-6 warning
    
    /git/arm-soc/arch/x86/kernel/cpu/microcode/amd.c: In function ‘load_microcode_amd’:
    /git/arm-soc/arch/x86/kernel/cpu/microcode/amd.c:878:30: error: self-comparison always evaluates to true [-Werror=tautological-compare]
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    
    sfi: avoid ccache warning
    
    With ccache in combination with gcc-6, we get a harmless warning for the sfi subsystem,
    as ccache only sees the preprocessed source:
    
    drivers/sfi/sfi_core.c: In function ‘sfi_map_table’:
    drivers/sfi/sfi_core.c:175:53: error: self-comparison always evaluates to true [-Werror=tautological-compare]
    
    Using an inline function to do the comparison tells the compiler what is
    going on even for preprocessed files, and avoids the warning.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c
index 6f353bdb3a25..64a457da4a4c 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -854,6 +854,7 @@ static enum ucode_state
 load_microcode_amd(int cpu, u8 family, const u8 *data, size_t size)
 {
 	enum ucode_state ret;
+	int bootcpu = boot_cpu_data.cpu_index;
 
 	/* free old equiv table */
 	free_equiv_cpu_table();
@@ -865,7 +866,7 @@ load_microcode_amd(int cpu, u8 family, const u8 *data, size_t size)
 
 #ifdef CONFIG_X86_32
 	/* save BSP's matching patch for early load */
-	if (cpu_data(cpu).cpu_index == boot_cpu_data.cpu_index) {
+	if (cpu_data(cpu).cpu_index == bootcpu) {
 		struct ucode_patch *p = find_patch(cpu);
 		if (p) {
 			memset(amd_ucode_patch, 0, PATCH_MAX_SIZE);
diff --git a/drivers/acpi/processor_thermal.c b/drivers/acpi/processor_thermal.c
index 1fed84a092c2..8cde6715537b 100644
--- a/drivers/acpi/processor_thermal.c
+++ b/drivers/acpi/processor_thermal.c
@@ -122,20 +122,22 @@ static int cpufreq_get_cur_state(unsigned int cpu)
 static int cpufreq_set_cur_state(unsigned int cpu, int state)
 {
 	int i;
+	int id;
 
 	if (!cpu_has_cpufreq(cpu))
 		return 0;
 
 	reduction_pctg(cpu) = state;
 
+	id = topology_physical_package_id(cpu);
+
 	/*
 	 * Update all the CPUs in the same package because they all
 	 * contribute to the temperature and often share the same
 	 * frequency.
 	 */
 	for_each_online_cpu(i) {
-		if (topology_physical_package_id(i) ==
-		    topology_physical_package_id(cpu))
+		if (topology_physical_package_id(i) == id)
 			cpufreq_update_policy(i);
 	}
 	return 0;
diff --git a/drivers/sfi/sfi_core.c b/drivers/sfi/sfi_core.c
index 296db7a69c27..a8f2313a2613 100644
--- a/drivers/sfi/sfi_core.c
+++ b/drivers/sfi/sfi_core.c
@@ -71,9 +71,12 @@
 
 #include "sfi_core.h"
 
-#define ON_SAME_PAGE(addr1, addr2) \
-	(((unsigned long)(addr1) & PAGE_MASK) == \
-	((unsigned long)(addr2) & PAGE_MASK))
+static inline bool on_same_page(unsigned long addr1, unsigned long addr2)
+{
+	return (addr1 & PAGE_MASK) == (addr2 & PAGE_MASK);
+}
+
+#define ON_SAME_PAGE(addr1, addr2) on_same_page((unsigned long)addr1, (unsigned long)addr2)
 #define TABLE_ON_PAGE(page, table, size) (ON_SAME_PAGE(page, table) && \
 				ON_SAME_PAGE(page, table + size))
 
diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 5c89a07e3d7f..8ca8de0d13eb 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -616,12 +616,14 @@ static void __init proc_kcore_text_init(void)
 /*
  * MODULES_VADDR has no intersection with VMALLOC_ADDR.
  */
-struct kcore_list kcore_modules;
+static struct kcore_list kcore_modules;
 static void __init add_modules_range(void)
 {
-	if (MODULES_VADDR != VMALLOC_START && MODULES_END != VMALLOC_END) {
-		kclist_add(&kcore_modules, (void *)MODULES_VADDR,
-			MODULES_END - MODULES_VADDR, KCORE_VMALLOC);
+	void *start = (void *)MODULES_VADDR;
+	size_t len = MODULES_END - MODULES_VADDR;
+
+	if (start != (void *)VMALLOC_START && len != VMALLOC_END - VMALLOC_START) {
+		kclist_add(&kcore_modules, start, len, KCORE_VMALLOC);
 	}
 }
 #else