From: Changbin Du <[email protected]>
Hi all,
I know some kernel developers was searching for a method to dissable GCC
optimizations, probably they want to apply GCC '-O0' option. But since Linux
kernel replys on GCC optimization to remove some dead code, so '-O0' just
breaks the build. They do need this because they want to debug kernel with
qemu, simics, kgtp or kgdb.
Thanks for the GCC '-Og' optimization level introduced in GCC 4.8, which
offers a reasonable level of optimization while maintaining fast compilation
and a good debugging experience. It is similar to '-O1' while perferring to
keep debug ability over runtime speed. With '-Og', we can build a kernel with
better debug ability and little performance drop after some simple change.
In this series, firstly introduce a new config CONFIG_NO_AUTO_INLINE after two
fixes for this new option. With this option, only functions explicitly marked
with "inline" will be inlined. This will allow the function tracer to trace
more functions because it only traces functions that the compiler has not
inlined.
Then introduce new config CC_OPTIMIZE_FOR_DEBUGGING which apply '-Og'
optimization level for whole kernel, with a simple fix in fix_to_virt().
Currently I have only tested this option on x86 and ARM platform. Other
platforms should also work but probably need some compiling fixes as what
having done in this series. I leave that to who want to try this debug
option.
Comparison of vmlinux size: a bit smaller.
w/o CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ size vmlinux
text data bss dec hex filename
22665554 9709674 2920908 35296136 21a9388 vmlinux
w/ CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ size vmlinux
text data bss dec hex filename
21499032 10102758 2920908 34522698 20ec64a vmlinux
Comparison of system performance: a bit drop (~6%).
This benchmark of kernel compilation is suggested by Ingo Molnar.
https://lkml.org/lkml/2018/5/2/74
Preparation: Set cpufreq to 'performance'.
for ((cpu=0; cpu<120; cpu++)); do
G=/sys/devices/system/cpu/cpu$cpu/cpufreq/scaling_governor
[ -f $G ] && echo performance > $G
done
w/o CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *; \
git checkout .; \
echo 1 > /proc/sys/vm/drop_caches; \
find ../kernel* -type f | xargs cat >/dev/null; \
make -j kernel >/dev/null; \
make clean >/dev/null 2>&1; \
sync '\
\
make -j8 >/dev/null
Performance counter stats for 'make -j8' (5 runs):
219.764246652 seconds time elapsed ( +- 0.78% )
w/ CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *; \
git checkout .; \
echo 1 > /proc/sys/vm/drop_caches; \
find ../kernel* -type f | xargs cat >/dev/null; \
make -j kernel >/dev/null; \
make clean >/dev/null 2>&1; \
sync '\
\
make -j8 >/dev/null
Performance counter stats for 'make -j8' (5 runs):
233.574187771 seconds time elapsed ( +- 0.19% )
v5:
o Exchange the position of last two patches to avoid compiling error.
v4:
o Remove aready merged one "regulator: add dummy function of_find_regulator_by_node".
Changbin Du (4):
x86/mm: surround level4_kernel_pgt with #ifdef
CONFIG_X86_5LEVEL...#endif
kernel hacking: new config NO_AUTO_INLINE to disable compiler
auto-inline optimizations
ARM: mm: fix build error in fix_to_virt with
CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
kernel hacking: new config CC_OPTIMIZE_FOR_DEBUGGING to apply GCC -Og
optimization
Makefile | 10 ++++++++++
arch/arm/mm/mmu.c | 2 +-
arch/x86/include/asm/pgtable_64.h | 2 ++
arch/x86/kernel/head64.c | 13 ++++++-------
include/linux/compiler-gcc.h | 2 +-
include/linux/compiler.h | 2 +-
init/Kconfig | 19 +++++++++++++++++++
lib/Kconfig.debug | 17 +++++++++++++++++
8 files changed, 57 insertions(+), 10 deletions(-)
--
2.7.4
From: Changbin Du <[email protected]>
This will apply GCC '-Og' optimization level which is supported
since GCC 4.8. This optimization level offers a reasonable level
of optimization while maintaining fast compilation and a good
debugging experience. It is similar to '-O1' while perferring
to keep debug ability over runtime speed.
If enabling this option breaks your kernel, you should either
disable this or find a fix (mostly in the arch code). Currently
this option has only been tested on x86_64 and arm platform.
This option can satisfy people who was searching for a method
to disable compiler optimizations so to achieve better kernel
debugging experience with kgdb or qemu.
The main problem of '-Og' is we must not use __attribute__((error(msg))).
The compiler will report error though the call to error function
still can be optimize out. So we must fallback to array tricky.
Comparison of vmlinux size: a bit smaller.
w/o CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ size vmlinux
text data bss dec hex filename
22665554 9709674 2920908 35296136 21a9388 vmlinux
w/ CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ size vmlinux
text data bss dec hex filename
21499032 10102758 2920908 34522698 20ec64a vmlinux
Comparison of system performance: a bit drop (~6%).
This benchmark of kernel compilation is suggested by Ingo Molnar.
https://lkml.org/lkml/2018/5/2/74
Preparation: Set cpufreq to 'performance'.
for ((cpu=0; cpu<120; cpu++)); do
G=/sys/devices/system/cpu/cpu$cpu/cpufreq/scaling_governor
[ -f $G ] && echo performance > $G
done
w/o CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *; \
git checkout .; \
echo 1 > /proc/sys/vm/drop_caches; \
find ../kernel* -type f | xargs cat >/dev/null; \
make -j kernel >/dev/null; \
make clean >/dev/null 2>&1; \
sync '\
\
make -j8 >/dev/null
Performance counter stats for 'make -j8' (5 runs):
219.764246652 seconds time elapsed ( +- 0.78% )
w/ CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *; \
git checkout .; \
echo 1 > /proc/sys/vm/drop_caches; \
find ../kernel* -type f | xargs cat >/dev/null; \
make -j kernel >/dev/null; \
make clean >/dev/null 2>&1; \
sync '\
\
make -j8 >/dev/null
Performance counter stats for 'make -j8' (5 runs):
233.574187771 seconds time elapsed ( +- 0.19% )
Signed-off-by: Changbin Du <[email protected]>
Acked-by: Steven Rostedt (VMware) <[email protected]>
---
v3:
o Rename DEBUG_EXPERIENCE to CC_OPTIMIZE_FOR_DEBUGGING
o Move new configuration item to "General setup->Compiler optimization level"
v2:
o Improve performance benchmark as suggested by Ingo.
o Grammar updates in description. (Randy Dunlap)
---
Makefile | 4 ++++
include/linux/compiler-gcc.h | 2 +-
include/linux/compiler.h | 2 +-
init/Kconfig | 19 +++++++++++++++++++
4 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 6720c40..977418a 100644
--- a/Makefile
+++ b/Makefile
@@ -639,6 +639,9 @@ KBUILD_CFLAGS += $(call cc-disable-warning, format-truncation)
KBUILD_CFLAGS += $(call cc-disable-warning, format-overflow)
KBUILD_CFLAGS += $(call cc-disable-warning, int-in-bool-context)
+ifdef CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
+KBUILD_CFLAGS += $(call cc-option, -Og)
+else
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_CFLAGS += $(call cc-option,-Oz,-Os)
KBUILD_CFLAGS += $(call cc-disable-warning,maybe-uninitialized,)
@@ -649,6 +652,7 @@ else
KBUILD_CFLAGS += -O2
endif
endif
+endif
KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0409, \
$(call cc-disable-warning,maybe-uninitialized,))
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index b4bf73f..586ed11 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -192,7 +192,7 @@
#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
-#ifndef __CHECKER__
+#if !defined(__CHECKER__) && !defined(CONFIG_CC_OPTIMIZE_FOR_DEBUGGING)
# define __compiletime_warning(message) __attribute__((warning(message)))
# define __compiletime_error(message) __attribute__((error(message)))
#endif /* __CHECKER__ */
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index ab4711c..e97caf4 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -301,7 +301,7 @@ unsigned long read_word_at_a_time(const void *addr)
* sparse see a constant array size without breaking compiletime_assert on old
* versions of GCC (e.g. 4.2.4), so hide the array from sparse altogether.
*/
-# ifndef __CHECKER__
+# if !defined(__CHECKER__) && !defined(CONFIG_CC_OPTIMIZE_FOR_DEBUGGING)
# define __compiletime_error_fallback(condition) \
do { ((void)sizeof(char[1 - 2 * condition])); } while (0)
# endif
diff --git a/init/Kconfig b/init/Kconfig
index f013afc..aa52535 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1036,6 +1036,25 @@ config CC_OPTIMIZE_FOR_SIZE
If unsure, say N.
+config CC_OPTIMIZE_FOR_DEBUGGING
+ bool "Optimize for better debugging experience (-Og)"
+ select NO_AUTO_INLINE
+ help
+ This will apply GCC '-Og' optimization level which is supported
+ since GCC 4.8. This optimization level offers a reasonable level
+ of optimization while maintaining fast compilation and a good
+ debugging experience. It is similar to '-O1' while preferring to
+ keep debug ability over runtime speed. The overall performance
+ will drop a bit (~6%).
+
+ Use only if you want to debug the kernel, especially if you want
+ to have better kernel debugging experience with gdb facilities
+ like kgdb or qemu. If enabling this option breaks your kernel,
+ you should either disable this or find a fix (mostly in the arch
+ code).
+
+ If unsure, select N.
+
endchoice
config SYSCTL
--
2.7.4
From: Changbin Du <[email protected]>
With '-Og' optimization level, GCC would not optimize a count for a loop
as a constant value. But BUILD_BUG_ON() only accept compile-time constant
values. Let's use __fix_to_virt() to avoid the error.
arch/arm/mm/mmu.o: In function `fix_to_virt':
/home/changbin/work/linux/./include/asm-generic/fixmap.h:31: undefined reference to `__compiletime_assert_31'
Makefile:1051: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1
Signed-off-by: Changbin Du <[email protected]>
Acked-by: Steven Rostedt (VMware) <[email protected]>
---
v2: use __fix_to_virt() to fix the issue.
---
arch/arm/mm/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index e46a6a4..c08d74e 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1599,7 +1599,7 @@ static void __init early_fixmap_shutdown(void)
pte_t *pte;
struct map_desc map;
- map.virtual = fix_to_virt(i);
+ map.virtual = __fix_to_virt(i);
pte = pte_offset_early_fixmap(pmd_off_k(map.virtual), map.virtual);
/* Only i/o device mappings are supported ATM */
--
2.7.4
From: Changbin Du <[email protected]>
The level4_kernel_pgt is only defined when X86_5LEVEL is enabled. So
surround level4_kernel_pgt with #ifdef CONFIG_X86_5LEVEL...#endif to
make code correct.
Signed-off-by: Changbin Du <[email protected]>
Acked-by: Steven Rostedt (VMware) <[email protected]>
---
arch/x86/include/asm/pgtable_64.h | 2 ++
arch/x86/kernel/head64.c | 13 ++++++-------
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/pgtable_64.h b/arch/x86/include/asm/pgtable_64.h
index 877bc27..9e7f667 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -15,7 +15,9 @@
#include <linux/bitops.h>
#include <linux/threads.h>
+#ifdef CONFIG_X86_5LEVEL
extern p4d_t level4_kernel_pgt[512];
+#endif
extern p4d_t level4_ident_pgt[512];
extern pud_t level3_kernel_pgt[512];
extern pud_t level3_ident_pgt[512];
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 0c408f8..775d7a6 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -143,16 +143,15 @@ unsigned long __head __startup_64(unsigned long physaddr,
pgd = fixup_pointer(&early_top_pgt, physaddr);
p = pgd + pgd_index(__START_KERNEL_map);
- if (la57)
- *p = (unsigned long)level4_kernel_pgt;
- else
- *p = (unsigned long)level3_kernel_pgt;
- *p += _PAGE_TABLE_NOENC - __START_KERNEL_map + load_delta;
-
+#ifdef CONFIG_X86_5LEVEL
if (la57) {
+ *p = (unsigned long)level4_kernel_pgt;
p4d = fixup_pointer(&level4_kernel_pgt, physaddr);
p4d[511] += load_delta;
- }
+ } else
+#endif
+ *p = (unsigned long)level3_kernel_pgt;
+ *p += _PAGE_TABLE_NOENC - __START_KERNEL_map + load_delta;
pud = fixup_pointer(&level3_kernel_pgt, physaddr);
pud[510] += load_delta;
--
2.7.4
From: Changbin Du <[email protected]>
This patch add a new kernel hacking option NO_AUTO_INLINE. Selecting
this option will prevent the compiler from optimizing the kernel by
auto-inlining functions not marked with the inline keyword.
With this option, only functions explicitly marked with "inline" will
be inlined. This will allow the function tracer to trace more functions
because it only traces functions that the compiler has not inlined.
Signed-off-by: Changbin Du <[email protected]>
Acked-by: Steven Rostedt (VMware) <[email protected]>
---
v2: Some grammar updates from Steven.
---
Makefile | 6 ++++++
lib/Kconfig.debug | 17 +++++++++++++++++
2 files changed, 23 insertions(+)
diff --git a/Makefile b/Makefile
index d0d2652..6720c40 100644
--- a/Makefile
+++ b/Makefile
@@ -775,6 +775,12 @@ KBUILD_CFLAGS += $(call cc-option, -femit-struct-debug-baseonly) \
$(call cc-option,-fno-var-tracking)
endif
+ifdef CONFIG_NO_AUTO_INLINE
+KBUILD_CFLAGS += $(call cc-option, -fno-inline-functions) \
+ $(call cc-option, -fno-inline-small-functions) \
+ $(call cc-option, -fno-inline-functions-called-once)
+endif
+
ifdef CONFIG_FUNCTION_TRACER
ifndef CC_FLAGS_FTRACE
CC_FLAGS_FTRACE := -pg
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c40c7b7..da52243 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -198,6 +198,23 @@ config GDB_SCRIPTS
instance. See Documentation/dev-tools/gdb-kernel-debugging.rst
for further details.
+config NO_AUTO_INLINE
+ bool "Disable compiler auto-inline optimizations"
+ help
+ This will prevent the compiler from optimizing the kernel by
+ auto-inlining functions not marked with the inline keyword.
+ With this option, only functions explicitly marked with
+ "inline" will be inlined. This will allow the function tracer
+ to trace more functions because it only traces functions that
+ the compiler has not inlined.
+
+ Enabling this function can help debugging a kernel if using
+ the function tracer. But it can also change how the kernel
+ works, because inlining functions may change the timing,
+ which could make it difficult while debugging race conditions.
+
+ If unsure, select N.
+
config ENABLE_WARN_DEPRECATED
bool "Enable __deprecated logic"
default y
--
2.7.4
Hi Changbin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17 next-20180605]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 8.1.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64
All warnings (new ones prefixed by >>):
drivers//staging/greybus/fw-management.c: In function 'fw_mgmt_load_and_validate_operation':
>> drivers//staging/greybus/fw-management.c:153:2: warning: 'strncpy' specified bound 10 equals destination size [-Wstringop-truncation]
strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers//staging/greybus/fw-management.c: In function 'fw_mgmt_backend_fw_update_operation':
drivers//staging/greybus/fw-management.c:304:2: warning: 'strncpy' specified bound 10 equals destination size [-Wstringop-truncation]
strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
drivers/auxdisplay/panel.c: In function 'panel_bind_key':
>> drivers/auxdisplay/panel.c:1509:2: warning: 'strncpy' specified bound 12 equals destination size [-Wstringop-truncation]
strncpy(key->u.kbd.press_str, press, sizeof(key->u.kbd.press_str));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/auxdisplay/panel.c:1510:2: warning: 'strncpy' specified bound 12 equals destination size [-Wstringop-truncation]
strncpy(key->u.kbd.repeat_str, repeat, sizeof(key->u.kbd.repeat_str));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vim +/strncpy +153 drivers//staging/greybus/fw-management.c
013e6653 Viresh Kumar 2016-05-14 138
013e6653 Viresh Kumar 2016-05-14 139 static int fw_mgmt_load_and_validate_operation(struct fw_mgmt *fw_mgmt,
013e6653 Viresh Kumar 2016-05-14 140 u8 load_method, const char *tag)
013e6653 Viresh Kumar 2016-05-14 141 {
013e6653 Viresh Kumar 2016-05-14 142 struct gb_fw_mgmt_load_and_validate_fw_request request;
013e6653 Viresh Kumar 2016-05-14 143 int ret;
013e6653 Viresh Kumar 2016-05-14 144
013e6653 Viresh Kumar 2016-05-14 145 if (load_method != GB_FW_LOAD_METHOD_UNIPRO &&
013e6653 Viresh Kumar 2016-05-14 146 load_method != GB_FW_LOAD_METHOD_INTERNAL) {
013e6653 Viresh Kumar 2016-05-14 147 dev_err(fw_mgmt->parent,
013e6653 Viresh Kumar 2016-05-14 148 "invalid load-method (%d)\n", load_method);
013e6653 Viresh Kumar 2016-05-14 149 return -EINVAL;
013e6653 Viresh Kumar 2016-05-14 150 }
013e6653 Viresh Kumar 2016-05-14 151
013e6653 Viresh Kumar 2016-05-14 152 request.load_method = load_method;
b2abeaa1 Viresh Kumar 2016-08-11 @153 strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
013e6653 Viresh Kumar 2016-05-14 154
013e6653 Viresh Kumar 2016-05-14 155 /*
013e6653 Viresh Kumar 2016-05-14 156 * The firmware-tag should be NULL terminated, otherwise throw error and
013e6653 Viresh Kumar 2016-05-14 157 * fail.
013e6653 Viresh Kumar 2016-05-14 158 */
b2abeaa1 Viresh Kumar 2016-08-11 159 if (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
013e6653 Viresh Kumar 2016-05-14 160 dev_err(fw_mgmt->parent, "load-and-validate: firmware-tag is not NULL terminated\n");
013e6653 Viresh Kumar 2016-05-14 161 return -EINVAL;
013e6653 Viresh Kumar 2016-05-14 162 }
013e6653 Viresh Kumar 2016-05-14 163
013e6653 Viresh Kumar 2016-05-14 164 /* Allocate ids from 1 to 255 (u8-max), 0 is an invalid id */
013e6653 Viresh Kumar 2016-05-14 165 ret = ida_simple_get(&fw_mgmt->id_map, 1, 256, GFP_KERNEL);
013e6653 Viresh Kumar 2016-05-14 166 if (ret < 0) {
013e6653 Viresh Kumar 2016-05-14 167 dev_err(fw_mgmt->parent, "failed to allocate request id (%d)\n",
013e6653 Viresh Kumar 2016-05-14 168 ret);
013e6653 Viresh Kumar 2016-05-14 169 return ret;
013e6653 Viresh Kumar 2016-05-14 170 }
013e6653 Viresh Kumar 2016-05-14 171
013e6653 Viresh Kumar 2016-05-14 172 fw_mgmt->intf_fw_request_id = ret;
04f0e6eb Viresh Kumar 2016-05-14 173 fw_mgmt->intf_fw_loaded = false;
013e6653 Viresh Kumar 2016-05-14 174 request.request_id = ret;
013e6653 Viresh Kumar 2016-05-14 175
013e6653 Viresh Kumar 2016-05-14 176 ret = gb_operation_sync(fw_mgmt->connection,
013e6653 Viresh Kumar 2016-05-14 177 GB_FW_MGMT_TYPE_LOAD_AND_VALIDATE_FW, &request,
013e6653 Viresh Kumar 2016-05-14 178 sizeof(request), NULL, 0);
013e6653 Viresh Kumar 2016-05-14 179 if (ret) {
013e6653 Viresh Kumar 2016-05-14 180 ida_simple_remove(&fw_mgmt->id_map,
013e6653 Viresh Kumar 2016-05-14 181 fw_mgmt->intf_fw_request_id);
013e6653 Viresh Kumar 2016-05-14 182 fw_mgmt->intf_fw_request_id = 0;
013e6653 Viresh Kumar 2016-05-14 183 dev_err(fw_mgmt->parent,
013e6653 Viresh Kumar 2016-05-14 184 "load and validate firmware request failed (%d)\n",
013e6653 Viresh Kumar 2016-05-14 185 ret);
013e6653 Viresh Kumar 2016-05-14 186 return ret;
013e6653 Viresh Kumar 2016-05-14 187 }
013e6653 Viresh Kumar 2016-05-14 188
013e6653 Viresh Kumar 2016-05-14 189 return 0;
013e6653 Viresh Kumar 2016-05-14 190 }
013e6653 Viresh Kumar 2016-05-14 191
:::::: The code at line 153 was first introduced by commit
:::::: b2abeaa10d5711e7730bb07120dd60ae27d7b930 greybus: firmware: s/_LEN/_SIZE
:::::: TO: Viresh Kumar <[email protected]>
:::::: CC: Greg Kroah-Hartman <[email protected]>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Hi Changbin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17 next-20180605]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64
All warnings (new ones prefixed by >>):
>> WARNING: vmlinux.o(.text.unlikely+0x1fc): Section mismatch in reference from the function init_tick_ops() to the function .init.text:get_tick_patch()
The function init_tick_ops() references
the function __init get_tick_patch().
This is often because init_tick_ops lacks a __init
annotation or the annotation of get_tick_patch is wrong.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
On Wed, 6 Jun 2018 05:21:55 +0800
kbuild test robot <[email protected]> wrote:
> Hi Changbin,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.17 next-20180605]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415
> config: ia64-allmodconfig (attached as .config)
> compiler: ia64-linux-gcc (GCC) 8.1.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=ia64
>
> All warnings (new ones prefixed by >>):
>
> drivers//staging/greybus/fw-management.c: In function 'fw_mgmt_load_and_validate_operation':
> >> drivers//staging/greybus/fw-management.c:153:2: warning: 'strncpy' specified bound 10 equals destination size [-Wstringop-truncation]
> strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers//staging/greybus/fw-management.c: In function 'fw_mgmt_backend_fw_update_operation':
> drivers//staging/greybus/fw-management.c:304:2: warning: 'strncpy' specified bound 10 equals destination size [-Wstringop-truncation]
> strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> --
> drivers/auxdisplay/panel.c: In function 'panel_bind_key':
> >> drivers/auxdisplay/panel.c:1509:2: warning: 'strncpy' specified bound 12 equals destination size [-Wstringop-truncation]
> strncpy(key->u.kbd.press_str, press, sizeof(key->u.kbd.press_str));
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> drivers/auxdisplay/panel.c:1510:2: warning: 'strncpy' specified bound 12 equals destination size [-Wstringop-truncation]
> strncpy(key->u.kbd.repeat_str, repeat, sizeof(key->u.kbd.repeat_str));
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nice! This patch actually caused bugs in other areas of the code to be
caught by the build system.
The patch is not wrong. The code that has these warnings are.
-- Steve
>
> vim +/strncpy +153 drivers//staging/greybus/fw-management.c
>
> 013e6653 Viresh Kumar 2016-05-14 138
> 013e6653 Viresh Kumar 2016-05-14 139 static int fw_mgmt_load_and_validate_operation(struct fw_mgmt *fw_mgmt,
> 013e6653 Viresh Kumar 2016-05-14 140 u8 load_method, const char *tag)
> 013e6653 Viresh Kumar 2016-05-14 141 {
> 013e6653 Viresh Kumar 2016-05-14 142 struct gb_fw_mgmt_load_and_validate_fw_request request;
> 013e6653 Viresh Kumar 2016-05-14 143 int ret;
> 013e6653 Viresh Kumar 2016-05-14 144
> 013e6653 Viresh Kumar 2016-05-14 145 if (load_method != GB_FW_LOAD_METHOD_UNIPRO &&
> 013e6653 Viresh Kumar 2016-05-14 146 load_method != GB_FW_LOAD_METHOD_INTERNAL) {
> 013e6653 Viresh Kumar 2016-05-14 147 dev_err(fw_mgmt->parent,
> 013e6653 Viresh Kumar 2016-05-14 148 "invalid load-method (%d)\n", load_method);
> 013e6653 Viresh Kumar 2016-05-14 149 return -EINVAL;
> 013e6653 Viresh Kumar 2016-05-14 150 }
> 013e6653 Viresh Kumar 2016-05-14 151
> 013e6653 Viresh Kumar 2016-05-14 152 request.load_method = load_method;
> b2abeaa1 Viresh Kumar 2016-08-11 @153 strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> 013e6653 Viresh Kumar 2016-05-14 154
> 013e6653 Viresh Kumar 2016-05-14 155 /*
> 013e6653 Viresh Kumar 2016-05-14 156 * The firmware-tag should be NULL terminated, otherwise throw error and
> 013e6653 Viresh Kumar 2016-05-14 157 * fail.
> 013e6653 Viresh Kumar 2016-05-14 158 */
> b2abeaa1 Viresh Kumar 2016-08-11 159 if (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
> 013e6653 Viresh Kumar 2016-05-14 160 dev_err(fw_mgmt->parent, "load-and-validate: firmware-tag is not NULL terminated\n");
> 013e6653 Viresh Kumar 2016-05-14 161 return -EINVAL;
> 013e6653 Viresh Kumar 2016-05-14 162 }
> 013e6653 Viresh Kumar 2016-05-14 163
> 013e6653 Viresh Kumar 2016-05-14 164 /* Allocate ids from 1 to 255 (u8-max), 0 is an invalid id */
> 013e6653 Viresh Kumar 2016-05-14 165 ret = ida_simple_get(&fw_mgmt->id_map, 1, 256, GFP_KERNEL);
> 013e6653 Viresh Kumar 2016-05-14 166 if (ret < 0) {
> 013e6653 Viresh Kumar 2016-05-14 167 dev_err(fw_mgmt->parent, "failed to allocate request id (%d)\n",
> 013e6653 Viresh Kumar 2016-05-14 168 ret);
> 013e6653 Viresh Kumar 2016-05-14 169 return ret;
> 013e6653 Viresh Kumar 2016-05-14 170 }
> 013e6653 Viresh Kumar 2016-05-14 171
> 013e6653 Viresh Kumar 2016-05-14 172 fw_mgmt->intf_fw_request_id = ret;
> 04f0e6eb Viresh Kumar 2016-05-14 173 fw_mgmt->intf_fw_loaded = false;
> 013e6653 Viresh Kumar 2016-05-14 174 request.request_id = ret;
> 013e6653 Viresh Kumar 2016-05-14 175
> 013e6653 Viresh Kumar 2016-05-14 176 ret = gb_operation_sync(fw_mgmt->connection,
> 013e6653 Viresh Kumar 2016-05-14 177 GB_FW_MGMT_TYPE_LOAD_AND_VALIDATE_FW, &request,
> 013e6653 Viresh Kumar 2016-05-14 178 sizeof(request), NULL, 0);
> 013e6653 Viresh Kumar 2016-05-14 179 if (ret) {
> 013e6653 Viresh Kumar 2016-05-14 180 ida_simple_remove(&fw_mgmt->id_map,
> 013e6653 Viresh Kumar 2016-05-14 181 fw_mgmt->intf_fw_request_id);
> 013e6653 Viresh Kumar 2016-05-14 182 fw_mgmt->intf_fw_request_id = 0;
> 013e6653 Viresh Kumar 2016-05-14 183 dev_err(fw_mgmt->parent,
> 013e6653 Viresh Kumar 2016-05-14 184 "load and validate firmware request failed (%d)\n",
> 013e6653 Viresh Kumar 2016-05-14 185 ret);
> 013e6653 Viresh Kumar 2016-05-14 186 return ret;
> 013e6653 Viresh Kumar 2016-05-14 187 }
> 013e6653 Viresh Kumar 2016-05-14 188
> 013e6653 Viresh Kumar 2016-05-14 189 return 0;
> 013e6653 Viresh Kumar 2016-05-14 190 }
> 013e6653 Viresh Kumar 2016-05-14 191
>
> :::::: The code at line 153 was first introduced by commit
> :::::: b2abeaa10d5711e7730bb07120dd60ae27d7b930 greybus: firmware: s/_LEN/_SIZE
>
> :::::: TO: Viresh Kumar <[email protected]>
> :::::: CC: Greg Kroah-Hartman <[email protected]>
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
On Wed, 6 Jun 2018 05:34:29 +0800
kbuild test robot <[email protected]> wrote:
> Hi Changbin,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.17 next-20180605]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415
> config: sparc64-allyesconfig (attached as .config)
> compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=sparc64
>
> All warnings (new ones prefixed by >>):
>
> >> WARNING: vmlinux.o(.text.unlikely+0x1fc): Section mismatch in reference from the function init_tick_ops() to the function .init.text:get_tick_patch()
> The function init_tick_ops() references
> the function __init get_tick_patch().
> This is often because init_tick_ops lacks a __init
> annotation or the annotation of get_tick_patch is wrong.
And again this patch uncovered a bug someplace else.
-- Steve
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
On Wed, Jun 06, 2018 at 09:57:14AM -0400, Steven Rostedt wrote:
> On Wed, 6 Jun 2018 05:21:55 +0800
> kbuild test robot <[email protected]> wrote:
>
> > Hi Changbin,
> >
> > Thank you for the patch! Perhaps something to improve:
> >
> > [auto build test WARNING on linus/master]
> > [also build test WARNING on v4.17 next-20180605]
> > [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
> >
> > url: https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415
> > config: ia64-allmodconfig (attached as .config)
> > compiler: ia64-linux-gcc (GCC) 8.1.0
> > reproduce:
> > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > make.cross ARCH=ia64
> >
> > All warnings (new ones prefixed by >>):
> >
> > drivers//staging/greybus/fw-management.c: In function 'fw_mgmt_load_and_validate_operation':
> > >> drivers//staging/greybus/fw-management.c:153:2: warning: 'strncpy' specified bound 10 equals destination size [-Wstringop-truncation]
> > strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > drivers//staging/greybus/fw-management.c: In function 'fw_mgmt_backend_fw_update_operation':
> > drivers//staging/greybus/fw-management.c:304:2: warning: 'strncpy' specified bound 10 equals destination size [-Wstringop-truncation]
> > strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > --
> > drivers/auxdisplay/panel.c: In function 'panel_bind_key':
> > >> drivers/auxdisplay/panel.c:1509:2: warning: 'strncpy' specified bound 12 equals destination size [-Wstringop-truncation]
> > strncpy(key->u.kbd.press_str, press, sizeof(key->u.kbd.press_str));
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > drivers/auxdisplay/panel.c:1510:2: warning: 'strncpy' specified bound 12 equals destination size [-Wstringop-truncation]
> > strncpy(key->u.kbd.repeat_str, repeat, sizeof(key->u.kbd.repeat_str));
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Nice! This patch actually caused bugs in other areas of the code to be
> caught by the build system.
>
> The patch is not wrong. The code that has these warnings are.
Looks like the greybus code above is working as intended by checking for
unterminated string after the strncpy, even if this does now triggers
the truncation warning.
drivers/auxdisplay/panel.c looks broken, though.
> > vim +/strncpy +153 drivers//staging/greybus/fw-management.c
> >
> > 013e6653 Viresh Kumar 2016-05-14 138
> > 013e6653 Viresh Kumar 2016-05-14 139 static int fw_mgmt_load_and_validate_operation(struct fw_mgmt *fw_mgmt,
> > 013e6653 Viresh Kumar 2016-05-14 140 u8 load_method, const char *tag)
> > 013e6653 Viresh Kumar 2016-05-14 141 {
> > 013e6653 Viresh Kumar 2016-05-14 142 struct gb_fw_mgmt_load_and_validate_fw_request request;
> > 013e6653 Viresh Kumar 2016-05-14 143 int ret;
> > 013e6653 Viresh Kumar 2016-05-14 144
> > 013e6653 Viresh Kumar 2016-05-14 145 if (load_method != GB_FW_LOAD_METHOD_UNIPRO &&
> > 013e6653 Viresh Kumar 2016-05-14 146 load_method != GB_FW_LOAD_METHOD_INTERNAL) {
> > 013e6653 Viresh Kumar 2016-05-14 147 dev_err(fw_mgmt->parent,
> > 013e6653 Viresh Kumar 2016-05-14 148 "invalid load-method (%d)\n", load_method);
> > 013e6653 Viresh Kumar 2016-05-14 149 return -EINVAL;
> > 013e6653 Viresh Kumar 2016-05-14 150 }
> > 013e6653 Viresh Kumar 2016-05-14 151
> > 013e6653 Viresh Kumar 2016-05-14 152 request.load_method = load_method;
> > b2abeaa1 Viresh Kumar 2016-08-11 @153 strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> > 013e6653 Viresh Kumar 2016-05-14 154
> > 013e6653 Viresh Kumar 2016-05-14 155 /*
> > 013e6653 Viresh Kumar 2016-05-14 156 * The firmware-tag should be NULL terminated, otherwise throw error and
> > 013e6653 Viresh Kumar 2016-05-14 157 * fail.
> > 013e6653 Viresh Kumar 2016-05-14 158 */
> > b2abeaa1 Viresh Kumar 2016-08-11 159 if (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
> > 013e6653 Viresh Kumar 2016-05-14 160 dev_err(fw_mgmt->parent, "load-and-validate: firmware-tag is not NULL terminated\n");
> > 013e6653 Viresh Kumar 2016-05-14 161 return -EINVAL;
> > 013e6653 Viresh Kumar 2016-05-14 162 }
Viresh, do you want to work around the warning somehow?
Thanks,
Johan
On Wed, 6 Jun 2018 16:26:00 +0200
Johan Hovold <[email protected]> wrote:
> Looks like the greybus code above is working as intended by checking for
> unterminated string after the strncpy, even if this does now triggers
> the truncation warning.
Ah, yes I now see that. Thanks for pointing it out. But perhaps it
should also add the "- 1" to the strncpy() so that gcc doesn't think
it's a mistake.
-- Steve
+Greg/Alex,
@Fegguang/build-bot: I do see mention of Greg and /me in your initial email's
body saying TO: Viresh, CC: Greg, but I don't see any of us getting cc'd in your
email. Bug ?
On 06-06-18, 14:26, Steven Rostedt wrote:
> On Wed, 6 Jun 2018 16:26:00 +0200
> Johan Hovold <[email protected]> wrote:
>
> > Looks like the greybus code above is working as intended by checking for
> > unterminated string after the strncpy, even if this does now triggers
> > the truncation warning.
So why exactly are we generating a warning here ? Is it because it is possible
that the first n bytes of src may not have the null terminating byte and the
dest may not be null terminated eventually ?
Maybe I should just use memcpy here then ?
But AFAIR, I used strncpy() specifically because it also sets all the remaining
bytes after the null terminating byte with the null terminating byte. And so it
is pretty easy for me to check if the final string is null terminated by
checking [max - 1] byte against '\0', which the code is doing right now.
I am not sure what would the best way to get around this incorrect-warning.
And I am wondering on why buildbot reported the warning only for two instances
in that file, while I have done the same thing at 4 places.
> Ah, yes I now see that. Thanks for pointing it out. But perhaps it
> should also add the "- 1" to the strncpy() so that gcc doesn't think
> it's a mistake.
The src string is passed on from a firmware entity and we need to make sure the
protocol (greybus) is implemented properly by the other end. For example, in the
current case if the firmware sends "HELLOWORLD", its an error as it should have
sent "HELLWORLD\0". But with what you are saying we will forcefully make dest as
"HELLWORLD\0", which wouldn't be the right thing to do as we will miss the bug
present in firmware.
--
viresh
Hi,
On Thu, Jun 07, 2018 at 09:47:18AM +0530, Viresh Kumar wrote:
> +Greg/Alex,
>
> @Fegguang/build-bot: I do see mention of Greg and /me in your initial email's
> body saying TO: Viresh, CC: Greg, but I don't see any of us getting cc'd in your
> email. Bug ?
>
> On 06-06-18, 14:26, Steven Rostedt wrote:
> > On Wed, 6 Jun 2018 16:26:00 +0200
> > Johan Hovold <[email protected]> wrote:
> >
> > > Looks like the greybus code above is working as intended by checking for
> > > unterminated string after the strncpy, even if this does now triggers
> > > the truncation warning.
>
> So why exactly are we generating a warning here ? Is it because it is possible
> that the first n bytes of src may not have the null terminating byte and the
> dest may not be null terminated eventually ?
>
> Maybe I should just use memcpy here then ?
>
I think if the destination is not a null terminated string (If I understand your
description below), memcpy can be used to get rid of such warning. The warning
makes sense in general as explained in mannual. Thanks!
> But AFAIR, I used strncpy() specifically because it also sets all the remaining
> bytes after the null terminating byte with the null terminating byte. And so it
> is pretty easy for me to check if the final string is null terminated by
> checking [max - 1] byte against '\0', which the code is doing right now.
>
> I am not sure what would the best way to get around this incorrect-warning.
>
> And I am wondering on why buildbot reported the warning only for two instances
> in that file, while I have done the same thing at 4 places.
>
> > Ah, yes I now see that. Thanks for pointing it out. But perhaps it
> > should also add the "- 1" to the strncpy() so that gcc doesn't think
> > it's a mistake.
>
> The src string is passed on from a firmware entity and we need to make sure the
> protocol (greybus) is implemented properly by the other end. For example, in the
> current case if the firmware sends "HELLOWORLD", its an error as it should have
> sent "HELLWORLD\0". But with what you are saying we will forcefully make dest as
> "HELLWORLD\0", which wouldn't be the right thing to do as we will miss the bug
> present in firmware.
>
> --
> viresh
--
Thanks,
Changbin Du
On Thu, Jun 07, 2018 at 09:47:18AM +0530, Viresh Kumar wrote:
> On 06-06-18, 14:26, Steven Rostedt wrote:
> > On Wed, 6 Jun 2018 16:26:00 +0200
> > Johan Hovold <[email protected]> wrote:
> >
> > > Looks like the greybus code above is working as intended by checking for
> > > unterminated string after the strncpy, even if this does now triggers
> > > the truncation warning.
>
> So why exactly are we generating a warning here ? Is it because it is possible
> that the first n bytes of src may not have the null terminating byte and the
> dest may not be null terminated eventually ?
Yes, new warning in GCC 8:
https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Warning-Options.html#index-Wstringop-truncation
> Maybe I should just use memcpy here then ?
No, as you note below, you use strncpy to clear the rest of the buffer.
> But AFAIR, I used strncpy() specifically because it also sets all the remaining
> bytes after the null terminating byte with the null terminating byte. And so it
> is pretty easy for me to check if the final string is null terminated by
> checking [max - 1] byte against '\0', which the code is doing right now.
>
> I am not sure what would the best way to get around this incorrect-warning.
It seems gcc just isn't smart enough in this case (where you check for
overflow and never use a non-terminated string), but it is supposed to
detect when the string is unconditionally terminated. So perhaps just
adding a redundant buf[size-1] = '\0' before returning in the error path
or after the error path would shut it up. But that's a bit of a long
shot, I admit.
Probably best to leave things as they are, and let the gcc folks find a
way to handle such false positives.
Thanks,
Johan
On 07-06-18, 15:46, Du, Changbin wrote:
> I think if the destination is not a null terminated string (If I understand your
> description below), memcpy can be used to get rid of such warning. The warning
> makes sense in general as explained in mannual. Thanks!
The destination should be a null terminated string eventually, but we first need
to make sure src is a null terminated string.
--
viresh
On Thu, Jun 07, 2018 at 02:40:25PM +0530, Viresh Kumar wrote:
> On 07-06-18, 11:03, Bernd Petrovitsch wrote:
> > On Thu, 2018-06-07 at 14:08 +0530, Viresh Kumar wrote:
> > > On 07-06-18, 15:46, Du, Changbin wrote:
> > > > I think if the destination is not a null terminated string (If I understand your
> > > > description below), memcpy can be used to get rid of such warning. The warning
> > > > makes sense in general as explained in mannual. Thanks!
> > >
> > > The destination should be a null terminated string eventually, but we first need
> > > to make sure src is a null terminated string.
> >
> > Is there strnlen() or memchr() in the kernel?
> > Then check the source before copying it.
>
> It would be extra work, but memchr can be used to work around this I believe.
>
> @Johan ??
If you want to work around the warning and think you can do it in some
non-contrived way, then go for it.
Clearing the request buffer, checking for termination using strnlen, and
then using memcpy might not be too bad.
But after all, it is a false positive, so leaving things as they stand
is fine too.
Thanks,
Johan
On 07-06-18, 11:18, Johan Hovold wrote:
> If you want to work around the warning and think you can do it in some
> non-contrived way, then go for it.
>
> Clearing the request buffer, checking for termination using strnlen, and
> then using memcpy might not be too bad.
>
> But after all, it is a false positive, so leaving things as they stand
> is fine too.
Leave it then :)
--
viresh
On 07-06-18, 11:03, Bernd Petrovitsch wrote:
> On Thu, 2018-06-07 at 14:08 +0530, Viresh Kumar wrote:
> > On 07-06-18, 15:46, Du, Changbin wrote:
> > > I think if the destination is not a null terminated string (If I understand your
> > > description below), memcpy can be used to get rid of such warning. The warning
> > > makes sense in general as explained in mannual. Thanks!
> >
> > The destination should be a null terminated string eventually, but we first need
> > to make sure src is a null terminated string.
>
> Is there strnlen() or memchr() in the kernel?
> Then check the source before copying it.
It would be extra work, but memchr can be used to work around this I believe.
@Johan ??
--
viresh
On 06/07/2018 04:19 AM, Viresh Kumar wrote:
> On 07-06-18, 11:18, Johan Hovold wrote:
>> If you want to work around the warning and think you can do it in some
>> non-contrived way, then go for it.
>>
>> Clearing the request buffer, checking for termination using strnlen, and
>> then using memcpy might not be too bad.
>>
>> But after all, it is a false positive, so leaving things as they stand
>> is fine too.
>
> Leave it then :)
>
It's interesting that the warning isn't reported for this in
fw_mgmt_interface_fw_version_operation(). The difference there is
that you actually put a zero byte at that last position before
returning. I'm mildly impressed if gcc is distinguishing that.
You *are* returning the fw_info->firmware_tag array newly filled
with a non-null-terminated string in one of the two cases that
get warnings in "fw-management.c". But the other one is only
updating a buffer in a local/automatic variable.
Weird. I wish there were a non-clumsy way of marking false positives
like this as A-OK.
-Alex
On Thu, Jun 07, 2018 at 05:12:51AM -0500, Alex Elder wrote:
> On 06/07/2018 04:19 AM, Viresh Kumar wrote:
> > On 07-06-18, 11:18, Johan Hovold wrote:
> >> If you want to work around the warning and think you can do it in some
> >> non-contrived way, then go for it.
> >>
> >> Clearing the request buffer, checking for termination using strnlen, and
> >> then using memcpy might not be too bad.
> >>
> >> But after all, it is a false positive, so leaving things as they stand
> >> is fine too.
> >
> > Leave it then :)
> >
>
> It's interesting that the warning isn't reported for this in
> fw_mgmt_interface_fw_version_operation(). The difference there is
> that you actually put a zero byte at that last position before
> returning. I'm mildly impressed if gcc is distinguishing that.
Found a redhat blog post claiming it does check for some cases like
that:
https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/
> You *are* returning the fw_info->firmware_tag array newly filled
> with a non-null-terminated string in one of the two cases that
> get warnings in "fw-management.c".
No, there's no warning for that one (line 250), and there fw_info is
used as the source, not the destination, so no unterminated string is
returned there either.
> But the other one is only
> updating a buffer in a local/automatic variable.
All three cases, except the one that is explicitly terminated.
> Weird. I wish there were a non-clumsy way of marking false positives
> like this as A-OK.
The gcc docs mentions an attribute for that but it seems a bit overkill
here.
Thanks,
Johan
On Thu, 2018-06-07 at 14:08 +0530, Viresh Kumar wrote:
> On 07-06-18, 15:46, Du, Changbin wrote:
> > I think if the destination is not a null terminated string (If I understand your
> > description below), memcpy can be used to get rid of such warning. The warning
> > makes sense in general as explained in mannual. Thanks!
>
> The destination should be a null terminated string eventually, but we first need
> to make sure src is a null terminated string.
Is there strnlen() or memchr() in the kernel?
Then check the source before copying it.
Kind regards,
Bernd
--
Bernd Petrovitsch Email : [email protected]
LUGA : http://www.luga.at
On Thu, 7 Jun 2018 11:18:16 +0200
Johan Hovold <[email protected]> wrote:
> If you want to work around the warning and think you can do it in some
> non-contrived way, then go for it.
>
> Clearing the request buffer, checking for termination using strnlen, and
> then using memcpy might not be too bad.
>
> But after all, it is a false positive, so leaving things as they stand
> is fine too.
Not sure how contrived you think this is, but it solves the warning
without adding extra work in the normal case.
-- Steve
diff --git a/drivers/staging/greybus/fw-management.c b/drivers/staging/greybus/fw-management.c
index 71aec14f8181..4fb9f1dff47d 100644
--- a/drivers/staging/greybus/fw-management.c
+++ b/drivers/staging/greybus/fw-management.c
@@ -150,15 +150,18 @@ static int fw_mgmt_load_and_validate_operation(struct fw_mgmt *fw_mgmt,
}
request.load_method = load_method;
- strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
+ strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE - 1);
/*
* The firmware-tag should be NULL terminated, otherwise throw error and
* fail.
*/
- if (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
- dev_err(fw_mgmt->parent, "load-and-validate: firmware-tag is not NULL terminated\n");
- return -EINVAL;
+ if (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 2] != '\0') {
+ if (tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
+ dev_err(fw_mgmt->parent, "load-and-validate: firmware-tag is not NULL terminated\n");
+ return -EINVAL;
+ }
+ request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] = '\0';
}
/* Allocate ids from 1 to 255 (u8-max), 0 is an invalid id */
Hi Changbin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17 next-20180608]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415
config: i386-randconfig-x079-06101602 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
In file included from arch/x86/include/asm/page_32.h:35:0,
from arch/x86/include/asm/page.h:14,
from arch/x86/include/asm/thread_info.h:12,
from include/linux/thread_info.h:38,
from arch/x86/include/asm/preempt.h:7,
from include/linux/preempt.h:81,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/module.h:10,
from net//bluetooth/mgmt.c:27:
net//bluetooth/mgmt.c: In function 'read_local_oob_ext_data_complete':
>> include/linux/string.h:345:9: warning: 'r256' may be used uninitialized in this function [-Wmaybe-uninitialized]
return __builtin_memcpy(p, q, size);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
net//bluetooth/mgmt.c:5669:27: note: 'r256' was declared here
u8 *h192, *r192, *h256, *r256;
^~~~
--
In file included from arch/x86/include/asm/page_32.h:35:0,
from arch/x86/include/asm/page.h:14,
from arch/x86/include/asm/thread_info.h:12,
from include/linux/thread_info.h:38,
from arch/x86/include/asm/preempt.h:7,
from include/linux/preempt.h:81,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/module.h:10,
from net/bluetooth/mgmt.c:27:
net/bluetooth/mgmt.c: In function 'read_local_oob_ext_data_complete':
>> include/linux/string.h:345:9: warning: 'r256' may be used uninitialized in this function [-Wmaybe-uninitialized]
return __builtin_memcpy(p, q, size);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
net/bluetooth/mgmt.c:5669:27: note: 'r256' was declared here
u8 *h192, *r192, *h256, *r256;
^~~~
vim +/r256 +345 include/linux/string.h
6974f0c4 Daniel Micay 2017-07-12 332
6974f0c4 Daniel Micay 2017-07-12 333 __FORTIFY_INLINE void *memcpy(void *p, const void *q, __kernel_size_t size)
6974f0c4 Daniel Micay 2017-07-12 334 {
6974f0c4 Daniel Micay 2017-07-12 335 size_t p_size = __builtin_object_size(p, 0);
6974f0c4 Daniel Micay 2017-07-12 336 size_t q_size = __builtin_object_size(q, 0);
6974f0c4 Daniel Micay 2017-07-12 337 if (__builtin_constant_p(size)) {
6974f0c4 Daniel Micay 2017-07-12 338 if (p_size < size)
6974f0c4 Daniel Micay 2017-07-12 339 __write_overflow();
6974f0c4 Daniel Micay 2017-07-12 340 if (q_size < size)
6974f0c4 Daniel Micay 2017-07-12 341 __read_overflow2();
6974f0c4 Daniel Micay 2017-07-12 342 }
6974f0c4 Daniel Micay 2017-07-12 343 if (p_size < size || q_size < size)
6974f0c4 Daniel Micay 2017-07-12 344 fortify_panic(__func__);
6974f0c4 Daniel Micay 2017-07-12 @345 return __builtin_memcpy(p, q, size);
6974f0c4 Daniel Micay 2017-07-12 346 }
6974f0c4 Daniel Micay 2017-07-12 347
:::::: The code at line 345 was first introduced by commit
:::::: 6974f0c4555e285ab217cee58b6e874f776ff409 include/linux/string.h: add the option of fortified string.h functions
:::::: TO: Daniel Micay <[email protected]>
:::::: CC: Linus Torvalds <[email protected]>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Hi Changbin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17 next-20180608]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415
config: i386-randconfig-x076-06101602 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers//usb/typec/fusb302/fusb302.c: In function 'fusb302_handle_togdone_src':
>> drivers//usb/typec/fusb302/fusb302.c:1413:10: warning: 'ra_comp' may be used uninitialized in this function [-Wmaybe-uninitialized]
else if (ra_comp)
^
--
drivers/infiniband/ulp/ipoib/ipoib_main.c: In function 'ipoib_get_netdev':
>> drivers/infiniband/ulp/ipoib/ipoib_main.c:2021:30: warning: 'dev' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (!hca->alloc_rdma_netdev || PTR_ERR(dev) == -EOPNOTSUPP)
--
kernel//cgroup/cgroup-v1.c: In function 'cgroup1_mount':
>> kernel//cgroup/cgroup-v1.c:1268:3: warning: 'root' may be used uninitialized in this function [-Wmaybe-uninitialized]
percpu_ref_reinit(&root->cgrp.self.refcnt);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
kernel//trace/bpf_trace.c: In function 'bpf_trace_printk':
>> kernel//trace/bpf_trace.c:226:20: warning: 'unsafe_addr' may be used uninitialized in this function [-Wmaybe-uninitialized]
(void *) (long) unsafe_addr,
^~~~~~~~~~~~~~~~~~
kernel//trace/bpf_trace.c:170:6: note: 'unsafe_addr' was declared here
u64 unsafe_addr;
^~~~~~~~~~~
--
net//6lowpan/iphc.c: In function 'lowpan_header_decompress':
net//6lowpan/iphc.c:617:12: warning: 'iphc1' may be used uninitialized in this function [-Wmaybe-uninitialized]
u8 iphc0, iphc1, cid = 0;
^~~~~
>> net//6lowpan/iphc.c:617:5: warning: 'iphc0' may be used uninitialized in this function [-Wmaybe-uninitialized]
u8 iphc0, iphc1, cid = 0;
^~~~~
--
net//netfilter/nf_tables_api.c: In function 'nf_tables_dump_set':
>> net//netfilter/nf_tables_api.c:3625:2: warning: 'set' may be used uninitialized in this function [-Wmaybe-uninitialized]
set->ops->walk(&dump_ctx->ctx, set, &args.iter);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
drivers/media/dvb-frontends/mn88472.c: In function 'mn88472_set_frontend':
>> drivers/media/dvb-frontends/mn88472.c:339:27: warning: 'bandwidth_vals_ptr' may be used uninitialized in this function [-Wmaybe-uninitialized]
bandwidth_vals_ptr[i]);
^
>> drivers/media/dvb-frontends/mn88472.c:320:8: warning: 'bandwidth_val' may be used uninitialized in this function [-Wmaybe-uninitialized]
ret = regmap_write(dev->regmap[2], 0x04, bandwidth_val);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
drivers/media/dvb-frontends/mn88473.c: In function 'mn88473_set_frontend':
>> drivers/media/dvb-frontends/mn88473.c:162:7: warning: 'conf_val_ptr' may be used uninitialized in this function [-Wmaybe-uninitialized]
ret = regmap_bulk_write(dev->regmap[1], 0x10, conf_val_ptr, 6);
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
net//netfilter/ipvs/ip_vs_sync.c: In function 'ip_vs_sync_conn':
>> net//netfilter/ipvs/ip_vs_sync.c:731:13: warning: 'm' may be used uninitialized in this function [-Wmaybe-uninitialized]
m->nr_conns++;
~~~~~~~~~~~^~
--
drivers//hwspinlock/hwspinlock_core.c: In function 'of_hwspin_lock_get_id':
>> drivers//hwspinlock/hwspinlock_core.c:339:19: warning: 'id' may be used uninitialized in this function [-Wmaybe-uninitialized]
return ret ? ret : id;
~~~~~~~~~~^~~~
--
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c: In function 'mlxsw_sp_nexthop_group_update':
>> drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3078:7: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized]
if (err)
^
vim +/ra_comp +1413 drivers//usb/typec/fusb302/fusb302.c
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1359
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1360 static int fusb302_handle_togdone_src(struct fusb302_chip *chip,
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1361 u8 togdone_result)
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1362 {
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1363 /*
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1364 * - set polarity (measure cc, vconn, tx)
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1365 * - set pull_up, pull_down
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1366 * - set cc1, cc2, and update to tcpm_port
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1367 * - set I_COMP interrupt on
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1368 */
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1369 int ret = 0;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1370 u8 status0;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1371 u8 ra_mda = ra_mda_value[chip->src_current_status];
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1372 u8 rd_mda = rd_mda_value[chip->src_current_status];
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1373 bool ra_comp, rd_comp;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1374 enum typec_cc_polarity cc_polarity;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1375 enum typec_cc_status cc_status_active, cc1, cc2;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1376
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1377 /* set pull_up, pull_down */
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1378 ret = fusb302_set_cc_pull(chip, true, false);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1379 if (ret < 0) {
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1380 fusb302_log(chip, "cannot set cc to pull up, ret=%d", ret);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1381 return ret;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1382 }
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1383 /* set polarity */
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1384 cc_polarity = (togdone_result == FUSB_REG_STATUS1A_TOGSS_SRC1) ?
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1385 TYPEC_POLARITY_CC1 : TYPEC_POLARITY_CC2;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1386 ret = fusb302_set_cc_polarity(chip, cc_polarity);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1387 if (ret < 0) {
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1388 fusb302_log(chip, "cannot set cc polarity %s, ret=%d",
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1389 cc_polarity_name[cc_polarity], ret);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1390 return ret;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1391 }
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1392 /* fusb302_set_cc_polarity() has set the correct measure block */
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1393 ret = fusb302_i2c_write(chip, FUSB_REG_MEASURE, rd_mda);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1394 if (ret < 0)
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1395 return ret;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1396 usleep_range(50, 100);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1397 ret = fusb302_i2c_read(chip, FUSB_REG_STATUS0, &status0);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1398 if (ret < 0)
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1399 return ret;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1400 rd_comp = !!(status0 & FUSB_REG_STATUS0_COMP);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1401 if (!rd_comp) {
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1402 ret = fusb302_i2c_write(chip, FUSB_REG_MEASURE, ra_mda);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1403 if (ret < 0)
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1404 return ret;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1405 usleep_range(50, 100);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1406 ret = fusb302_i2c_read(chip, FUSB_REG_STATUS0, &status0);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1407 if (ret < 0)
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1408 return ret;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1409 ra_comp = !!(status0 & FUSB_REG_STATUS0_COMP);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1410 }
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1411 if (rd_comp)
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1412 cc_status_active = TYPEC_CC_OPEN;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 @1413 else if (ra_comp)
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1414 cc_status_active = TYPEC_CC_RD;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1415 else
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1416 /* Ra is not supported, report as Open */
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1417 cc_status_active = TYPEC_CC_OPEN;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1418 /* restart toggling if the cc status on the active line is OPEN */
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1419 if (cc_status_active == TYPEC_CC_OPEN) {
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1420 fusb302_log(chip, "restart toggling as CC_OPEN detected");
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1421 ret = fusb302_set_toggling(chip, chip->toggling_mode);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1422 return ret;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1423 }
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1424 /* update tcpm with the new cc value */
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1425 cc1 = (cc_polarity == TYPEC_POLARITY_CC1) ?
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1426 cc_status_active : TYPEC_CC_OPEN;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1427 cc2 = (cc_polarity == TYPEC_POLARITY_CC2) ?
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1428 cc_status_active : TYPEC_CC_OPEN;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1429 if ((chip->cc1 != cc1) || (chip->cc2 != cc2)) {
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1430 chip->cc1 = cc1;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1431 chip->cc2 = cc2;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1432 tcpm_cc_change(chip->tcpm_port);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1433 }
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1434 /* turn off toggling */
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1435 ret = fusb302_set_toggling(chip, TOGGLINE_MODE_OFF);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1436 if (ret < 0) {
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1437 fusb302_log(chip,
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1438 "cannot set toggling mode off, ret=%d", ret);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1439 return ret;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1440 }
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1441 /* set MDAC to Rd threshold, and unmask I_COMP for unplug detection */
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1442 ret = fusb302_i2c_write(chip, FUSB_REG_MEASURE, rd_mda);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1443 if (ret < 0)
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1444 return ret;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1445 /* unmask comp_chng interrupt */
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1446 ret = fusb302_i2c_clear_bits(chip, FUSB_REG_MASK,
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1447 FUSB_REG_MASK_COMP_CHNG);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1448 if (ret < 0) {
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1449 fusb302_log(chip,
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1450 "cannot unmask bc_lcl interrupt, ret=%d", ret);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1451 return ret;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1452 }
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1453 chip->intr_comp_chng = true;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1454 fusb302_log(chip, "detected cc1=%s, cc2=%s",
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1455 typec_cc_status_name[cc1],
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1456 typec_cc_status_name[cc2]);
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1457
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1458 return ret;
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1459 }
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1460
:::::: The code at line 1413 was first introduced by commit
:::::: c034a43e72dda58e4a184d71f5502ef356e04453 staging: typec: Fairchild FUSB302 Type-c chip driver
:::::: TO: Yueyao Zhu <[email protected]>
:::::: CC: Greg Kroah-Hartman <[email protected]>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
On Fri, Jun 08, 2018 at 04:03:55PM -0400, Steven Rostedt wrote:
> On Thu, 7 Jun 2018 11:18:16 +0200
> Johan Hovold <[email protected]> wrote:
>
>
> > If you want to work around the warning and think you can do it in some
> > non-contrived way, then go for it.
> >
> > Clearing the request buffer, checking for termination using strnlen, and
> > then using memcpy might not be too bad.
> >
> > But after all, it is a false positive, so leaving things as they stand
> > is fine too.
>
> Not sure how contrived you think this is, but it solves the warning
> without adding extra work in the normal case.
>
> -- Steve
>
> diff --git a/drivers/staging/greybus/fw-management.c b/drivers/staging/greybus/fw-management.c
> index 71aec14f8181..4fb9f1dff47d 100644
> --- a/drivers/staging/greybus/fw-management.c
> +++ b/drivers/staging/greybus/fw-management.c
> @@ -150,15 +150,18 @@ static int fw_mgmt_load_and_validate_operation(struct fw_mgmt *fw_mgmt,
> }
>
> request.load_method = load_method;
> - strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE);
> + strncpy(request.firmware_tag, tag, GB_FIRMWARE_TAG_MAX_SIZE - 1);
>
> /*
> * The firmware-tag should be NULL terminated, otherwise throw error and
> * fail.
> */
> - if (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
> - dev_err(fw_mgmt->parent, "load-and-validate: firmware-tag is not NULL terminated\n");
> - return -EINVAL;
> + if (request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 2] != '\0') {
> + if (tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] != '\0') {
> + dev_err(fw_mgmt->parent, "load-and-validate: firmware-tag is not NULL terminated\n");
> + return -EINVAL;
> + }
> + request.firmware_tag[GB_FIRMWARE_TAG_MAX_SIZE - 1] = '\0';
> }
Well, I think it's quite far from obvious what is going on above, and
not least why things are being done this way (which a comment may help
with).
And just NUL-terminating the (automatic) buffer before returning wasn't
enough? Then it may be better to do away with strncpy completely.
But should we really be working around gcc this way? If the
implementation of this new warning isn't smart enough yet, should it not
just be disabled instead?
Thanks,
Johan
On Sun, 10 Jun 2018 23:49:55 +0800
kbuild test robot <[email protected]> wrote:
> Hi Changbin,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.17 next-20180608]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415
> config: i386-randconfig-x076-06101602 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
> http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
>
> All warnings (new ones prefixed by >>):
>
> drivers//usb/typec/fusb302/fusb302.c: In function 'fusb302_handle_togdone_src':
> >> drivers//usb/typec/fusb302/fusb302.c:1413:10: warning: 'ra_comp' may be used uninitialized in this function [-Wmaybe-uninitialized]
> else if (ra_comp)
> ^
This is a false warning. I'm surprised gcc couldn't catch it. Although
that code looks like it could have been done a bit nicer.
> --
> drivers/infiniband/ulp/ipoib/ipoib_main.c: In function 'ipoib_get_netdev':
> >> drivers/infiniband/ulp/ipoib/ipoib_main.c:2021:30: warning: 'dev' may be used uninitialized in this function [-Wmaybe-uninitialized]
> if (!hca->alloc_rdma_netdev || PTR_ERR(dev) == -EOPNOTSUPP)
> --
Strange, this is also false, with the same construct.
if (a) {
b = init;
}
if (!a) {
use b;
It warns that b may be unused. I'm guessing the extra option we add in
gcc by the patch causes gcc to break in this regard.
> kernel//cgroup/cgroup-v1.c: In function 'cgroup1_mount':
> >> kernel//cgroup/cgroup-v1.c:1268:3: warning: 'root' may be used uninitialized in this function [-Wmaybe-uninitialized]
> percpu_ref_reinit(&root->cgrp.self.refcnt);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> --
Slightly different construct, but similar:
ret = func();
if (ret)
goto out_unlock;
root = init;
out_unlock:
if (ret)
return;
use root;
> kernel//trace/bpf_trace.c: In function 'bpf_trace_printk':
> >> kernel//trace/bpf_trace.c:226:20: warning: 'unsafe_addr' may be used uninitialized in this function [-Wmaybe-uninitialized]
> (void *) (long) unsafe_addr,
> ^~~~~~~~~~~~~~~~~~
Again similar:
if (fmt_cnt >= 3)
return;
switch (fmt_cnt) {
case 1:
unsafe_addr = init;
break;
case 2:
unsafe_addr = init2;
break;
case 3:
unsafe_addr = init3;
break;
}
use init;
> kernel//trace/bpf_trace.c:170:6: note: 'unsafe_addr' was declared here
> u64 unsafe_addr;
> ^~~~~~~~~~~
> --
> net//6lowpan/iphc.c: In function 'lowpan_header_decompress':
> net//6lowpan/iphc.c:617:12: warning: 'iphc1' may be used uninitialized in this function [-Wmaybe-uninitialized]
> u8 iphc0, iphc1, cid = 0;
> ^~~~~
> >> net//6lowpan/iphc.c:617:5: warning: 'iphc0' may be used uninitialized in this function [-Wmaybe-uninitialized]
> u8 iphc0, iphc1, cid = 0;
> ^~~~~
Similar but crazier:
if (lowpan_fetch_skb(&iphc0) ||
lowpan_fetch_skb(&iphc1))
return;
use iphc0 and ipch1;
where lowpan_fetch_skb() is:
if (test())
return true;
init data (iphc0 or iphc1);
return false;
> --
> net//netfilter/nf_tables_api.c: In function 'nf_tables_dump_set':
> >> net//netfilter/nf_tables_api.c:3625:2: warning: 'set' may be used uninitialized in this function [-Wmaybe-uninitialized]
> set->ops->walk(&dump_ctx->ctx, set, &args.iter);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't have the same kernel, as this doesn't match. But I'm sure it's
a false positive like the others.
> --
> drivers/media/dvb-frontends/mn88472.c: In function 'mn88472_set_frontend':
> >> drivers/media/dvb-frontends/mn88472.c:339:27: warning: 'bandwidth_vals_ptr' may be used uninitialized in this function [-Wmaybe-uninitialized]
> bandwidth_vals_ptr[i]);
> ^
> >> drivers/media/dvb-frontends/mn88472.c:320:8: warning: 'bandwidth_val' may be used uninitialized in this function [-Wmaybe-uninitialized]
> ret = regmap_write(dev->regmap[2], 0x04, bandwidth_val);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This one may not be a false positive. It really looks like there's a
path to that being used uninitialized. But I haven't torn that function
apart enough to really tell, but I don't fault gcc for not warning
about it. But I like to know if gcc doesn't warn without this patch?
> --
> drivers/media/dvb-frontends/mn88473.c: In function 'mn88473_set_frontend':
> >> drivers/media/dvb-frontends/mn88473.c:162:7: warning: 'conf_val_ptr' may be used uninitialized in this function [-Wmaybe-uninitialized]
> ret = regmap_bulk_write(dev->regmap[1], 0x10, conf_val_ptr, 6);
> ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Same as the one before it. Need to see if this isn't really a real
issue.
> --
> net//netfilter/ipvs/ip_vs_sync.c: In function 'ip_vs_sync_conn':
> >> net//netfilter/ipvs/ip_vs_sync.c:731:13: warning: 'm' may be used uninitialized in this function [-Wmaybe-uninitialized]
> m->nr_conns++;
> ~~~~~~~~~~~^~
gcc is really stupid on this one.
if (buff)
init m;
if (!buff)
init m;
use m;
Really?
> --
> drivers//hwspinlock/hwspinlock_core.c: In function 'of_hwspin_lock_get_id':
> >> drivers//hwspinlock/hwspinlock_core.c:339:19: warning: 'id' may be used uninitialized in this function [-Wmaybe-uninitialized]
> return ret ? ret : id;
> ~~~~~~~~~~^~~~
Again, we jump here without initializing 'id' when ret is set.
> --
> drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c: In function 'mlxsw_sp_nexthop_group_update':
> >> drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3078:7: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized]
> if (err)
> ^
>
> vim +/ra_comp +1413 drivers//usb/typec/fusb302/fusb302.c
>
Another switch statement false positive:
nh->type can only be set to two different values, and then we
have:
switch (nh->type) {
case value1:
err = func();
break;
case value2:
err = func2();
break;
}
if (err)
Of all the warnings, only one looks like it could be a possible issue.
Thus, this patch causes gcc to fail more on it analysis. The one
possible issue should have been caught by gcc without this patch, so
I'm skeptical that it is indeed an issue, but it's complex and I am
impressed if gcc really did figure it out.
-- Steve