aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2019-07-31parisc: Fix fall-through warnings in fpudispatch.cHelge Deller1-0/+1
In fpudispatch.c we see a lot of fall-through warnings, but for this file we prefer to not mark the switches and instead keep it in it's original state as it's copied from HP-UX. Fixes: a035d552a93b ("Makefile: Globally enable fall-through warning") Signed-off-by: Helge Deller <deller@gmx.de>
2019-07-31parisc: Mark expected switch fall-throughs in fault.cHelge Deller1-0/+1
Fix a fall-through warning in fault.c. Fixes: a035d552a93b ("Makefile: Globally enable fall-through warning") Signed-off-by: Helge Deller <deller@gmx.de>
2019-07-30exit: make setting exit_state consistentChristian Brauner1-2/+3
Since commit b191d6491be6 ("pidfd: fix a poll race when setting exit_state") we unconditionally set exit_state to EXIT_ZOMBIE before calling into do_notify_parent(). This was done to eliminate a race when querying exit_state in do_notify_pidfd(). Back then we decided to do the absolute minimal thing to fix this and not touch the rest of the exit_notify() function where exit_state is set. Since this fix has not caused any issues change the setting of exit_state to EXIT_DEAD in the autoreap case to account for the fact hat exit_state is set to EXIT_ZOMBIE unconditionally. This fix was planned but also explicitly requested in [1] and makes the whole code more consistent. /* References */ [1]: https://lore.kernel.org/lkml/CAHk-=wigcxGFR2szue4wavJtH5cYTTeNES=toUBVGsmX0rzX+g@mail.gmail.com Signed-off-by: Christian Brauner <christian@brauner.io> Acked-by: Oleg Nesterov <oleg@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org>
2019-07-29dax: Fix missed wakeup in put_unlocked_entry()Jan Kara1-1/+1
The condition checking whether put_unlocked_entry() needs to wake up following waiter got broken by commit 23c84eb78375 ("dax: Fix missed wakeup with PMD faults"). We need to wake the waiter whenever the passed entry is valid (i.e., non-NULL and not special conflict entry). This could lead to processes never being woken up when waiting for entry lock. Fix the condition. Cc: <stable@vger.kernel.org> Link: http://lore.kernel.org/r/20190729120228.GC17833@quack2.suse.cz Fixes: 23c84eb78375 ("dax: Fix missed wakeup with PMD faults") Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2019-07-29platform/x86: pcengines-apuv2: use KEY_RESTART for front buttonEnrico Weigelt1-1/+1
The keycode KEY_RESTART is more appropriate for the front button, as most people use it for things like restart or factory reset. Signed-off-by: Enrico Weigelt <info@metux.net> Fixes: f8eb0235f659 ("x86: pcengines apuv2 gpio/leds/keys platform driver") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-07-29pidfd: Add warning if exit_state is 0 during notificationJoel Fernandes (Google)1-0/+1
Previously a condition got missed where the pidfd waiters are awakened before the exit_state gets set. This can result in a missed notification [1] and the polling thread waiting forever. It is fixed now, however it would be nice to avoid this kind of issue going unnoticed in the future. So just add a warning to catch it in the future. /* References */ [1]: https://lore.kernel.org/lkml/20190717172100.261204-1-joel@joelfernandes.org/ Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org> Link: https://lore.kernel.org/r/20190724164816.201099-1-joel@joelfernandes.org Signed-off-by: Christian Brauner <christian@brauner.io>
2019-07-29pidfd: remove obsolete comments from testChristian Brauner1-5/+1
Since the introduction of CLONE_PIDFD pidfd_send_signal() is independent of CONFIG_PROC_FS. Signed-off-by: Christian Brauner <christian@brauner.io>
2019-07-28f2fs: use EINVAL for superblock with invalid magicIcenowy Zheng1-24/+24
The kernel mount_block_root() function expects -EACESS or -EINVAL for a unmountable filesystem when trying to mount the root with different filesystem types. However, in 5.3-rc1 the behavior when F2FS code cannot find valid block changed to return -EFSCORRUPTED(-EUCLEAN), and this error code makes mount_block_root() fail when trying to probe F2FS. When the magic number of the superblock mismatches, it has a high probability that it's just not a F2FS. In this case return -EINVAL seems to be a better result, and this return value can make mount_block_root() probing work again. Return -EINVAL when the superblock has magic mismatch, -EFSCORRUPTED in other cases (the magic matches but the superblock cannot be recognized). Fixes: 10f966bbf521 ("f2fs: use generic EFSBADCRC/EFSCORRUPTED") Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Reviewed-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2019-07-28Linux 5.3-rc2Linus Torvalds1-1/+1
2019-07-27kbuild: remove unused single-used-mMasahiro Yamada1-2/+0
This is unused since commit 9f69a496f100 ("kbuild: split out *.mod out of {single,multi}-used-m rules"). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-27gen_compile_commands: lower the entry count thresholdMasahiro Yamada1-2/+2
Running gen_compile_commands.py after building the kernel with allnoconfig gave this: $ ./scripts/gen_compile_commands.py WARNING: Found 449 entries. Have you compiled the kernel? Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-27.gitignore: Add compilation database fileToru Komatsu1-0/+3
This file is used by clangd to use language server protocol. It can be generated at each compile using scripts/gen_compile_commands.py. Therefore it is different depending on the environment and should be ignored. Signed-off-by: Toru Komatsu <k0ma@utam0k.jp> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-27kbuild: remove unused objectify macroMasahiro Yamada1-3/+0
Commit 415008af3219 ("docs-rst: convert lsm from DocBook to ReST") removed the last users of this macro. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-26f2fs: fix to read source block before invalidating itJaegeuk Kim1-36/+34
f2fs_allocate_data_block() invalidates old block address and enable new block address. Then, if we try to read old block by f2fs_submit_page_bio(), it will give WARN due to reading invalid blocks. Let's make the order sanely back. Reviewed-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2019-07-26dt-bindings: Fix more $id value mismatches filenamesRob Herring11-11/+11
The path in the schema '$id' values are wrong. Fix them. Signed-off-by: Rob Herring <robh@kernel.org>
2019-07-26dt-bindings: nvmem: SID: Fix the examples node namesMaxime Ripard1-2/+2
Now that the examples are validated, the examples in the SID binding generates an error since the node names aren't one of the valid ones. Let's switch for one that is ok. Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Rob Herring <robh@kernel.org>
2019-07-26dt-bindings: nvmem: Add YAML schemas for the generic NVMEM bindingsMaxime Ripard3-80/+139
The nvmem providers and consumers have a bunch of generic properties that are needed in a device tree. Add a YAML schemas for those. Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> [Srini: Changed licence to (GPL-2.0 OR BSD-2-Clause)] Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org>
2019-07-26of: Fix typo in kerneldocThierry Reding1-1/+1
"Findfrom" is not a word. Replace the function synopsis by something that makes sense. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Rob Herring <robh@kernel.org>
2019-07-26block: fix max segment size handling in blk_queue_virt_boundaryChristoph Hellwig1-1/+2
We should only set the max segment size to unlimited if we actually have a virt boundary. Otherwise we accidentally clear that limit when called from the SCSI midlayer, which always calls blk_queue_virt_boundary, even if that mask is 0. Fixes: 7ad388d8e4c7 ("scsi: core: add a host / host template field for the virt boundary") Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-07-26docs: phy: Drop duplicate 'be made'Guido Günther1-2/+2
Fix duplicate words. Signed-off-by: Guido Günther <agx@sigxcpu.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-07-26fix the struct mount leak in umount_tree()Al Viro1-2/+2
We need to drop everything we remove from the tree, whether mnt_has_parent() is true or not. Usually the bug manifests as a slow memory leak (leaked struct mount for initramfs); it becomes much more visible in mount_subtree() users, such as btrfs. There we leak a struct mount for btrfs superblock being mounted, which prevents fs shutdown on subsequent umount. Fixes: 56cbb429d911 ("switch the remnants of releasing the mountpoint away from fs_pin") Reported-by: Nikolay Borisov <nborisov@suse.com> Tested-by: Nikolay Borisov <nborisov@suse.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2019-07-26vhost: disable metadata prefetch optimizationMichael S. Tsirkin1-1/+1
This seems to cause guest and host memory corruption. Disable for now until we get a better handle on that. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-07-26MAINTAINERS: vfio-ccw: Remove myself as the maintainerFarhan Ali1-1/+0
I will not be able to continue with my maintainership responsibilities going forward, so remove myself as the maintainer. Signed-off-by: Farhan Ali <alifm@linux.ibm.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-26s390/mm: use shared variables for sysctl range checkVasily Gorbik1-4/+2
Since commit eec4844fae7c ("proc/sysctl: add shared variables for range check") special shared variables are available for sysctl range check. Reuse them for /proc/sys/vm/allocate_pgste proc handler. Acked-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-26virtio/s390: fix race on airq_areas[]Halil Pasic1-0/+4
The access to airq_areas was racy ever since the adapter interrupts got introduced to virtio-ccw, but since commit 39c7dcb15892 ("virtio/s390: make airq summary indicators DMA") this became an issue in practice as well. Namely before that commit the airq_info that got overwritten was still functional. After that commit however the two infos share a summary_indicator, which aggravates the situation. Which means auto-online mechanism occasionally hangs the boot with virtio_blk. Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Cc: stable@vger.kernel.org Fixes: 96b14536d935 ("virtio-ccw: virtio-ccw adapter interrupt support.") Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-26s390/dma: provide proper ARCH_ZONE_DMA_BITS valueHalil Pasic1-0/+2
On s390 ZONE_DMA is up to 2G, i.e. ARCH_ZONE_DMA_BITS should be 31 bits. The current value is 24 and makes __dma_direct_alloc_pages() take a wrong turn first (but __dma_direct_alloc_pages() recovers then). Let's correct ARCH_ZONE_DMA_BITS value and avoid wrong turns. Signed-off-by: Halil Pasic <pasic@linux.ibm.com> Reported-by: Petr Tesarik <ptesarik@suse.cz> Fixes: c61e9637340e ("dma-direct: add support for allocation from ZONE_DMA and ZONE_DMA32") Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-26btrfs: fix extent_state leak in btrfs_lock_and_flush_ordered_rangeNaohiro Aota1-5/+6
btrfs_lock_and_flush_ordered_range() loads given "*cached_state" into cachedp, which, in general, is NULL. Then, lock_extent_bits() updates "cachedp", but it never goes backs to the caller. Thus the caller still see its "cached_state" to be NULL and never free the state allocated under btrfs_lock_and_flush_ordered_range(). As a result, we will see massive state leak with e.g. fstests btrfs/005. Fix this bug by properly handling the pointers. Fixes: bd80d94efb83 ("btrfs: Always use a cached extent_state in btrfs_lock_and_flush_ordered_range") Reviewed-by: Nikolay Borisov <nborisov@suse.com> Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com> Signed-off-by: David Sterba <dsterba@suse.com>
2019-07-25Makefile: Globally enable fall-through warningGustavo A. R. Silva2-0/+17
Now that all the fall-through warnings have been addressed in the kernel, enable the fall-through warning globally. Also, update the deprecated.rst file to include implicit fall-through as 'deprecated' so people can be pointed to a single location for justification. Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Kees Cook <keescook@chromium.org> Cc: linux-kbuild@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-07-25drm/i915: Mark expected switch fall-throughsGustavo A. R. Silva6-4/+5
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/gpu/drm/i915/gem/i915_gem_mman.c: In function ‘i915_gem_fault’: drivers/gpu/drm/i915/gem/i915_gem_mman.c:342:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (!i915_terminally_wedged(i915)) ^ drivers/gpu/drm/i915/gem/i915_gem_mman.c:345:2: note: here case -EAGAIN: ^~~~ drivers/gpu/drm/i915/gem/i915_gem_pages.c: In function ‘i915_gem_object_map’: ./include/linux/compiler.h:78:22: warning: this statement may fall through [-Wimplicit-fallthrough=] # define unlikely(x) __builtin_expect(!!(x), 0) ^~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/asm-generic/bug.h:136:2: note: in expansion of macro ‘unlikely’ unlikely(__ret_warn_on); \ ^~~~~~~~ drivers/gpu/drm/i915/i915_utils.h:49:25: note: in expansion of macro ‘WARN’ #define MISSING_CASE(x) WARN(1, "Missing case (%s == %ld)\n", \ ^~~~ drivers/gpu/drm/i915/gem/i915_gem_pages.c:270:3: note: in expansion of macro ‘MISSING_CASE’ MISSING_CASE(type); ^~~~~~~~~~~~ drivers/gpu/drm/i915/gem/i915_gem_pages.c:272:2: note: here case I915_MAP_WB: ^~~~ drivers/gpu/drm/i915/i915_gpu_error.c: In function ‘error_record_engine_registers’: ./include/linux/compiler.h:78:22: warning: this statement may fall through [-Wimplicit-fallthrough=] # define unlikely(x) __builtin_expect(!!(x), 0) ^~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/asm-generic/bug.h:136:2: note: in expansion of macro ‘unlikely’ unlikely(__ret_warn_on); \ ^~~~~~~~ drivers/gpu/drm/i915/i915_utils.h:49:25: note: in expansion of macro ‘WARN’ #define MISSING_CASE(x) WARN(1, "Missing case (%s == %ld)\n", \ ^~~~ drivers/gpu/drm/i915/i915_gpu_error.c:1196:5: note: in expansion of macro ‘MISSING_CASE’ MISSING_CASE(engine->id); ^~~~~~~~~~~~ drivers/gpu/drm/i915/i915_gpu_error.c:1197:4: note: here case RCS0: ^~~~ drivers/gpu/drm/i915/display/intel_dp.c: In function ‘intel_dp_get_fia_supported_lane_count’: ./include/linux/compiler.h:78:22: warning: this statement may fall through [-Wimplicit-fallthrough=] # define unlikely(x) __builtin_expect(!!(x), 0) ^~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/asm-generic/bug.h:136:2: note: in expansion of macro ‘unlikely’ unlikely(__ret_warn_on); \ ^~~~~~~~ drivers/gpu/drm/i915/i915_utils.h:49:25: note: in expansion of macro ‘WARN’ #define MISSING_CASE(x) WARN(1, "Missing case (%s == %ld)\n", \ ^~~~ drivers/gpu/drm/i915/display/intel_dp.c:233:3: note: in expansion of macro ‘MISSING_CASE’ MISSING_CASE(lane_info); ^~~~~~~~~~~~ drivers/gpu/drm/i915/display/intel_dp.c:234:2: note: here case 1: ^~~~ drivers/gpu/drm/i915/display/intel_display.c: In function ‘check_digital_port_conflicts’: CC [M] drivers/gpu/drm/nouveau/nvkm/engine/disp/cursgv100.o drivers/gpu/drm/i915/display/intel_display.c:12043:7: warning: this statement may fall through [-Wimplicit-fallthrough=] if (WARN_ON(!HAS_DDI(to_i915(dev)))) ^ drivers/gpu/drm/i915/display/intel_display.c:12046:3: note: here case INTEL_OUTPUT_DP: ^~~~ Also, notice that the Makefile is modified to stop ignoring fall-through warnings. The -Wimplicit-fallthrough option will be enabled globally in v5.3. Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-07-25drm/amd/display: Mark expected switch fall-throughsGustavo A. R. Silva1-0/+5
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-07-25drm/amdkfd/kfd_mqd_manager_v10: Avoid fall-through warningGustavo A. R. Silva1-1/+0
In preparation to enabling -Wimplicit-fallthrough, this patch silences the following warning: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_mqd_manager_v10.c: In function ‘mqd_manager_init_v10’: ./include/linux/dynamic_debug.h:122:52: warning: this statement may fall through [-Wimplicit-fallthrough=] #define __dynamic_func_call(id, fmt, func, ...) do { \ ^ ./include/linux/dynamic_debug.h:143:2: note: in expansion of macro ‘__dynamic_func_call’ __dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__) ^~~~~~~~~~~~~~~~~~~ ./include/linux/dynamic_debug.h:153:2: note: in expansion of macro ‘_dynamic_func_call’ _dynamic_func_call(fmt, __dynamic_pr_debug, \ ^~~~~~~~~~~~~~~~~~ ./include/linux/printk.h:336:2: note: in expansion of macro ‘dynamic_pr_debug’ dynamic_pr_debug(fmt, ##__VA_ARGS__) ^~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_mqd_manager_v10.c:432:3: note: in expansion of macro ‘pr_debug’ pr_debug("%s@%i\n", __func__, __LINE__); ^~~~~~~~ drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_mqd_manager_v10.c:433:2: note: here case KFD_MQD_TYPE_COMPUTE: ^~~~ by removing the call to pr_debug() in KFD_MQD_TYPE_CP: "The mqd init for CP and COMPUTE will have the same routine." [1] This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough. [1] https://lore.kernel.org/lkml/c735a1cc-a545-50fb-44e7-c0ad93ee8ee7@amd.com/ Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-07-25drm/amdgpu/gfx10: Fix missing break in switch statementGustavo A. R. Silva1-0/+1
Add missing break statement in order to prevent the code from falling through to case AMDGPU_IRQ_STATE_ENABLE. This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough. Fixes: a644d85a5cd4 ("drm/amdgpu: add gfx v10 implementation (v10)") Cc: stable@vger.kernel.org Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-07-25drm/amdkfd: Fix missing break in switch statementGustavo A. R. Silva1-0/+1
Add missing break statement in order to prevent the code from falling through to case CHIP_NAVI10. This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough. Fixes: 14328aa58ce5 ("drm/amdkfd: Add navi10 support to amdkfd. (v3)") Cc: stable@vger.kernel.org Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-07-25perf/x86/intel: Mark expected switch fall-throughsGustavo A. R. Silva1-0/+2
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: arch/x86/events/intel/core.c: In function ‘intel_pmu_init’: arch/x86/events/intel/core.c:4959:8: warning: this statement may fall through [-Wimplicit-fallthrough=] pmem = true; ~~~~~^~~~~~ arch/x86/events/intel/core.c:4960:2: note: here case INTEL_FAM6_SKYLAKE_MOBILE: ^~~~ arch/x86/events/intel/core.c:5008:8: warning: this statement may fall through [-Wimplicit-fallthrough=] pmem = true; ~~~~~^~~~~~ arch/x86/events/intel/core.c:5009:2: note: here case INTEL_FAM6_ICELAKE_MOBILE: ^~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-07-25mtd: onenand_base: Mark expected switch fall-throughGustavo A. R. Silva1-0/+1
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warning: drivers/mtd/nand/onenand/onenand_base.c: In function ‘onenand_check_features’: drivers/mtd/nand/onenand/onenand_base.c:3264:17: warning: this statement may fall through [-Wimplicit-fallthrough=] this->options |= ONENAND_HAS_NOP_1; drivers/mtd/nand/onenand/onenand_base.c:3265:2: note: here case ONENAND_DEVICE_DENSITY_4Gb: ^~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Cc: Jonathan Bakker <xc-racer2@live.ca> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-07-25afs: fsclient: Mark expected switch fall-throughsGustavo A. R. Silva1-18/+33
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: Warning level 3 was used: -Wimplicit-fallthrough=3 fs/afs/fsclient.c: In function ‘afs_deliver_fs_fetch_acl’: fs/afs/fsclient.c:2199:19: warning: this statement may fall through [-Wimplicit-fallthrough=] call->unmarshall++; ~~~~~~~~~~~~~~~~^~ fs/afs/fsclient.c:2202:2: note: here case 1: ^~~~ fs/afs/fsclient.c:2216:19: warning: this statement may fall through [-Wimplicit-fallthrough=] call->unmarshall++; ~~~~~~~~~~~~~~~~^~ fs/afs/fsclient.c:2219:2: note: here case 2: ^~~~ fs/afs/fsclient.c:2225:19: warning: this statement may fall through [-Wimplicit-fallthrough=] call->unmarshall++; ~~~~~~~~~~~~~~~~^~ fs/afs/fsclient.c:2228:2: note: here case 3: ^~~~ This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-07-25afs: yfsclient: Mark expected switch fall-throughsGustavo A. R. Silva1-19/+35
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: fs/afs/yfsclient.c: In function ‘yfs_deliver_fs_fetch_opaque_acl’: fs/afs/yfsclient.c:1984:19: warning: this statement may fall through [-Wimplicit-fallthrough=] call->unmarshall++; ~~~~~~~~~~~~~~~~^~ fs/afs/yfsclient.c:1987:2: note: here case 1: ^~~~ fs/afs/yfsclient.c:2005:19: warning: this statement may fall through [-Wimplicit-fallthrough=] call->unmarshall++; ~~~~~~~~~~~~~~~~^~ fs/afs/yfsclient.c:2008:2: note: here case 2: ^~~~ fs/afs/yfsclient.c:2014:19: warning: this statement may fall through [-Wimplicit-fallthrough=] call->unmarshall++; ~~~~~~~~~~~~~~~~^~ fs/afs/yfsclient.c:2017:2: note: here case 3: ^~~~ fs/afs/yfsclient.c:2035:19: warning: this statement may fall through [-Wimplicit-fallthrough=] call->unmarshall++; ~~~~~~~~~~~~~~~~^~ fs/afs/yfsclient.c:2038:2: note: here case 4: ^~~~ fs/afs/yfsclient.c:2047:19: warning: this statement may fall through [-Wimplicit-fallthrough=] call->unmarshall++; ~~~~~~~~~~~~~~~~^~ fs/afs/yfsclient.c:2050:2: note: here case 5: ^~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 Also, fix some commenting style issues. This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-07-25can: mark expected switch fall-throughsGustavo A. R. Silva4-5/+8
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/net/can/peak_canfd/peak_pciefd_main.c:668:3: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/can/spi/mcp251x.c:875:7: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/can/usb/peak_usb/pcan_usb.c:422:6: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/can/at91_can.c:895:6: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/can/at91_can.c:953:15: warning: this statement may fall through [-Wimplicit-fallthrough=] drivers/net/can/usb/peak_usb/pcan_usb.c: In function ‘pcan_usb_decode_error’: drivers/net/can/usb/peak_usb/pcan_usb.c:422:6: warning: this statement may fall through [-Wimplicit-fallthrough=] if (n & PCAN_USB_ERROR_BUS_LIGHT) { ^ drivers/net/can/usb/peak_usb/pcan_usb.c:428:2: note: here case CAN_STATE_ERROR_WARNING: ^~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough. Notice that in some cases spelling mistakes were fixed. In other cases, the /* fall through */ comment is placed at the bottom of the case statement, which is what GCC is expecting to find. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-07-25firewire: mark expected switch fall-throughsGustavo A. R. Silva3-2/+3
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/firewire/core-device.c: In function ‘set_broadcast_channel’: drivers/firewire/core-device.c:969:7: warning: this statement may fall through [-Wimplicit-fallthrough=] if (data & cpu_to_be32(1 << 31)) { ^ drivers/firewire/core-device.c:974:3: note: here case RCODE_ADDRESS_ERROR: ^~~~ drivers/firewire/core-iso.c: In function ‘manage_channel’: drivers/firewire/core-iso.c:308:7: warning: this statement may fall through [-Wimplicit-fallthrough=] if ((data[0] & bit) == (data[1] & bit)) ^ drivers/firewire/core-iso.c:312:3: note: here default: ^~~~~~~ drivers/firewire/core-topology.c: In function ‘count_ports’: drivers/firewire/core-topology.c:69:23: warning: this statement may fall through [-Wimplicit-fallthrough=] (*child_port_count)++; ~~~~~~~~~~~~~~~~~~~^~ drivers/firewire/core-topology.c:70:3: note: here case SELFID_PORT_PARENT: ^~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 Notice that in some cases, the code comment is modified in accordance with what GCC is expecting to find. This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Cc: Kees Cook <keescook@chromium.org> Cc: Mathieu Malaterre <malat@debian.org> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (reworded a comment) Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
2019-07-25structleak: disable STRUCTLEAK_BYREF in combination with KASAN_STACKArnd Bergmann1-0/+7
The combination of KASAN_STACK and GCC_PLUGIN_STRUCTLEAK_BYREF leads to much larger kernel stack usage, as seen from the warnings about functions that now exceed the 2048 byte limit: drivers/media/i2c/tvp5150.c:253:1: error: the frame size of 3936 bytes is larger than 2048 bytes drivers/media/tuners/r820t.c:1327:1: error: the frame size of 2816 bytes is larger than 2048 bytes drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16552:1: error: the frame size of 3144 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] fs/ocfs2/aops.c:1892:1: error: the frame size of 2088 bytes is larger than 2048 bytes fs/ocfs2/dlm/dlmrecovery.c:737:1: error: the frame size of 2088 bytes is larger than 2048 bytes fs/ocfs2/namei.c:1677:1: error: the frame size of 2584 bytes is larger than 2048 bytes fs/ocfs2/super.c:1186:1: error: the frame size of 2640 bytes is larger than 2048 bytes fs/ocfs2/xattr.c:3678:1: error: the frame size of 2176 bytes is larger than 2048 bytes net/bluetooth/l2cap_core.c:7056:1: error: the frame size of 2144 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] net/bluetooth/l2cap_core.c: In function 'l2cap_recv_frame': net/bridge/br_netlink.c:1505:1: error: the frame size of 2448 bytes is larger than 2048 bytes net/ieee802154/nl802154.c:548:1: error: the frame size of 2232 bytes is larger than 2048 bytes net/wireless/nl80211.c:1726:1: error: the frame size of 2224 bytes is larger than 2048 bytes net/wireless/nl80211.c:2357:1: error: the frame size of 4584 bytes is larger than 2048 bytes net/wireless/nl80211.c:5108:1: error: the frame size of 2760 bytes is larger than 2048 bytes net/wireless/nl80211.c:6472:1: error: the frame size of 2112 bytes is larger than 2048 bytes The structleak plugin was previously disabled for CONFIG_COMPILE_TEST, but meant we missed some bugs, so this time we should address them. The frame size warnings are distracting, and risking a kernel stack overflow is generally not beneficial to performance, so it may be best to disallow that particular combination. This can be done by turning off either one. I picked the dependency in GCC_PLUGIN_STRUCTLEAK_BYREF and GCC_PLUGIN_STRUCTLEAK_BYREF_ALL, as this option is designed to make uninitialized stack usage less harmful when enabled on its own, but it also prevents KASAN from detecting those cases in which it was in fact needed. KASAN_STACK is currently implied by KASAN on gcc, but could be made a user selectable option if we want to allow combining (non-stack) KASAN with GCC_PLUGIN_STRUCTLEAK_BYREF. Note that it would be possible to specifically address the files that print the warning, but presumably the overall stack usage is still significantly higher than in other configurations, so this would not address the full problem. I could not test this with CONFIG_INIT_STACK_ALL, which may or may not suffer from a similar problem. Fixes: 81a56f6dcd20 ("gcc-plugins: structleak: Generalize to all variable types") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20190722114134.3123901-1-arnd@arndb.de Signed-off-by: Kees Cook <keescook@chromium.org>
2019-07-25nouveau: unlock mmap_sem on all errors from nouveau_range_faultChristoph Hellwig1-5/+6
Currently nouveau_svm_fault expects nouveau_range_fault to never unlock mmap_sem, but the latter unlocks it for a random selection of error codes. Fix this up by always unlocking mmap_sem for non-zero return values in nouveau_range_fault, and only unlocking it in the caller for successful returns. Link: https://lore.kernel.org/r/20190724065258.16603-5-hch@lst.de Tested-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-07-25nouveau: remove the block parameter to nouveau_range_faultChristoph Hellwig1-6/+4
The parameter is always false, so remove it as well as the -EAGAIN handling that can only happen for the non-blocking case. Link: https://lore.kernel.org/r/20190724065258.16603-4-hch@lst.de Tested-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-07-25mm/hmm: move hmm_vma_range_done and hmm_vma_fault to nouveauChristoph Hellwig2-56/+44
These two functions are marked as a legacy APIs to get rid of, but seem to suit the current nouveau flow. Move it to the only user in preparation for fixing a locking bug involving caller and callee. All comments referring to the old API have been removed as this now is a driver private helper. Link: https://lore.kernel.org/r/20190724065258.16603-3-hch@lst.de Tested-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-07-25mm/hmm: always return EBUSY for invalid ranges in hmm_range_{fault,snapshot}Christoph Hellwig2-7/+5
We should not have two different error codes for the same condition. EAGAIN must be reserved for the FAULT_FLAG_ALLOW_RETRY retry case and signals to the caller that the mmap_sem has been unlocked. Use EBUSY for the !valid case so that callers can get the locking right. Link: https://lore.kernel.org/r/20190724065258.16603-2-hch@lst.de Tested-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ralph Campbell <rcampbell@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> [jgg: elaborated commit message] Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-07-25platform/x86: intel_pmc_core: Add ICL-NNPI support to PMC CoreRajneesh Bhardwaj1-0/+1
Ice Lake Neural Network Processor for deep learning inference a.k.a. ICL-NNPI can re-use Ice Lake Mobile regmap to enable Intel PMC Core driver on it. Cc: Darren Hart <dvhart@infradead.org> Cc: Andy Shevchenko <andy@infradead.org> Cc: platform-driver-x86@vger.kernel.org Link: https://lkml.org/lkml/2019/6/5/1034 Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-07-25Platform: OLPC: add SPI MODULE_DEVICE_TABLELubomir Rintel1-0/+6
The SPI bus creates a device with the modalias of "xo1.75-ec". This fixes XO-1.75 EC driver autoloading Fixes: 0c3d931b3ab9 ("Platform: OLPC: Add XO-1.75 EC driver") Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-07-25platform/x86: wmi: add missing struct parameter descriptionMattias Jacobsson1-0/+1
Add a description for the context parameter in the struct wmi_device_id. Reported-by: kbuild test robot <lkp@intel.com> Fixes: a48e23385fcf ("platform/x86: wmi: add context pointer field to struct wmi_device_id") Signed-off-by: Mattias Jacobsson <2pi@mok.nu> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-07-25platform/x86: pcengines-apuv2: Fix softdep statementJean Delvare1-3/+1
Only first MODULE_SOFTDEP statement is handled per module. Multiple dependencies must be expressed in a single statement. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: "Enrico Weigelt, metux IT consult" <info@metux.net> Cc: Darren Hart <dvhart@infradead.org> Cc: Andy Shevchenko <andy@infradead.org> [andy: massaged commit message] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-07-25io_uring: ensure ->list is initialized for poll commandsJens Axboe1-0/+2
Daniel reports that when testing an http server that uses io_uring to poll for incoming connections, sometimes it hard crashes. This is due to an uninitialized list member for the io_uring request. Normally this doesn't trigger and none of the test cases caught it. Reported-by: Daniel Kozak <kozzi11@gmail.com> Tested-by: Daniel Kozak <kozzi11@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-07-25btrfs: Fix deadlock caused by missing memory barrierNikolay Borisov1-3/+6
Commit 06297d8cefca ("btrfs: switch extent_buffer blocking_writers from atomic to int") changed the type of blocking_writers but forgot to adjust relevant code in btrfs_tree_unlock by converting the smp_mb__after_atomic to smp_mb. This opened up the possibility of a deadlock due to re-ordering of setting blocking_writers and checking/waking up the waiter. This particular lockup is explained in a comment above waitqueue_active() function. Fix it by converting the memory barrier to a full smp_mb, accounting for the fact that blocking_writers is a simple integer. Fixes: 06297d8cefca ("btrfs: switch extent_buffer blocking_writers from atomic to int") Tested-by: Johannes Thumshirn <jthumshirn@suse.com> Signed-off-by: Nikolay Borisov <nborisov@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>