08 Dec, 2018
1 commit
-
commit 321cb0308a9e76841394b4bbab6a1107cfedbae0 upstream.
gcc-8 reports many -Wpacked-not-aligned warnings. The below are some
examples../include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
} __attribute__ ((packed));./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
} __attribute__ ((packed));./include/linux/ceph/msgr.h:67:1: warning: alignment 1 of 'struct
ceph_entity_addr' is less than 8 [-Wpacked-not-aligned]
} __attribute__ ((packed));This patch suppresses this kind of warnings for default setting.
Signed-off-by: Xiongfeng Wang
Signed-off-by: Masahiro Yamada
Signed-off-by: Greg Kroah-Hartman
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
01 Sep, 2017
1 commit
-
We have lots of dead defines and macros in drivers, lets offer users a way
to detect and eventually remove them.Signed-off-by: Johannes Thumshirn
Signed-off-by: Masahiro Yamada
23 Apr, 2017
1 commit
-
Since commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to
cc-option to support clang"), cc-option and friends work nicely
for clang.However, -Wno-unknown-warning-option makes clang happy with any
unknown warning options even if -Werror is specified.Once -Wno-unknown-warning-option is added, any succeeding call of
cc-disable-warning is evaluated positive, then unknown warning
options are accepted. This should be dropped.Signed-off-by: Masahiro Yamada
12 Nov, 2016
2 commits
-
Previously the warnings were added back at the W=1 level and above, this
now turns them on again by default, assuming that we have addressed all
warnings and again have a clean build for v4.10.I found a number of new warnings in linux-next already and submitted
bugfixes for those. Hopefully they are caught by the 0day builder in
the future as soon as this patch is merged.Signed-off-by: Arnd Bergmann
Signed-off-by: Linus Torvalds -
Traditionally, we have always had warnings about uninitialized variables
enabled, as this is part of -Wall, and generally a good idea [1], but it
also always produced false positives, mainly because this is a variation
of the halting problem and provably impossible to get right in all cases
[2].Various people have identified cases that are particularly bad for false
positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized
when building with -Os"), I turned off the warning for any build that
was done with CC_OPTIMIZE_FOR_SIZE. This drastically reduced the number
of false positive warnings in the default build but unfortunately had
the side effect of turning the warning off completely in 'allmodconfig'
builds, which in turn led to a lot of warnings (both actual bugs, and
remaining false positives) to go in unnoticed.With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
definition") enabled the warning again for allmodconfig builds in v4.7
and in v4.8-rc1, I had finally managed to address all warnings I get in
an ARM allmodconfig build and most other maybe-uninitialized warnings
for ARM randconfig builds.However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning
globally") was merged at the same time and disabled it completely for
all configurations, because of false-positive warnings on x86 that I had
not addressed until then. This caused a lot of actual bugs to get
merged into mainline, and I sent several dozen patches for these during
the v4.9 development cycle. Most of these are actual bugs, some are for
correct code that is safe because it is only called under external
constraints that make it impossible to run into the case that gcc sees,
and in a few cases gcc is just stupid and finds something that can
obviously never happen.I have now done a few thousand randconfig builds on x86 and collected
all patches that I needed to address every single warning I got (I can
provide the combined patch for the other warnings if anyone is
interested), so I hope we can get the warning back and let people catch
the actual bugs earlier.This reverts the change to disable the warning completely and for now
brings it back at the "make W=1" level, so we can get it merged into
mainline without introducing false positives. A follow-up patch enables
it on all levels unless some configuration option turns it off because
of false-positives.Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann
Signed-off-by: Linus Torvalds
11 May, 2016
1 commit
-
gcc-6 started warning by default about variables that are not
used anywhere and that are marked 'const', generating many
false positives in an allmodconfig build, e.g.:arch/arm/mach-davinci/board-da830-evm.c:282:20: warning: 'da830_evm_emif25_pins' defined but not used [-Wunused-const-variable=]
arch/arm/plat-omap/dmtimer.c:958:34: warning: 'omap_timer_match' defined but not used [-Wunused-const-variable=]
drivers/bluetooth/hci_bcm.c:625:39: warning: 'acpi_bcm_default_gpios' defined but not used [-Wunused-const-variable=]
drivers/char/hw_random/omap-rng.c:92:18: warning: 'reg_map_omap4' defined but not used [-Wunused-const-variable=]
drivers/devfreq/exynos/exynos5_bus.c:381:32: warning: 'exynos5_busfreq_int_pm' defined but not used [-Wunused-const-variable=]
drivers/dma/mv_xor.c:1139:34: warning: 'mv_xor_dt_ids' defined but not used [-Wunused-const-variable=]This is similar to the existing -Wunused-but-set-variable warning
that was added in an earlier release and that we disable by default
now and only enable when W=1 is set, so it makes sense to do
the same here. Once we have eliminated the majority of the
warnings for both, we can put them back into the default list.We probably want this in backport kernels as well, to allow building
them with gcc-6 without introducing extra warnings.Signed-off-by: Arnd Bergmann
Acked-by: Olof Johansson
Acked-by: Lee Jones
Cc: stable@vger.kernel.org
Signed-off-by: Michal Marek
12 Jan, 2016
1 commit
-
Ideally, a kernel compile with W=1 enabled should complete cleanly;
however, when we run one currently we are presented with ~25k warnings.
'sign-compare' accounts for ~22k of those ~25k.In this patch we're demoting 'sign-compare' warnings to W=2, with a view
to fixing the remaining 3k W=1 warnings required for a clean build.Arnd adds:
"As per our discussion, I'd add that this was inadvertedly introduced
by Behan when he moved the clang specific warnings into an ifdef block
and did not notice that -Wsign-compare was interpreted by both gcc
and clang.Earlier, it was introduced in just the same way by Jan-Simon as part
of 3d3d6b847420 ("kbuild: LLVMLinux: Adapt warnings for compilation
with clang")."Acked-by: Arnd Bergmann
Fixes: 26ea6bb1fef0 ("kbuild, LLVMLinux: Supress warnings unless W=1-3")
Signed-off-by: Lee Jones
Signed-off-by: Michal Marek
04 Sep, 2015
1 commit
-
We cannot detect clang before including the arch Makefile, because that
can set the default cross compiler. We also cannot detect clang after
including the arch Makefile, because powerpc wants to know about clang.
Solve this by using an deferred variable. This costs us a few shell
invocations, but this is only a constant number.Reported-by: Behan Webster
Reported-by: Anton Blanchard
Signed-off-by: Michal Marek
05 Aug, 2014
1 commit
-
clang has more warnings enabled by default. Turn them off unless W is
set. This patch fixes a logic bug where warnings in clang were disabled
when W was set.Signed-off-by: Behan Webster
Signed-off-by: Jan-Simon Möller
Signed-off-by: Mark Charlebois
Cc: bp@alien8.de
Signed-off-by: Michal Marek
17 Apr, 2014
1 commit
-
W=... provides extra gcc checks.
Having such code in scripts/Makefile.build results in the same flags
being added to KBUILD_CFLAGS multiple times becuase
scripts/Makefile.build is invoked every time Kbuild descends into
the subdirectories.Since the top Makefile is already too cluttered, this commit moves
all of extra gcc check stuff to a new file scripts/Makefile.extrawarn,
which is included from the top Makefile.Signed-off-by: Masahiro Yamada
CC: Sam Ravnborg
Signed-off-by: Michal Marek
