Tree/Branch: v4.7.5 Git describe: v4.7.5 Commit: 6c21842b5f Linux 4.7.5
Build Time: 71 min 4 sec
Passed: 9 / 9 (100.00 %) Failed: 0 / 9 ( 0.00 %)
Errors: 0 Warnings: 2 Section Mismatches: 0
------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 2 warnings 0 mismatches : arm64-allmodconfig 1 warnings 0 mismatches : x86_64-defconfig 1 warnings 0 mismatches : arm-multi_v7_defconfig 1 warnings 0 mismatches : arm-allmodconfig 1 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 2 5 ../fs/nfs/nfs4session.c:201:54: warning: 'cur_seq' may be used uninitialized in this function [-Wmaybe-uninitialized] 1 ../fs/reiserfs/ibalance.c:1156:2: warning: 'new_insert_key' may be used uninitialized in this function [-Wmaybe-uninitialized]
=============================================================================== Detailed per-defconfig build reports below:
------------------------------------------------------------------------------- arm64-allmodconfig : PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings: ../fs/nfs/nfs4session.c:201:54: warning: 'cur_seq' may be used uninitialized in this function [-Wmaybe-uninitialized] ../fs/reiserfs/ibalance.c:1156:2: warning: 'new_insert_key' may be used uninitialized in this function [-Wmaybe-uninitialized]
------------------------------------------------------------------------------- x86_64-defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings: ../fs/nfs/nfs4session.c:201:54: warning: 'cur_seq' may be used uninitialized in this function [-Wmaybe-uninitialized]
------------------------------------------------------------------------------- arm-multi_v7_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings: ../fs/nfs/nfs4session.c:201:54: warning: 'cur_seq' may be used uninitialized in this function [-Wmaybe-uninitialized]
------------------------------------------------------------------------------- arm-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings: ../fs/nfs/nfs4session.c:201:54: warning: 'cur_seq' may be used uninitialized in this function [-Wmaybe-uninitialized]
------------------------------------------------------------------------------- arm64-defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings: ../fs/nfs/nfs4session.c:201:54: warning: 'cur_seq' may be used uninitialized in this function [-Wmaybe-uninitialized] -------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
x86_64-allnoconfig arm64-allnoconfig arm-allnoconfig arm-multi_v5_defconfig
On Saturday, September 24, 2016 2:44:46 PM CEST Build bot for Mark Brown wrote:
Warnings Summary: 2 5 ../fs/nfs/nfs4session.c:201:54: warning: 'cur_seq' may be used uninitialized in this function [-Wmaybe-uninitialized]
This is a false positive warning that was introduced by
Fixes: 11d01071d730 ("NFSv4.1: Fix Oopsable condition in server callback races")
I submitted a patch at https://patchwork.kernel.org/patch/9307119/ which still seems like the best workaround to me, but as the warning is disabled in v4.8, the patch was never applied upstream.
1 ../fs/reiserfs/ibalance.c:1156:2: warning: 'new_insert_key' may be used uninitialized in this function [-Wmaybe-uninitialized]
This one was the last warning reported by Mark's autobuilder in v4.7, the following patch for it went into v4.8:
Fixes: 0a11b9aae49a ("reiserfs: fix "new_insert_key may be used uninitialized ..."")
Arnd
On Sat, Sep 24, 2016 at 10:57:27PM +0200, Arnd Bergmann wrote:
On Saturday, September 24, 2016 2:44:46 PM CEST Build bot for Mark Brown wrote:
Warnings Summary: 2 5 ../fs/nfs/nfs4session.c:201:54: warning: 'cur_seq' may be used uninitialized in this function [-Wmaybe-uninitialized]
This is a false positive warning that was introduced by
Fixes: 11d01071d730 ("NFSv4.1: Fix Oopsable condition in server callback races")
I submitted a patch at https://patchwork.kernel.org/patch/9307119/ which still seems like the best workaround to me, but as the warning is disabled in v4.8, the patch was never applied upstream.
Sad :(
1 ../fs/reiserfs/ibalance.c:1156:2: warning: 'new_insert_key' may be used uninitialized in this function [-Wmaybe-uninitialized]
This one was the last warning reported by Mark's autobuilder in v4.7, the following patch for it went into v4.8:
Fixes: 0a11b9aae49a ("reiserfs: fix "new_insert_key may be used uninitialized ..."")
Thanks, now queued this one up as well.
greg k-h
Hi Arnd,
I'm getting the following build warnings on the 4.7-stable tree, any ideas what they are from:
In file included from ../kernel/trace/trace_irqsoff.c:15:0: ../kernel/trace/trace_irqsoff.c: In function ‘stop_critical_timings’: ../include/linux/ftrace.h:703:36: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe [-Wframe-address] # define ftrace_return_address(n) __builtin_return_address(n) ^~~~~~~~~~~~~~~~~~~~~~~~~~~ ../include/linux/ftrace.h:710:38: note: in expansion of macro ‘ftrace_return_address’ #define CALLER_ADDR1 ((unsigned long)ftrace_return_address(1)) ^~~~~~~~~~~~~~~~~~~~~ ../kernel/trace/trace_irqsoff.c:433:38: note: in expansion of macro ‘CALLER_ADDR1’ stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1); ^~~~~~~~~~~~
It shows up in a few other places as well with this signature.
Same goes for the 4.4-stable tree
thanks,
greg k-h
On Sunday 25 September 2016, Greg KH wrote:
Hi Arnd,
I'm getting the following build warnings on the 4.7-stable tree, any ideas what they are from:
In file included from ../kernel/trace/trace_irqsoff.c:15:0: ../kernel/trace/trace_irqsoff.c: In function ‘stop_critical_timings’: ../include/linux/ftrace.h:703:36: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe [-Wframe-address] # define ftrace_return_address(n) __builtin_return_address(n) ^~~~~~~~~~~~~~~~~~~~~~~~~~~ ../include/linux/ftrace.h:710:38: note: in expansion of macro ‘ftrace_return_address’ #define CALLER_ADDR1 ((unsigned long)ftrace_return_address(1)) ^~~~~~~~~~~~~~~~~~~~~ ../kernel/trace/trace_irqsoff.c:433:38: note: in expansion of macro ‘CALLER_ADDR1’ stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1); ^~~~~~~~~~~~
It shows up in a few other places as well with this signature.
Same goes for the 4.4-stable tree
In mainline, this warning got disabled with 124a3d88fa20 ("Disable "frame-address" warning") and then later that change was partially reverted wtih 377ccbb48373 ("Makefile: Mute warning for __builtin_return_address(>0) for tracing only").
It's probably fine if you apply both to the stable kernel.
I think I never saw this particular warning in my ARM build tests.
Arnd
On Mon, Sep 26, 2016 at 01:46:51AM +0200, Arnd Bergmann wrote:
On Sunday 25 September 2016, Greg KH wrote:
Hi Arnd,
I'm getting the following build warnings on the 4.7-stable tree, any ideas what they are from:
In file included from ../kernel/trace/trace_irqsoff.c:15:0: ../kernel/trace/trace_irqsoff.c: In function ‘stop_critical_timings’: ../include/linux/ftrace.h:703:36: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe [-Wframe-address] # define ftrace_return_address(n) __builtin_return_address(n) ^~~~~~~~~~~~~~~~~~~~~~~~~~~ ../include/linux/ftrace.h:710:38: note: in expansion of macro ‘ftrace_return_address’ #define CALLER_ADDR1 ((unsigned long)ftrace_return_address(1)) ^~~~~~~~~~~~~~~~~~~~~ ../kernel/trace/trace_irqsoff.c:433:38: note: in expansion of macro ‘CALLER_ADDR1’ stop_critical_timing(CALLER_ADDR0, CALLER_ADDR1); ^~~~~~~~~~~~
It shows up in a few other places as well with this signature.
Same goes for the 4.4-stable tree
In mainline, this warning got disabled with 124a3d88fa20 ("Disable "frame-address" warning") and then later that change was partially reverted wtih 377ccbb48373 ("Makefile: Mute warning for __builtin_return_address(>0) for tracing only").
It's probably fine if you apply both to the stable kernel.
Thanks, that's better, but the warning still triggers on kernel/sched/core.c for me, as the last patch only disables it for the tracing directory.
But it's a few less warning messages, now on to fix up the rest...
thanks,
greg k-h
kernel-build-reports@lists.linaro.org