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/
Runtime: 60m 17s
Passed: 121 Failed: 1
Warnings: 72
Section mismatches: 0
-------------------------------------------------------------------------------
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]
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] 1 drivers/block/floppy.c:810:44: warning: self-comparison always evaluates to true [-Wtautological-compare] 1 drivers/block/floppy.c:825:43: warning: self-comparison always evaluates to true [-Wtautological-compare] 1 drivers/block/floppy.c:826:43: warning: self-comparison always evaluates to true [-Wtautological-compare] 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 1 fs/devpts/inode.c:462:23: warning: self-comparison always evaluates to false [-Wtautological-compare] 1 include/uapi/linux/swab.h:14:33: warning: integer overflow in expression [-Woverflow] 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] 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 1 net/netfilter/xt_owner.c:27: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] 4 drivers/connector/cn_proc.c:349:23: warning: self-comparison always evaluates to false [-Wtautological-compare] 4 drivers/gpu/drm/exynos/exynos_drm_core.c:104:199: warning: self-comparison always evaluates to false [-Wtautological-compare] 4 drivers/i2c/busses/i2c-imx.c:1007:10: warning: 'return' with a value, in function returning void 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] 9 kernel/cgroup.c:239:396: warning: array subscript is above array bounds [-Warray-bounds] 19 drivers/net/ethernet/smsc/smc91x.c:563:14: warning: self-comparison always evaluates to true [-Wtautological-compare]
No new syscalls
No section mismatches
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
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
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
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
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
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
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
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
kernel-build-reports@lists.linaro.org
-
Arnd Bergmann -
ebiederm＠xmission.com -
Greg KH -
Olof Johansson -
Olof's autobuilder