aboutsummaryrefslogtreecommitdiff
path: root/scripts
AgeCommit message (Collapse)AuthorFilesLines
2016-11-29kbuild: improve linker compatibility with lib-ksyms.o buildNicholas Piggin1-1/+1
lib-ksyms.o is created by linking an empty input file with a linker script containing the interesting bits. Currently the empty input file is an archive containing nothing, however this causes the gold linker to segfault. I have opened a bug against gold https://sourceware.org/bugzilla/show_bug.cgi?id=20767 However this can be worked around by assembling an empty file to link with instead. The resulting lib-ksyms.o is slightly larger (seemingly due to empty .text, .data, .bss setions added), but final linked output should not be changed. Reported-by: Anton Blanchard <[email protected]> Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michal Marek <[email protected]>
2016-11-29genksyms: Regenerate parserMichal Marek3-381/+387
Regenerate the keyword table and parser after commit 0efdb2282343 ("kbuild/genksyms: handle va_list type"). Signed-off-by: Michal Marek <[email protected]>
2016-11-29kbuild/genksyms: handle va_list typeNicholas Piggin2-0/+3
genksyms currently does not handle va_list. Add the __builtin_va_list keyword as a type. This reduces the amount of syntax errors thrown, but so far no export symbol has a type with a va_list argument, so there is currently no bug in the end result. Note: this patch does not regenerate shipped parser files. Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michal Marek <[email protected]>
2016-11-29kbuild: thin archives for multi-y targetsNicholas Piggin1-3/+10
THIN_ARCHIVES builds archives for built-in.o targets, have it build multi-y targets as archives as well. This saves another ~15% of the size of intermediate artifacts in the build tree. After this patch, the linker is only used in final link, and special cases like vdsos. Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michal Marek <[email protected]>
2016-11-29kbuild: kallsyms allow 3-pass generation if symbols size has changedNicholas Piggin1-6/+13
kallsyms generation is not foolproof, due to some linkers adding symbols (e.g., branch trampolines) when a binary size changes. Have it attempt a 3rd pass automatically if the kallsyms size changes in the 2nd pass. This allows powerpc64 allyesconfig to build without adding another pass when it's not required. This can be solved other ways by directing the linker not to add labels on branch stubs, or to move kallsyms near the end of the image. The former is undesirable for debugging/tracing, and the latter is a more significant change that requires more testing and review. Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michal Marek <[email protected]>
2016-11-29scripts/decode_stacktrace.sh: Fix address line detection on x86Josh Poimboeuf1-1/+2
Kirill reported that the decode_stacktrace.sh script was broken by the following commit: bb5e5ce545f2 ("x86/dumpstack: Remove kernel text addresses from stack dump") Fix it by updating the per-line absolute address check to also check for function-based address lines like the following: write_sysrq_trigger+0x51/0x60 I didn't remove the check for absolute addresses because it's still needed for ARM. Reported-by: Kirill A. Shutemov <[email protected]> Tested-by: Kirill A. Shutemov <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Cc: Konstantin Khlebnikov <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Sasha Levin <[email protected]> Cc: Thomas Gleixner <[email protected]> Fixes: bb5e5ce545f2 ("x86/dumpstack: Remove kernel text addresses from stack dump") Link: http://lkml.kernel.org/r/20161128230635.4n2ofgawltgexgcg@treble Signed-off-by: Ingo Molnar <[email protected]>
2016-11-29Scripts: kconfig: nconf: fix _GNU_SOURCE redefined warningCheah Kok Cheong1-0/+2
Fix below warning when make nconfig is run initially or after make clean. HOSTCC scripts/kconfig/nconf.o scripts/kconfig/nconf.c:8:0: warning: "_GNU_SOURCE" redefined #define _GNU_SOURCE ^ <command-line>:0:0: note: this is the location of the previous definition Signed-off-by: Cheah Kok Cheong <[email protected]> Signed-off-by: Michal Marek <[email protected]>
2016-11-26modpost: free allocated memoryHeinrich Schuchardt1-0/+2
valgrind complains that memory is not freed after allocation with realloc() called from main() and write_dump(). So let us free the allocated memory properly. Signed-off-by: Heinrich Schuchardt <[email protected]> Signed-off-by: Rusty Russell <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Jessica Yu <[email protected]>
2016-11-25builddeb: fix cross-building to arm64 producing host-arch debsAdam Borowski1-1/+1
Both Debian and kernel archs are "arm64" but UTS_MACHINE and gcc say "aarch64". Recognizing just the latter should be enough but let's accept both in case something regresses again or an user sets UTS_MACHINE=arm64. Regressed in cfa88c7: arm64: Set UTS_MACHINE in the Makefile. Signed-off-by: Adam Borowski <[email protected]> Acked-by: Riku Voipio <[email protected]> Signed-off-by: Michal Marek <[email protected]>
2016-11-22Merge branch 'linus' into locking/core, to pick up fixesIngo Molnar5-7/+84
Signed-off-by: Ingo Molnar <[email protected]>
2016-11-18Merge branch 'rc-fixes' of ↵Linus Torvalds2-7/+76
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild Pull kbuild fixes from Michal Marek: "Here are some regression fixes for kbuild: - modversion support for exported asm symbols (Nick Piggin). The affected architectures need separate patches adding asm-prototypes.h. - fix rebuilds of lib-ksyms.o (Nick Piggin) - -fno-PIE builds (Sebastian Siewior and Borislav Petkov). This is not a kernel regression, but one of the Debian gcc package. Nevertheless, it's quite annoying, so I think it should go into mainline and stable now" * 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild: kbuild: Steal gcc's pie from the very beginning kbuild: be more careful about matching preprocessed asm ___EXPORT_SYMBOL x86/kexec: add -fno-PIE scripts/has-stack-protector: add -fno-PIE kbuild: add -fno-PIE kbuild: modversions for EXPORT_SYMBOL() for asm kbuild: prevent lib-ksyms.o rebuilds
2016-11-18Merge tag 'v4.9-rc4' into soundJonathan Corbet4-17/+17
Bring in -rc4 patches so I can successfully merge the sound doc changes.
2016-11-17Merge branch 'x86/cpufeature' into x86/asm, to pick up dependencyIngo Molnar7-17/+25
Signed-off-by: Ingo Molnar <[email protected]>
2016-11-16kernel-doc: add support for one line inline struct member doc commentsJani Nikula1-1/+11
kernel-doc supports documenting struct members "inline" since a4c6ebede2f9 ("scripts/kernel-doc Allow struct arguments documentation in struct body"). This requires the inline kernel-doc comments to have the opening and closing comment markers (/** and */ respectively) on lines of their own, even for short comments. For example: /** * struct foo - struct documentation */ struct foo { /** * @bar: member documentation */ int bar; }; Add support for one line inline comments: /** * struct foo - struct documentation */ struct foo { /** @bar: member documentation */ int bar; }; Note that mixing of the two in one doc comment is not allowed; either both comment markers must be on lines of their own, or both must be on the one line. This limitation keeps both the comments more uniform, and kernel-doc less complicated. Cc: Daniel Vetter <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Jonathan Corbet <[email protected]>
2016-11-16Kconfig: Regenerate *.c_shipped files after previous changesNicolas Pitre2-858/+753
Signed-off-by: Nicolas Pitre <[email protected]> Cc: Paul Bolle <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Richard Cochran <[email protected]> Cc: Josh Triplett <[email protected]> Cc: Michal Marek <[email protected]> Cc: John Stultz <[email protected]> Cc: Edward Cree <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2016-11-16Kconfig: Introduce the "imply" keywordNicolas Pitre5-19/+79
The "imply" keyword is a weak version of "select" where the target config symbol can still be turned off, avoiding those pitfalls that come with the "select" keyword. This is useful e.g. with multiple drivers that want to indicate their ability to hook into a secondary subsystem while allowing the user to configure that subsystem out without also having to unset these drivers. Currently, the same effect can almost be achieved with: config DRIVER_A tristate config DRIVER_B tristate config DRIVER_C tristate config DRIVER_D tristate [...] config SUBSYSTEM_X tristate default DRIVER_A || DRIVER_B || DRIVER_C || DRIVER_D || [...] This is unwieldy to maintain especially with a large number of drivers. Furthermore, there is no easy way to restrict the choice for SUBSYSTEM_X to y or n, excluding m, when some drivers are built-in. The "select" keyword allows for excluding m, but it excludes n as well. Hence this "imply" keyword. The above becomes: config DRIVER_A tristate imply SUBSYSTEM_X config DRIVER_B tristate imply SUBSYSTEM_X [...] config SUBSYSTEM_X tristate This is much cleaner, and way more flexible than "select". SUBSYSTEM_X can still be configured out, and it can be set as a module when none of the drivers are configured in or all of them are modular. Signed-off-by: Nicolas Pitre <[email protected]> Acked-by: Richard Cochran <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Acked-by: John Stultz <[email protected]> Reviewed-by: Josh Triplett <[email protected]> Cc: Paul Bolle <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Michal Marek <[email protected]> Cc: Edward Cree <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2016-11-15locking/mutex, drm: Introduce mutex_trylock_recursive()Peter Zijlstra1-0/+6
By popular DRM demand, introduce mutex_trylock_recursive() to fix up the two GEM users. Without this it is very easy for these drivers to get stuck in low-memory situations and trigger OOM. Work is in progress to remove the need for this in at least i915. Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: David Airlie <[email protected]> Cc: Davidlohr Bueso <[email protected]> Cc: Ding Tianhong <[email protected]> Cc: Imre Deak <[email protected]> Cc: Jason Low <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Paul E. McKenney <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Rob Clark <[email protected]> Cc: Terry Rudd <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Tim Chen <[email protected]> Cc: Will Deacon <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-11-14recordmcount: arm: Implement make_nopStephen Boyd1-0/+65
In similar spirit to x86 and arm64 support, add a make_nop_arm() to replace calls to mcount with a nop in sections that aren't traced. Link: http://lkml.kernel.org/r/[email protected] Acked-by: Russell King <[email protected]> Acked-by: Rabin Vincent <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Steven Rostedt <[email protected]>
2016-11-14Merge 4.9-rc5 into char-misc-nextGreg Kroah-Hartman7-17/+25
We want those fixes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2016-11-14powerpc: Build-time sort the exception tableNicholas Piggin1-0/+2
Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2016-11-11Merge branch 'maybe-uninitialized' (patches from Arnd)Linus Torvalds2-0/+5
Merge fixes for -Wmaybe-uninitialized from Arnd Bergmann: "It took a while for some patches to make it into mainline through maintainer trees, but the 28-patch series is now reduced to 10, with one tiny patch added at the end. Aside from patches that are no longer required, I did these changes compared to version 1: - Dropped "iio: maxim_thermocouple: detect invalid storage size in read()", which is currently in linux-next as commit 32cb7d27e65d. This is the only remaining warning I see for a couple of corner cases (kbuild bot reports it on blackfin, kernelci bot and arm-soc bot both report it on arm64) - Dropped "brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap", which is currently in net/master merge pending. - Dropped two x86 patches, "x86: math-emu: possible uninitialized variable use" and "x86: mark target address as output in 'insb' asm" as they do not seem to trigger for a default build, and I got no feedback on them. Both of these are ancient issues and seem harmless, I will send them again to the x86 maintainers once the rest is merged. - Dropped "rbd: false-postive gcc-4.9 -Wmaybe-uninitialized" based on feedback from Ilya Dryomov, who already has a different fix queued up for v4.10. The kbuild bot reports this as a warning for xtensa. - Replaced "crypto: aesni: avoid -Wmaybe-uninitialized warning" with a simpler patch, this one always triggers but my first solution would not be safe for linux-4.9 any more at this point. I'll follow up with the larger patch as a cleanup for 4.10. - Replaced "dib0700: fix nec repeat handling" with a better one, contributed by Sean Young" * -Wmaybe-uninitialized fixes: Kbuild: enable -Wmaybe-uninitialized warnings by default pcmcia: fix return value of soc_pcmcia_regulator_set infiniband: shut up a maybe-uninitialized warning crypto: aesni: shut up -Wmaybe-uninitialized warning rc: print correct variable for z8f0811 dib0700: fix nec repeat handling s390: pci: don't print uninitialized data for debugging nios2: fix timer initcall return value x86: apm: avoid uninitialized data NFSv4.1: work around -Wmaybe-uninitialized warning Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"
2016-11-11Kbuild: enable -Wmaybe-uninitialized warnings by defaultArnd Bergmann1-2/+0
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 <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-11-11Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"Arnd Bergmann2-0/+7
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 <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-11-11scripts/bloat-o-meter: fix SIGPIPEAlexey Dobriyan1-0/+3
Fix piping output to a program which quickly exits (read: head -n1) $ ./scripts/bloat-o-meter ../vmlinux-000 ../obj/vmlinux | head -n1 add/remove: 0/0 grow/shrink: 9/60 up/down: 124/-305 (-181) close failed in file object destructor: sys.excepthook is missing lost sys.stderr Link: http://lkml.kernel.org/r/20161028204618.GA29923@avx2 Signed-off-by: Alexey Dobriyan <[email protected]> Cc: Matt Mackall <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-11-09kbuild: be more careful about matching preprocessed asm ___EXPORT_SYMBOLNicholas Piggin1-2/+2
The CRC code for asm exports grabs the preprocessed asm, finds the ___EXPORT_SYMBOL and turns those into EXPORT_SYMBOL in a C program that can be preprocessed and parsed to create the CRC signatures from the type. The existing regex matching and replacement is too strict, and doesn't deal well with whitespace among other things. The line " EXPORT_SYMBOL(sym)" in a .S file would not match due to initial whitespace, for example, which resulted in x86's ___preempt_schedule failing to get CRCs. Reported-by: Philip Müller <[email protected]> Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michal Marek <[email protected]>
2016-11-09scripts/has-stack-protector: add -fno-PIESebastian Andrzej Siewior1-1/+1
Adding -no-PIE to the fstack protector check. -no-PIE was introduced before -fstack-protector so there is no need for a runtime check. Without it the build stops: |Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong available but compiler is broken due to -mcmodel=kernel + -fPIE if -fPIE is enabled by default. Tagging it stable so it is possible to compile recent stable kernels as well. Cc: [email protected] Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Michal Marek <[email protected]>
2016-11-01kbuild: modversions for EXPORT_SYMBOL() for asmNicholas Piggin1-6/+72
Allow architectures to create asm/asm-prototypes.h file that provides C prototypes for exported asm functions, which enables proper CRC versions to be generated for them. Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michal Marek <[email protected]>
2016-10-31latent_entropy: Fix wrong gcc code generation with 64 bit variablesKees Cook1-10/+9
The stack frame size could grow too large when the plugin used long long on 32-bit architectures when the given function had too many basic blocks. The gcc warning was: drivers/pci/hotplug/ibmphp_ebda.c: In function 'ibmphp_access_ebda': drivers/pci/hotplug/ibmphp_ebda.c:409:1: warning: the frame size of 1108 bytes is larger than 1024 bytes [-Wframe-larger-than=] This switches latent_entropy from u64 to unsigned long. Thanks to PaX Team and Emese Revfy for the patch. Signed-off-by: Kees Cook <[email protected]>
2016-10-31gcc-plugins: Export symbols needed by gccKees Cook4-7/+8
This explicitly exports symbols that gcc expects from plugins. Based on code from Emese Revfy. Signed-off-by: Kees Cook <[email protected]>
2016-10-28kernel-doc: better parsing of named variable argumentsSilvio Fricke1-2/+6
Without this patch we get warnings for named variable arguments. warning: No description found for parameter '...' warning: Excess function parameter 'args' description in 'alloc_ordered_workqueue' Signed-off-by: Silvio Fricke <[email protected]> Reviewed-by: Jani Nikula <[email protected] Signed-off-by: Jonathan Corbet <[email protected]>
2016-10-28checkkconfigsymbols.py: support git's "^" syntaxValentin Rothberg1-1/+1
Support git's "^" syntax for diffing two commits, for instance via "--diff HEAD^^^..HEAD". Signed-off-by: Michael Ellermann <[email protected]> Signed-off-by: Valentin Rothberg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2016-10-25scripts/faddr2line: Fix "size mismatch" errorJosh Poimboeuf1-12/+21
I'm not sure how we missed this problem before. When I take a function address and size from an oops and give it to faddr2line, it usually complains about a size mismatch: $ scripts/faddr2line ~/k/vmlinux write_sysrq_trigger+0x51/0x60 skipping write_sysrq_trigger address at 0xffffffff815731a1 due to size mismatch (0x60 != 83) no match for write_sysrq_trigger+0x51/0x60 The problem is caused by differences in how kallsyms and faddr2line determine a function's size. kallsyms calculates a function's size by parsing the output of 'nm -n' and subtracting the next function's address from the current function's address. This means that nop instructions after the end of the function are included in the size. In contrast, faddr2line reads the size from the symbol table, which does *not* include the ending nops in the function's size. Change faddr2line to calculate the size from the output of 'nm -n' to be consistent with kallsyms and oops outputs. Signed-off-by: Josh Poimboeuf <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/bd313ed7c4003f6b1fda63e825325c44a9d837de.1477405374.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <[email protected]>
2016-10-24docs: fix locations of several documents that got movedMauro Carvalho Chehab1-3/+3
The previous patch renamed several files that are cross-referenced along the Kernel documentation. Adjust the links to point to the right places. Signed-off-by: Mauro Carvalho Chehab <[email protected]>
2016-10-22kbuild: prevent lib-ksyms.o rebuildsNicholas Piggin1-0/+3
Signed-off-by: Nicholas Piggin <[email protected]> Reported-by: Russell King <[email protected]> Tested-by: Russell King <[email protected]> Signed-off-by: Michal Marek <[email protected]>
2016-10-15Merge tag 'gcc-plugins-v4.9-rc1' of ↵Linus Torvalds2-1/+648
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull gcc plugins update from Kees Cook: "This adds a new gcc plugin named "latent_entropy". It is designed to extract as much possible uncertainty from a running system at boot time as possible, hoping to capitalize on any possible variation in CPU operation (due to runtime data differences, hardware differences, SMP ordering, thermal timing variation, cache behavior, etc). At the very least, this plugin is a much more comprehensive example for how to manipulate kernel code using the gcc plugin internals" * tag 'gcc-plugins-v4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: latent_entropy: Mark functions with __latent_entropy gcc-plugins: Add latent_entropy plugin
2016-10-14Merge branch 'misc' of ↵Linus Torvalds4-12/+80
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild Pull misc kbuild changes from Michal Marek: "Just a few patches on the kbuild.git#misc branch this time: - New Coccinelle patch by Nicholas Mc Guire - Existing patch fixes by Julia Lawall - Minor comment fix by Markus Elfring" * 'misc' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild: Coccinelle: flag conditions with no effect scripts/coccicheck: Update reference for the corresponding documentation Coccinelle: pm_runtime: ensure relevance of pm_runtime reports Coccinelle: limit memdup_user transformation to GFP_KERNEL case
2016-10-14Merge branch 'kbuild' of ↵Linus Torvalds7-115/+174
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild Pull kbuild updates from Michal Marek: - EXPORT_SYMBOL for asm source by Al Viro. This does bring a regression, because genksyms no longer generates checksums for these symbols (CONFIG_MODVERSIONS). Nick Piggin is working on a patch to fix this. Plus, we are talking about functions like strcpy(), which rarely change prototypes. - Fixes for PPC fallout of the above by Stephen Rothwell and Nick Piggin - fixdep speedup by Alexey Dobriyan. - preparatory work by Nick Piggin to allow architectures to build with -ffunction-sections, -fdata-sections and --gc-sections - CONFIG_THIN_ARCHIVES support by Stephen Rothwell - fix for filenames with colons in the initramfs source by me. * 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild: (22 commits) initramfs: Escape colons in depfile ppc: there is no clear_pages to export powerpc/64: whitelist unresolved modversions CRCs kbuild: -ffunction-sections fix for archs with conflicting sections kbuild: add arch specific post-link Makefile kbuild: allow archs to select link dead code/data elimination kbuild: allow architectures to use thin archives instead of ld -r kbuild: Regenerate genksyms lexer kbuild: genksyms fix for typeof handling fixdep: faster CONFIG_ search ia64: move exports to definitions sparc32: debride memcpy.S a bit [sparc] unify 32bit and 64bit string.h sparc: move exports to definitions ppc: move exports to definitions arm: move exports to definitions s390: move exports to definitions m68k: move exports to definitions alpha: move exports to actual definitions x86: move exports to actual definitions ...
2016-10-11scripts/tags.sh: enable code completion in VIMMathieu Maret1-1/+2
Vim, with the omnicppcomplete(#1) plugin, can do code completion using information build by ctags. Add flags needed by omnicppcomplete(#2) to have completion on member of structure. 1: https://github.com/vim-scripts/omnicppcomplete 2: https://github.com/vim-scripts/OmniCppComplete/blob/master/doc/omnicppcomplete.txt#L93 Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Mathieu Maret <[email protected]> Cc: Michal Marek <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-10-11checkpatch: improve the octal permissions testsJoe Perches1-16/+44
The function calls with octal permissions commonly span multiple lines. The current test is line oriented and fails to find some matches. Make the test use the $stat variable instead of the $line variable to span multiple lines. Also add a few functions to the known functions with permissions list. Move the SYMBOLIC_PERMS test to a separate section to find all the S_<FOO> permissions in any form not just those that have specific function names. This can now find and fix permissions uses like: .mode = S_<FOO> | S_<BAR>; Link: http://lkml.kernel.org/r/b51bab60530912aae4ac420119d465c5b206f19f.1475030406.git.joe@perches.com Signed-off-by: Joe Perches <[email protected]> Tested-by: Ramiro Oliveira <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-10-11checkpatch: add warning for unnamed function definition argumentsJoe Perches1-0/+13
Function definitions without identifiers like int foo(int) are not preferred. Emit a warning when they occur. Link: http://lkml.kernel.org/r/94fe6378504745991b650f48fc92bb4648f25706.1474925354.git.joe@perches.com Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-10-11checkpatch: improve MACRO_ARG_PRECEDENCE testJoe Perches1-1/+19
It is possible for a multiple line macro definition to have a false positive report when an argument is used on a line after a continuation \. This line might have a leading '+' as the initial character that could be confused by checkpatch as an operator. Avoid the leading character on multiple line macro definitions. Link: http://lkml.kernel.org/r/60229d13399f9b6509db5a32e30d4c16951a60cd.1473836073.git.joe@perches.com Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-10-11checkpatch: add --strict test for precedence challenged macro argumentsJoe Perches1-1/+8
Add a test for macro arguents that have a non-comma leading or trailing operator where the argument isn't parenthesized to avoid possible precedence issues. Link: http://lkml.kernel.org/r/47715508972f8d786f435e583ff881dbeee3a114.1473745855.git.joe@perches.com Signed-off-by: Joe Perches <[email protected]> Cc: Andy Whitcroft <[email protected]> Cc: Julia Lawall <[email protected]> Cc: Dan Carpenter <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-10-11checkpatch: add --strict test for macro argument reuseJoe Perches1-8/+35
If a macro argument is used multiple times in the macro definition, the macro argument may have an unexpected side-effect. Add a test (MACRO_ARG_REUSE) for that condition which is only emitted with command-line option --strict. Link: http://lkml.kernel.org/r/b6d67a87cafcafd15499e91780dc63b15dec0aa0.1473744906.git.joe@perches.com Signed-off-by: Joe Perches <[email protected]> Cc: Andy Whitcroft <[email protected]> Cc: Julia Lawall <[email protected]> Cc: Dan Carpenter <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-10-11checkpatch: improve the block comment * alignment testJoe Perches1-7/+12
An "uninitialized value" is emitted when a block comment starts on the same line as a statement. Fix this and make the test use a little fewer cpu cycles too. Link: http://lkml.kernel.org/r/3c9993320c2182d37f53ac540878cfef59c3f62d.1473365956.git.joe@perches.com Signed-off-by: Joe Perches <[email protected]> Reported-by: Charlemagne Lasse <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-10-11checkpatch: speed up checking for filenames in sections marked obsoleteJoe Perches1-1/+1
Adding -f to the get_maintainer.pl invocation means git isn't invoked by get_maintainer.pl for known filenames. This reduces the overall time to run checkpatch. Link: http://lkml.kernel.org/r/22991e3a295aeb399b43af0478b6e5809106ccee.1472684066.git.joe@perches.com Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-10-11const_structs.checkpatch: add frequently used from Julia Lawall's listJoe Perches1-0/+25
Using const is generally a good idea. Julia Lawall has created a list of always const and almost always const structs in the kernel sources. Link: https://lkml.org/lkml/2016/8/28/95 Add the most frequently used (> 50 cases) that are almost always or always const. Link: http://lkml.kernel.org/r/1e16020f8027654db0095bbfbcc11da51025365c.1472664220.git.joe@perches.com Signed-off-by: Joe Perches <[email protected]> Acked-by: Kees Cook <[email protected]> Cc: Julia Lawall <[email protected]> Cc: Andy Whitcroft <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-10-11checkpatch: externalize the structs that should be constJoe Perches2-40/+63
Make it easier to add new structs that should be const. Link: http://lkml.kernel.org/r/e5a8da43e7c11525bafbda1ca69a8323614dd942.1472664220.git.joe@perches.com Signed-off-by: Joe Perches <[email protected]> Cc: Julia Lawall <[email protected]> Cc: Kees Cook <[email protected]> Cc: Andy Whitcroft <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-10-11checkpatch: don't test for prefer ether_addr_<foo>Joe Perches1-35/+35
< sigh > Comment these tests out. These are just too enticing to people that don't verify that both source and dest addresses really must be __aligned(2). It helps make Dan Carpenter happy too. Link: http://lkml.kernel.org/r/dc32ec66d24647f4cdf824c8dfbbc59aa7ce7b7d.1472665676.git.joe@perches.com Signed-off-by: Joe Perches <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: Greg <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-10-11checkpatch: test multiple line block comment alignmentJoe Perches1-0/+19
Warn when block comments are not aligned on the * /* * block comment, no warning */ /* * block comment, emit warning */ Link: http://lkml.kernel.org/r/edb57bd330adfe024b95ec2a807d4aa7f0c8b112.1472261299.git.joe@perches.com Signed-off-by: Joe Perches <[email protected]> Reported-by: Sudip Mukherjee <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-10-11checkpatch: look for symbolic permissions and suggest octal insteadJoe Perches1-6/+43
S_<FOO> uses should be avoided where octal is more intelligible. Linus didst say: : It's *much* easier to parse and understand the octal numbers, while the : symbolic macro names are just random line noise and hard as hell to : understand. You really have to think about it. : : So we should rather go the other way: convert existing bad symbolic : permission bit macro use to just use the octal numbers. : : The symbolic names are good for the *other* bits (ie sticky bit, and the : inode mode _type_ numbers etc), but for the permission bits, the symbolic : names are just insane crap. Nobody sane should ever use them. Not in the : kernel, not in user space. (http://lkml.kernel.org/r/CA+55aFw5v23T-zvDZp-MmD_EYxF8WbafwwB59934FV7g21uMGQ@mail.gmail.com) Link: http://lkml.kernel.org/r/7232ef011d05a92f4caa86a5e9830d87966a2eaf.1470180926.git.joe@perches.com Signed-off-by: Joe Perches <[email protected]> Cc: Linus Torvalds <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>