aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
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 <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]>
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 <[email protected]>
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/[email protected]/ Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]>
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: [email protected] Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]>
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: [email protected] Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]>
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 <[email protected]>
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 <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]> Cc: Mathieu Malaterre <[email protected]> Signed-off-by: Stefan Richter <[email protected]> (reworded a comment) Signed-off-by: Gustavo A. R. Silva <[email protected]>
2019-07-25Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller18-94/+480
Alexei Starovoitov says: ==================== pull-request: bpf 2019-07-25 The following pull-request contains BPF updates for your *net* tree. The main changes are: 1) fix segfault in libbpf, from Andrii. 2) fix gso_segs access, from Eric. 3) tls/sockmap fixes, from Jakub and John. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-07-25ipip: validate header length in ipip_tunnel_xmitHaishuang Yan1-0/+3
We need the same checks introduced by commit cb9f1b783850 ("ip: validate header length on virtual device xmit") for ipip tunnel. Fixes: cb9f1b783850b ("ip: validate header length on virtual device xmit") Signed-off-by: Haishuang Yan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-07-25selftests/net: add missing gitignores (ipv6_flowlabel)Jakub Kicinski1-2/+2
ipv6_flowlabel and ipv6_flowlabel_mgr are missing from gitignore. Quentin points out that the original commit 3fb321fde22d ("selftests/net: ipv6 flowlabel") did add ignore entries, they are just missing the "ipv6_" prefix. Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Quentin Monnet <[email protected]> Acked-by: Willem de Bruijn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-07-25bnx2x: Disable multi-cos feature.Sudarsana Reddy Kalluru1-2/+1
Commit 3968d38917eb ("bnx2x: Fix Multi-Cos.") which enabled multi-cos feature after prolonged time in driver added some regression causing numerous issues (sudden reboots, tx timeout etc.) reported by customers. We plan to backout this commit and submit proper fix once we have root cause of issues reported with this feature enabled. Fixes: 3968d38917eb ("bnx2x: Fix Multi-Cos.") Signed-off-by: Sudarsana Reddy Kalluru <[email protected]> Signed-off-by: Manish Chopra <[email protected]> Signed-off-by: David S. Miller <[email protected]>
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]>
2019-07-25Documentation: TLS: fix stat counters descriptionTariq Toukan1-6/+17
Add missing description of counters. Split tx_tls_encrypted counter into two, to give packets and bytes indications. Fixes: f42c104f2ec9 ("Documentation: add TLS offload documentation") Suggested-by: Jakub Kicinski <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-07-25nfp: tls: rename tls packet countersTariq Toukan1-2/+2
Align to the naming convention in TLS documentation. Fixes: 51a5e563298d ("nfp: tls: add basic statistics") Suggested-by: Jakub Kicinski <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-07-25net/mlx5e: kTLS, Call WARN_ONCE on netdev mismatchTariq Toukan1-1/+1
A netdev mismatch in the processed TLS SKB should not occur, and indicates a kernel bug. Add WARN_ONCE to spot such cases. Fixes: d2ead1f360e8 ("net/mlx5e: Add kTLS TX HW offload support") Suggested-by: Jakub Kicinski <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-07-25net/mlx5e: Prevent encap flow counter update async to user queryAriel Levkovich3-2/+8
This patch prevents a race between user invoked cached counters query and a neighbor last usage updater. The cached flow counter stats can be queried by calling "mlx5_fc_query_cached" which provides the number of bytes and packets that passed via this flow since the last time this counter was queried. It does so by reducting the last saved stats from the current, cached stats and then updating the last saved stats with the cached stats. It also provide the lastuse value for that flow. Since "mlx5e_tc_update_neigh_used_value" needs to retrieve the last usage time of encapsulation flows, it calls the flow counter query method periodically and async to user queries of the flow counter using cls_flower. This call is causing the driver to update the last reported bytes and packets from the cache and therefore, future user queries of the flow stats will return lower than expected number for bytes and packets since the last saved stats in the driver was updated async to the last saved stats in cls_flower. This causes wrong stats presentation of encapsulation flows to user. Since the neighbor usage updater only needs the lastuse stats from the cached counter, the fix is to use a dedicated lastuse query call that returns the lastuse value without synching between the cached stats and the last saved stats. Fixes: f6dfb4c3f216 ("net/mlx5e: Update neighbour 'used' state using HW flow rules counters") Signed-off-by: Ariel Levkovich <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-07-25net/mlx5e: Fix matching of speed to PRM link modesAya Levin3-32/+68
Speed translation is performed based on legacy or extended PTYS register. Translate speed with respect to: 1) Capability bit of extended PTYS table. 2) User request: a) When auto-negotiation is turned on, inspect advertisement whether it contains extended link modes. b) When auto-negotiation is turned off, speed > 100Gbps (maximal speed supported in legacy mode). With both conditions fulfilled translation is done with extended PTYS table otherwise use legacy PTYS table. Without this patch 25/50/100 Gbps speed cannot be set, since try to configure in extended mode but read from legacy mode. Fixes: dd1b9e09c12b ("net/mlx5: ethtool, Allow legacy link-modes configuration via non-extended ptys") Signed-off-by: Aya Levin <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-07-25net/mlx5e: Fix wrong max num channels indicationTariq Toukan9-41/+35
No XSK support in the enhanced IPoIB driver and representors. Add a profile property to specify this, and enhance the logic that calculates the max number of channels to take it into account. Fixes: db05815b36cb ("net/mlx5e: Add XSK zero-copy support") Signed-off-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-07-25net/mlx5: Fix modify_cq_in alignmentEdward Srouji1-2/+4
Fix modify_cq_in alignment to match the device specification. After this fix the 'cq_umem_valid' field will be in the right offset. Cc: <[email protected]> # 4.19 Fixes: bd37197554eb ("net/mlx5: Update mlx5_ifc with DEVX UID bits") Signed-off-by: Edward Srouji <[email protected]> Reviewed-by: Yishai Hadas <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-07-25net/mlx5: Add missing RDMA_RX capabilitiesMaor Gottlieb1-2/+3
New flow table type RDMA_RX was added but the MLX5_CAP_FLOW_TABLE_TYPE didn't handle this new flow table type. This means that MLX5_CAP_FLOW_TABLE_TYPE returns an empty capability to this flow table type. Update both the macro and the maximum supported flow table type to RDMA_RX. Fixes: d83eb50e29de ("net/mlx5: Add support in RDMA RX steering") Signed-off-by: Maor Gottlieb <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-07-25net/mlx5: Use reversed order when unregister devicesMark Zhang1-1/+1
When lag is active, which is controlled by the bonded mlx5e netdev, mlx5 interface unregestering must happen in the reverse order where rdma is unregistered (unloaded) first, to guarantee all references to the lag context in hardware is removed, then remove mlx5e netdev interface which will cleanup the lag context from hardware. Without this fix during destroy of LAG interface, we observed following errors: * mlx5_cmd_check:752:(pid 12556): DESTROY_LAG(0x843) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0xe4ac33) * mlx5_cmd_check:752:(pid 12556): DESTROY_LAG(0x843) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0xa5aee8). Fixes: a31208b1e11d ("net/mlx5_core: New init and exit flow for mlx5_core") Reviewed-by: Parav Pandit <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Signed-off-by: Mark Zhang <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
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/[email protected] Tested-by: Ralph Campbell <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
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/[email protected] Tested-by: Ralph Campbell <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
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/[email protected] Tested-by: Ralph Campbell <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
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/[email protected] Tested-by: Ralph Campbell <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Ralph Campbell <[email protected]> Reviewed-by: Jason Gunthorpe <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> [jgg: elaborated commit message] Signed-off-by: Jason Gunthorpe <[email protected]>
2019-07-25fsl/fman: Remove comment referring to non-existent functionChris Packham1-3/+0
fm_set_max_frm() existed in the Freescale SDK as a callback for an early_param. When this code was ported to the upstream kernel the early_param was converted to a module_param making the reference to the function incorrect. The rest of the comment already does a good job of explaining the parameter so removing the reference to the non-existent function seems like the best thing to do. Signed-off-by: Chris Packham <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-07-25st_nci_hci_connectivity_event_received: null check the allocationNavid Emamdoost1-0/+2
devm_kzalloc may fail and return NULL. So the null check is needed. Signed-off-by: Navid Emamdoost <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-07-25st21nfca_connectivity_event_received: null check the allocationNavid Emamdoost1-0/+2
devm_kzalloc may fail and return null. So the null check is needed. Signed-off-by: Navid Emamdoost <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-07-25tun: mark small packets as owned by the tap sockAlexis Bauvin1-3/+6
- v1 -> v2: Move skb_set_owner_w to __tun_build_skb to reduce patch size Small packets going out of a tap device go through an optimized code path that uses build_skb() rather than sock_alloc_send_pskb(). The latter calls skb_set_owner_w(), but the small packet code path does not. The net effect is that small packets are not owned by the userland application's socket (e.g. QEMU), while large packets are. This can be seen with a TCP session, where packets are not owned when the window size is small enough (around PAGE_SIZE), while they are once the window grows (note that this requires the host to support virtio tso for the guest to offload segmentation). All this leads to inconsistent behaviour in the kernel, especially on netfilter modules that uses sk->socket (e.g. xt_owner). Fixes: 66ccbc9c87c2 ("tap: use build_skb() for small packet") Signed-off-by: Alexis Bauvin <[email protected]> Acked-by: Jason Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-07-25Merge branch 'dim-fixes'David S. Miller7-63/+63
Leon Romanovsky says: ==================== DIM fixes for 5.3 Those two fixes for recently merged DIM patches, both exposed through RDMa DIM usage. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-07-25lib/dim: Fix -Wunused-const-variable warningsLeon Romanovsky2-56/+56
DIM causes to the following warnings during kernel compilation which indicates that tx_profile and rx_profile are supposed to be declared in *.c and not in *.h files. In file included from ./include/rdma/ib_verbs.h:64, from ./include/linux/mlx5/device.h:37, from ./include/linux/mlx5/driver.h:51, from ./include/linux/mlx5/vport.h:36, from drivers/infiniband/hw/mlx5/ib_virt.c:34: ./include/linux/dim.h:326:1: warning: _tx_profile_ defined but not used [-Wunused-const-variable=] 326 | tx_profile[DIM_CQ_PERIOD_NUM_MODES][NET_DIM_PARAMS_NUM_PROFILES] = { | ^~~~~~~~~~ ./include/linux/dim.h:320:1: warning: _rx_profile_ defined but not used [-Wunused-const-variable=] 320 | rx_profile[DIM_CQ_PERIOD_NUM_MODES][NET_DIM_PARAMS_NUM_PROFILES] = { | ^~~~~~~~~~ Fixes: 4f75da3666c0 ("linux/dim: Move implementation to .c files") Signed-off-by: Leon Romanovsky <[email protected]> Reviewed-by: Bart Van Assche <[email protected]> Acked-by: Saeed Mahameed <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-07-25linux/dim: Fix overflow in dim calculationYamin Friedman5-7/+7
While using net_dim, a dim_sample was used without ever initializing the comps value. Added use of DIV_ROUND_DOWN_ULL() to prevent potential overflow, it should not be a problem to save the final result in an int because after the division by epms the value should not be larger than a few thousand. [ 1040.127124] UBSAN: Undefined behaviour in lib/dim/dim.c:78:23 [ 1040.130118] signed integer overflow: [ 1040.131643] 134718714 * 100 cannot be represented in type 'int' Fixes: 398c2b05bbee ("linux/dim: Add completions count to dim_sample") Signed-off-by: Yamin Friedman <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Acked-by: Saeed Mahameed <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-07-25ife: error out when nla attributes are emptyCong Wang1-0/+5
act_ife at least requires TCA_IFE_PARMS, so we have to bail out when there is no attribute passed in. Reported-by: [email protected] Fixes: ef6980b6becb ("introduce IFE action") Cc: Jamal Hadi Salim <[email protected]> Cc: Jiri Pirko <[email protected]> Signed-off-by: Cong Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
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 <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: [email protected] Link: https://lkml.org/lkml/2019/6/5/1034 Signed-off-by: Rajneesh Bhardwaj <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
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 <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
2019-07-25libbpf: silence GCC8 warning about string truncationAndrii Nakryiko1-2/+2
Despite a proper NULL-termination after strncpy(..., ..., IFNAMSIZ - 1), GCC8 still complains about *expected* string truncation: xsk.c:330:2: error: 'strncpy' output may be truncated copying 15 bytes from a string of length 15 [-Werror=stringop-truncation] strncpy(ifr.ifr_name, xsk->ifname, IFNAMSIZ - 1); This patch gets rid of the issue altogether by using memcpy instead. There is no performance regression, as strncpy will still copy and fill all of the bytes anyway. v1->v2: - rebase against bpf tree. Cc: Magnus Karlsson <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Acked-by: Magnus Karlsson <[email protected]> Acked-by: Song Liu <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]>
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 <[email protected]> Fixes: a48e23385fcf ("platform/x86: wmi: add context pointer field to struct wmi_device_id") Signed-off-by: Mattias Jacobsson <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]>
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 <[email protected]> Cc: "Enrico Weigelt, metux IT consult" <[email protected]> Cc: Darren Hart <[email protected]> Cc: Andy Shevchenko <[email protected]> [andy: massaged commit message] Signed-off-by: Andy Shevchenko <[email protected]>
2019-07-25Merge branch 'nvme-5.3' of git://git.infradead.org/nvme into for-linusJens Axboe4-17/+15
Pull NVMe fixes from Christoph. * 'nvme-5.3' of git://git.infradead.org/nvme: Revert "nvme-pci: don't create a read hctx mapping without read queues" nvme: fix multipath crash when ANA is deactivated nvme: fix memory leak caused by incorrect subsystem free nvme: ignore subnqn for ADATA SX6000LNP
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 <[email protected]> Tested-by: Daniel Kozak <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-07-25Merge tag 'pm-5.3-rc2' of ↵Linus Torvalds4-16/+15
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki "These fix two issues related to the RAPL MMIO interface support added recently and one cpufreq driver issue. Specifics: - Initialize the power capping subsystem and the RAPL driver earlier in case the int340X thermal driver is built-in and attempts to register an MMIO interface for RAPL which must not happen before the requisite infrastructure is ready (Zhang Rui) - Fix the int340X thermal driver's RAPL MMIO interface registration error path (Rafael Wysocki) - Fix possible use-after-free in the pasemi cpufreq driver (Wen Yang)" * tag 'pm-5.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq/pasemi: fix use-after-free in pas_cpufreq_cpu_init() int340X/processor_thermal_device: Fix proc_thermal_rapl_remove() powercap: Invoke powercap_init() and rapl_init() earlier
2019-07-25Merge tag 'riscv/for-v5.3-rc2' of ↵Linus Torvalds5-0/+27
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V updates from Paul Walmsley: "Four minor RISC-V-related changes: - Add support for the new clone3 syscall for RV64, relying on the generic support - Add DT data for the gigabit Ethernet controller on the SiFive FU540 and the HiFive Unleashed board - Update MAINTAINERS to add me to the arch/riscv maintainers' list - Add support for PCIe message-signaled interrupts by reusing the generic header file" * tag 'riscv/for-v5.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: dts: Add DT node for SiFive FU540 Ethernet controller driver riscv: include generic support for MSI irqdomains MAINTAINERS: Add Paul as a RISC-V maintainer riscv: enable sys_clone3 syscall for rv64
2019-07-25Merge tag 'ktest-v5.3' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest Pull ktest fixlets from Steven Rostedt: "This contains only simple spelling fixes" * tag 'ktest-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest: ktest: Fix some typos in config-bisect.pl
2019-07-25Merge branch 'access-creds'Linus Torvalds3-3/+45
The access() (and faccessat()) credentials change can cause an unnecessary load on the RCU machinery because every access() call ends up freeing the temporary access credential using RCU. This isn't really noticeable on small machines, but if you have hundreds of cores you can cause huge slowdowns due to RCU storms. It's easy to avoid: the temporary access crededntials aren't actually normally accessed using RCU at all, so we can avoid the whole issue by just marking them as such. * access-creds: access: avoid the RCU grace period for the temporary subjective credentials
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 <[email protected]> Signed-off-by: Nikolay Borisov <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2019-07-25IB/mlx5: Fix RSS Toeplitz setup to be aligned with the HW specificationYishai Hadas1-1/+0
The specification for the Toeplitz function doesn't require to set the key explicitly to be symmetric. In case a symmetric functionality is required a symmetric key can be simply used. Wrongly forcing the algorithm to symmetric causes the wrong packet distribution and a performance degradation. Link: https://lore.kernel.org/r/[email protected] Cc: <[email protected]> # 4.7 Fixes: 28d6137008b2 ("IB/mlx5: Add RSS QP support") Signed-off-by: Yishai Hadas <[email protected]> Reviewed-by: Alex Vainman <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>