aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-05-02Merge tag 'pci-v5.1-fixes-3' of ↵Linus Torvalds5-4/+32
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI fixes from Bjorn Helgaas: "I apologize for sending these so late in the cycle. We went back and forth about how to deal with the unexpected logging of intentional link state changes and finally decided to just config them off by default. PCI fixes: - Stop ignoring "pci=disable_acs_redir" parameter (Logan Gunthorpe) - Use shared MSI/MSI-X vector for Link Bandwidth Management (Alex Williamson) - Add Kconfig option for Link Bandwidth notification messages (Keith Busch)" * tag 'pci-v5.1-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI/LINK: Add Kconfig option (default off) PCI/portdrv: Use shared MSI/MSI-X vector for Bandwidth Management PCI: Fix issue with "pci=disable_acs_redir" parameter being ignored
2019-05-02Merge tag 'mtd/fixes-for-5.1-rc6' of ↵Linus Torvalds1-6/+6
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux Pull MTD fix from Richard Weinberger: "A single regression fix for the marvell nand driver" * tag 'mtd/fixes-for-5.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux: mtd: rawnand: marvell: Clean the controller state before each operation
2019-05-02rtw88: phy: mark expected switch fall-throughsGustavo A. R. Silva1-0/+3
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warnings: drivers/net/wireless/realtek/rtw88/phy.c: In function ‘rtw_get_channel_group’: ./include/linux/compiler.h:77:22: warning: this statement may fall through [-Wimplicit-fallthrough=] # define unlikely(x) __builtin_expect(!!(x), 0) ^~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/asm-generic/bug.h:125:2: note: in expansion of macro ‘unlikely’ unlikely(__ret_warn_on); \ ^~~~~~~~ drivers/net/wireless/realtek/rtw88/phy.c:907:3: note: in expansion of macro ‘WARN_ON’ WARN_ON(1); ^~~~~~~ drivers/net/wireless/realtek/rtw88/phy.c:908:2: note: here case 1: ^~~~ In file included from ./include/linux/bcd.h:5, from drivers/net/wireless/realtek/rtw88/phy.c:5: drivers/net/wireless/realtek/rtw88/phy.c: In function ‘phy_get_2g_tx_power_index’: ./include/linux/compiler.h:77:22: warning: this statement may fall through [-Wimplicit-fallthrough=] # define unlikely(x) __builtin_expect(!!(x), 0) ^~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/asm-generic/bug.h:125:2: note: in expansion of macro ‘unlikely’ unlikely(__ret_warn_on); \ ^~~~~~~~ drivers/net/wireless/realtek/rtw88/phy.c:1021:3: note: in expansion of macro ‘WARN_ON’ WARN_ON(1); ^~~~~~~ drivers/net/wireless/realtek/rtw88/phy.c:1022:2: note: here case RTW_CHANNEL_WIDTH_20: ^~~~ 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]> Signed-off-by: Kalle Valo <[email protected]>
2019-05-02rtw88: fix shift of more than 32 bits of a integerColin Ian King1-3/+3
Currently the shift of an integer value more than 32 bits can occur when nss is more than 32. Fix this by making the integer constants unsigned long longs before shifting and bit-wise or'ing with the u64 ra_mask to avoid the undefined shift behaviour. Addresses-Coverity: ("Bad shift operation") Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2019-05-02PCI/LINK: Add Kconfig option (default off)Keith Busch3-1/+13
e8303bb7a75c ("PCI/LINK: Report degraded links via link bandwidth notification") added dmesg logging whenever a link changes speed or width to a state that is considered degraded. Unfortunately, it cannot differentiate signal integrity-related link changes from those intentionally initiated by an endpoint driver, including drivers that may live in userspace or VMs when making use of vfio-pci. Some GPU drivers actively manage the link state to save power, which generates a stream of messages like this: vfio-pci 0000:07:00.0: 32.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s x16 link at 0000:00:02.0 (capable of 64.000 Gb/s with 5 GT/s x16 link) Since we can't distinguish the intentional changes from the signal integrity issues, leave the reporting turned off by default. Add a Kconfig option to turn it on if desired. Fixes: e8303bb7a75c ("PCI/LINK: Report degraded links via link bandwidth notification") Link: https://lore.kernel.org/linux-pci/[email protected] Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>
2019-05-02net: ll_temac: Fix typo bug for 32-bitEsben Haabendal1-1/+1
Fixes: d84aec42151b ("net: ll_temac: Fix support for 64-bit platforms") Signed-off-by: Esben Haabendal <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-02ice: Use dev_err when ice_cfg_vsi_lan failsBrett Creeley1-3/+6
dev_err makes more sense than dev_info when this call fails. Signed-off-by: Brett Creeley <[email protected]> Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-05-02ice: Refactor link event flowBrett Creeley2-48/+65
Currently the link event flow works, but can be much better. Refactor the link event flow to make it cleaner and more clear on what is going on. Signed-off-by: Brett Creeley <[email protected]> Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-05-02ice: Add missing PHY type to link settingsTony Nguyen1-0/+1
The PHY type ICE_PHY_TYPE_LOW_25G_AUI_C2C is missing from ice_get_settings_link_up() which is causing a warning message for unrecognized PHY. Add the PHY type to correctly set the settings and avoid the warning message. Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-05-02ice: Add reg_idx variable in ice_q_vector structureBrett Creeley4-26/+76
Every time we want to re-enable interrupts and/or write to a register that requires an interrupt vector's hardware index we do the following: vsi->hw_base_vector + q_vector->v_idx This is a wasteful operation, especially in the hot path. Fix this by adding a u16 reg_idx member to the ice_q_vector structure and make the necessary changes to make this work. Signed-off-by: Brett Creeley <[email protected]> Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-05-02ice: Remove runtime change of PFINT_OICR_ENA registerMd Fahad Iqbal Polash2-23/+3
Runtime change of PFINT_OICR_ENA register is unnecessary. The handlers should always clear the atomic bit for each task as they start, because it will make sure that any late interrupt will either 1) re-set the bit, or 2) be handled directly in the "already running" task handler. Signed-off-by: Md Fahad Iqbal Polash <[email protected]> Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-05-02ice: Fix issue when adding more than allowed VLANsAkeem G Abodunrin2-7/+21
This patch fixes issue with non trusted VFs being able to add more than permitted number of VLANs by adding a check in ice_vc_process_vlan_msg. Also don't return an error in this case as the VF does not need to know that it is not trusted. Also rework ice_vsi_kill_vlan to use the right types. Signed-off-by: Akeem G Abodunrin <[email protected]> Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-05-02ice: Remove unnecessary wait when disabling/enabling Rx queuesBrett Creeley1-8/+2
In ice_vsi_ctrl_rx_rings() we are unnecessarily waiting for QRX_CTRL_QENA_REQ and QRX_CTRL_QENA_STAT to be the same value prior to disabling each Rx queue. There is no reason to do this so remove this wait loop as we already have a wait loop after disabling/enabling the Rx queue through the QRX_CTRL register to make sure it gets successfully disabled/enabled. Signed-off-by: Brett Creeley <[email protected]> Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-05-02ice: Add ability to update rx-usecs-highBrett Creeley4-2/+33
Currently the driver allows rx-usecs-high values to be set, but when querying the device for rx-usecs-high the value does not stick. This is because it was not yet implemented. Add code to allow the user to change rx-usecs-high and use this to set the q_vector's intrl value. Signed-off-by: Brett Creeley <[email protected]> Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-05-02ice: Add 52 byte RSS hash key supportPaul Greenwalt2-7/+8
Add support to set 52 byte RSS hash key. Signed-off-by: Paul Greenwalt <[email protected]> Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-05-02ice: Use ice_for_each_q_vector macro where possibleBrett Creeley2-8/+8
There are many places in the code where we do the following: for (i = 0; i < vsi->num_q_vectors; i++) Instead use the macro mentioned in the commit title: ice_for_each_q_vector(vsi, i) Signed-off-by: Brett Creeley <[email protected]> Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-05-02ice: Validate ring existence and its q_vector per VSIMaciej Fijalkowski1-1/+2
When stopping Tx rings, we use 'i' as an ring array index for looking up whether the ice_ring exists and have assigned a q_vector. This checks rings only within a given TC and we need to go through every ring in VSI. Use 'q_idx' instead. Signed-off-by: Maciej Fijalkowski <[email protected]> Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-05-02ice: Reduce scope of variable in ice_vsi_cfg_rxqsBrett Creeley1-7/+11
Reduce scope of the variable 'err' to inside the for loop instead of using it as a second looping conditional. Also while here, improve the debug message if we fail to configure a Rx queue. Signed-off-by: Brett Creeley <[email protected]> Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-05-02ice: Resolve static analysis reported issueBruce Allan1-10/+2
Static analysis points out the default case in the switch statement in ice_get_itr_intrl_gran() is an infeasible condition causing the default case statement to be unreachable. Remove it and since the function no longer returns anything but success, change it to just return void and update the only call to it accordingly. Signed-off-by: Bruce Allan <[email protected]> Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-05-02ice: Return configuration error without queue to disableAkeem G Abodunrin1-7/+10
If there is no queue to disable, return appropriate configuration error earlier without acquiring the lock. Signed-off-by: Akeem G Abodunrin <[email protected]> Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-05-02ice: Create framework for VSI queue contextAnirudh Venkataramanan7-56/+205
This patch introduces a framework to store queue specific information in VSI queue contexts. Currently VSI queue context (represented by struct ice_q_ctx) only has q_handle as a member. In future patches, this structure will be updated to hold queue specific information. Signed-off-by: Anirudh Venkataramanan <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]>
2019-05-01udp: fix GRO packet of deathEric Dumazet1-3/+10
syzbot was able to crash host by sending UDP packets with a 0 payload. TCP does not have this issue since we do not aggregate packets without payload. Since dev_gro_receive() sets gso_size based on skb_gro_len(skb) it seems not worth trying to cope with padded packets. BUG: KASAN: slab-out-of-bounds in skb_gro_receive+0xf5f/0x10e0 net/core/skbuff.c:3826 Read of size 16 at addr ffff88808893fff0 by task syz-executor612/7889 CPU: 0 PID: 7889 Comm: syz-executor612 Not tainted 5.1.0-rc7+ #96 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187 kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 __asan_report_load16_noabort+0x14/0x20 mm/kasan/generic_report.c:133 skb_gro_receive+0xf5f/0x10e0 net/core/skbuff.c:3826 udp_gro_receive_segment net/ipv4/udp_offload.c:382 [inline] call_gro_receive include/linux/netdevice.h:2349 [inline] udp_gro_receive+0xb61/0xfd0 net/ipv4/udp_offload.c:414 udp4_gro_receive+0x763/0xeb0 net/ipv4/udp_offload.c:478 inet_gro_receive+0xe72/0x1110 net/ipv4/af_inet.c:1510 dev_gro_receive+0x1cd0/0x23c0 net/core/dev.c:5581 napi_gro_frags+0x36b/0xd10 net/core/dev.c:5843 tun_get_user+0x2f24/0x3fb0 drivers/net/tun.c:1981 tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2027 call_write_iter include/linux/fs.h:1866 [inline] do_iter_readv_writev+0x5e1/0x8e0 fs/read_write.c:681 do_iter_write fs/read_write.c:957 [inline] do_iter_write+0x184/0x610 fs/read_write.c:938 vfs_writev+0x1b3/0x2f0 fs/read_write.c:1002 do_writev+0x15e/0x370 fs/read_write.c:1037 __do_sys_writev fs/read_write.c:1110 [inline] __se_sys_writev fs/read_write.c:1107 [inline] __x64_sys_writev+0x75/0xb0 fs/read_write.c:1107 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x441cc0 Code: 05 48 3d 01 f0 ff ff 0f 83 9d 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 83 3d 51 93 29 00 00 75 14 b8 14 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 74 09 fc ff c3 48 83 ec 08 e8 ba 2b 00 00 RSP: 002b:00007ffe8c716118 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007ffe8c716150 RCX: 0000000000441cc0 RDX: 0000000000000001 RSI: 00007ffe8c716170 RDI: 00000000000000f0 RBP: 0000000000000000 R08: 000000000000ffff R09: 0000000000a64668 R10: 0000000020000040 R11: 0000000000000246 R12: 000000000000c2d9 R13: 0000000000402b50 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5143: save_stack+0x45/0xd0 mm/kasan/common.c:75 set_track mm/kasan/common.c:87 [inline] __kasan_kmalloc mm/kasan/common.c:497 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:470 kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:505 slab_post_alloc_hook mm/slab.h:437 [inline] slab_alloc mm/slab.c:3393 [inline] kmem_cache_alloc+0x11a/0x6f0 mm/slab.c:3555 mm_alloc+0x1d/0xd0 kernel/fork.c:1030 bprm_mm_init fs/exec.c:363 [inline] __do_execve_file.isra.0+0xaa3/0x23f0 fs/exec.c:1791 do_execveat_common fs/exec.c:1865 [inline] do_execve fs/exec.c:1882 [inline] __do_sys_execve fs/exec.c:1958 [inline] __se_sys_execve fs/exec.c:1953 [inline] __x64_sys_execve+0x8f/0xc0 fs/exec.c:1953 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 5351: save_stack+0x45/0xd0 mm/kasan/common.c:75 set_track mm/kasan/common.c:87 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:459 kasan_slab_free+0xe/0x10 mm/kasan/common.c:467 __cache_free mm/slab.c:3499 [inline] kmem_cache_free+0x86/0x260 mm/slab.c:3765 __mmdrop+0x238/0x320 kernel/fork.c:677 mmdrop include/linux/sched/mm.h:49 [inline] finish_task_switch+0x47b/0x780 kernel/sched/core.c:2746 context_switch kernel/sched/core.c:2880 [inline] __schedule+0x81b/0x1cc0 kernel/sched/core.c:3518 preempt_schedule_irq+0xb5/0x140 kernel/sched/core.c:3745 retint_kernel+0x1b/0x2d arch_local_irq_restore arch/x86/include/asm/paravirt.h:767 [inline] kmem_cache_free+0xab/0x260 mm/slab.c:3766 anon_vma_chain_free mm/rmap.c:134 [inline] unlink_anon_vmas+0x2ba/0x870 mm/rmap.c:401 free_pgtables+0x1af/0x2f0 mm/memory.c:394 exit_mmap+0x2d1/0x530 mm/mmap.c:3144 __mmput kernel/fork.c:1046 [inline] mmput+0x15f/0x4c0 kernel/fork.c:1067 exec_mmap fs/exec.c:1046 [inline] flush_old_exec+0x8d9/0x1c20 fs/exec.c:1279 load_elf_binary+0x9bc/0x53f0 fs/binfmt_elf.c:864 search_binary_handler fs/exec.c:1656 [inline] search_binary_handler+0x17f/0x570 fs/exec.c:1634 exec_binprm fs/exec.c:1698 [inline] __do_execve_file.isra.0+0x1394/0x23f0 fs/exec.c:1818 do_execveat_common fs/exec.c:1865 [inline] do_execve fs/exec.c:1882 [inline] __do_sys_execve fs/exec.c:1958 [inline] __se_sys_execve fs/exec.c:1953 [inline] __x64_sys_execve+0x8f/0xc0 fs/exec.c:1953 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff88808893f7c0 which belongs to the cache mm_struct of size 1496 The buggy address is located 600 bytes to the right of 1496-byte region [ffff88808893f7c0, ffff88808893fd98) The buggy address belongs to the page: page:ffffea0002224f80 count:1 mapcount:0 mapping:ffff88821bc40ac0 index:0xffff88808893f7c0 compound_mapcount: 0 flags: 0x1fffc0000010200(slab|head) raw: 01fffc0000010200 ffffea00025b4f08 ffffea00027b9d08 ffff88821bc40ac0 raw: ffff88808893f7c0 ffff88808893e440 0000000100000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88808893fe80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88808893ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88808893ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888088940000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888088940080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Fixes: e20cf8d3f1f7 ("udp: implement GRO for plain UDP sockets.") Signed-off-by: Eric Dumazet <[email protected]> Cc: Paolo Abeni <[email protected]> Reported-by: syzbot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-01Merge tag 'for-v5.1-rc' of ↵Linus Torvalds2-6/+3
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply Pull power supply fixes from Sebastian Reichel: "Two more fixes for the 5.1 cycle. One division by zero fix in a specific driver and one core workaround for bad userspace behaviour from systemd regarding uevents. IMHO this can be considered to be a userspace bug, but the debug messages are useless anyways - cpcap-battery: fix a division by zero - core: fix systemd issue due to log messages produced by uevent" * tag 'for-v5.1-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: power: supply: sysfs: prevent endless uevent loop with CONFIG_POWER_SUPPLY_DEBUG power: supply: cpcap-battery: Fix division by zero
2019-05-01net/mlx5: E-Switch, Use atomic rep state to serialize state changeBodong Wang2-20/+18
When the state of rep was introduced, it was also designed to prevent duplicate unloading of the same rep. Considering the following two flows when an eswitch manager is at switchdev mode with n VF reps loaded. +--------------------------------------+--------------------------------+ | cpu-0 | cpu-1 | | -------- | -------- | | mlx5_ib_remove | mlx5_eswitch_disable_sriov | | mlx5_ib_unregister_vport_reps | esw_offloads_cleanup | | mlx5_eswitch_unregister_vport_reps | esw_offloads_unload_all_reps | | __unload_reps_all_vport | __unload_reps_all_vport | +--------------------------------------+--------------------------------+ These two flows will try to unload the same rep. Per original design, once one flow unloads the rep, the state moves to REGISTERED. The 2nd flow will no longer needs to do the unload and bails out. However, as read and write of the state is not atomic, when 1st flow is doing the unload, the state is still LOADED, 2nd flow is able to do the same unload action. Kernel crash will happen. To solve this, driver should do atomic test-and-set for the state. So that only one flow can change the rep state from LOADED to REGISTERED, and proceed to do the actual unloading. Since the state is changing to atomic type, all other read/write should be atomic action as well. Fixes: f121e0ea9586 (net/mlx5: E-Switch, Add state to eswitch vport representors) Signed-off-by: Bodong Wang <[email protected]> Reviewed-by: Parav Pandit <[email protected]> Reviewed-by: Vu Pham <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01net/mlx5: E-Switch, Fix the check of legal vportBodong Wang2-45/+46
The check of legal vport is to ensure the vport number falls between 0 and total number of vports. Along with the introduction of uplink rep, enabled vports are not consecutive any more. Therefore, rely on the eswitch vport getter function to check if it's a valid vport. As the getter function relies on eswitch, add the check of vport group manager and validation the presence of eswitch structure. Remove the redundant check in the function calls. Since the vport array will be allocated once eswitch is initialized and will be kept alive if eswitch presents, no need to protect it with the state lock. Fixes: 5ae5162066d8 ("net/mlx5: E-Switch, Assign a different position for uplink rep and vport") Signed-off-by: Bodong Wang <[email protected]> Signed-off-by: Parav Pandit <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01net/mlx5: E-Switch, Use getter to access all vport arrayBodong Wang2-9/+11
Some functions issue vport commands and access vport array using vport_index/vport_num interchangeably which is OK for VFs vports. However, this creates potential bug if those vports are not VFs (E.g, uplink, sf) where their vport_index don't equal to vport_num. Prepare code to access mlx5_vport structure using a getter function. Signed-off-by: Bodong Wang <[email protected]> Signed-off-by: Vu Pham <[email protected]> Reviewed-by: Parav Pandit <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01net/mlx5: Use available mlx5_vport structParav Pandit1-58/+51
Several functions need to access mlx5_vport and vport_num. When these functions are called, caller already has mlx5_vport* available. Hence pass such mlx5_vport pointer. This is preparation patch to add error checks to mlx5_eswitch_get_vport() and to return error status. By doing so, reduce places where error check of mlx5_eswitch_get_vport() can be avoided. While doing such change, mlx5_eswitch_query_vport_drop_stats() gets corrected to work on vport, instead of vport_idx. Signed-off-by: Parav Pandit <[email protected]> Reviewed-by: Bodong Wang <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01net/mlx5: Reuse mlx5_esw_for_each_vf_vport macro in two filesParav Pandit3-52/+58
Currently mlx5_esw_for_each_vf_vport iterates over mlx5_vport entries in eswitch.c Same macro in eswitch_offloads.c iterates over vport number in eswitch_offloads.c Instead of duplicate macro names, to avoid confusion and to reuse the same macro in both files, move it to eswitch.h. To iterate over vport numbers where there is no need to iterate over mlx5_vport, but only a vport number is needed, rename those macros in eswitch_offloads.c to mlx5_esw_for_each_vf_num_vport*. While at it, keep all vport and vport rep iterators together. Signed-off-by: Parav Pandit <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01net/mlx5: Remove unused mlx5_query_nic_vport_vlansBodong Wang2-65/+0
mlx5_query_nic_vport_vlans() is not used anymore. Hence remove it. This patch doesn't change any functionality. Signed-off-by: Bodong Wang <[email protected]> Reviewed-by: Parav Pandit <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01net/mlx5e: remove meaningless CFLAGS_tracepoint.oMasahiro Yamada1-2/+0
CFLAGS_tracepoint.o specifies CFLAGS for compiling tracepoint.c but it does not exist under drivers/net/ethernet/mellanox/mlx5/core/. CFLAGS_tracepoint.o is unused. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01net/mlx5e: Put the common XDP code into a functionMaxim Mikityanskiy1-36/+27
The same code that returns XDP frames and releases pages is used both in mlx5e_poll_xdpsq_cq and mlx5e_free_xdpsq_descs. Create a function that cleans up an MPWQE. Signed-off-by: Maxim Mikityanskiy <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01net/mlx5e: ethtool, Add support for EEPROM high pages queryErez Alfasi3-10/+39
Add the support to read additional EEPROM information from high pages. Information for modules such as SFF-8436 and SFF-8636: 1) Application select table 2) User writable EEPROM 3) Thresholds and alarms Signed-off-by: Erez Alfasi <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01ethtool: Add SFF-8436 and SFF-8636 max EEPROM length definitionsErez Alfasi1-0/+3
Added max EEPROM length defines for ethtool usage: #define ETH_MODULE_SFF_8636_MAX_LEN 640 #define ETH_MODULE_SFF_8436_MAX_LEN 640 These definitions are used to determine the EEPROM data length when reading high eeprom pages. For example, SFF-8636 EEPROM data from page 03h needs to be stored at data[512] - data[639]. Signed-off-by: Erez Alfasi <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01net/mlx5e: Return error when trying to insert existing flower filterVlad Buslov1-0/+1
With unlocked TC it is possible to have spurious deletes and inserts of same filter. TC layer needs drivers to always return error when flow insertion failed in order to correctly calculate "in_hw_count" for each filter. Fix mlx5e_configure_flower() to return -EEXIST when TC tries to insert a filter that is already provisioned to the driver. Signed-off-by: Vlad Buslov <[email protected]> Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01net/mlx5e: Replace TC VLAN pop with VLAN 0 rewrite in prio tag modeEli Britstein1-0/+36
Current ConnectX HW is unable to perform VLAN pop in TX path and VLAN push on RX path. To workaround that limitation untagged packets are tagged with VLAN ID 0x000 (priority tag) and pop/push actions are replaced by VLAN re-write actions (which are supported by the HW). Replace TC VLAN pop action with a VLAN priority tag header rewrite. Signed-off-by: Eli Britstein <[email protected]> Reviewed-by: Oz Shlomo <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01net/mlx5e: ACLs for priority tag modeEli Britstein3-12/+193
Current ConnectX HW is unable to perform VLAN pop in TX path and VLAN push on RX path. As a workaround, untagged packets are tagged with VID 0x000 allowing pop/push actions to be exchanged with VLAN rewrite actions. Use the ingress ACL table, preceding the FDB, to push VLAN 0x000 ID tag for untagged packets and the egress ACL table, succeeding the FDB, to pop VLAN 0x000 ID tag. Signed-off-by: Eli Britstein <[email protected]> Reviewed-by: Oz Shlomo <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01net/mlx5e: Turn on HW tunnel offload in all TIRsTariq Toukan4-1/+7
Hardware requires that all TIRs that steer traffic to the same RQ should share identical tunneled_offload_en value. For that, the tunneled_offload_en bit should be set/unset (according to the HW capability) for all TIRs', not only the ones dedicated for tunneled (inner) traffic. Fixes: 1b223dd39162 ("net/mlx5e: Fix checksum handling for non-stripped vlan packets") Signed-off-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01net/mlx5e: Take common TIR context settings into a functionTariq Toukan1-28/+21
Many TIR context settings are common to different TIR types, take them into a common function. Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Aya Levin <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01ipv6: A few fixes on dereferencing rt->fromMartin KaFai Lau1-20/+18
It is a followup after the fix in commit 9c69a1320515 ("route: Avoid crash from dereferencing NULL rt->from") rt6_do_redirect(): 1. NULL checking is needed on rt->from because a parallel fib6_info delete could happen that sets rt->from to NULL. (e.g. rt6_remove_exception() and fib6_drop_pcpu_from()). 2. fib6_info_hold() is not enough. Same reason as (1). Meaning, holding dst->__refcnt cannot ensure rt->from is not NULL or rt->from->fib6_ref is not 0. Instead of using fib6_info_hold_safe() which ip6_rt_cache_alloc() is already doing, this patch chooses to extend the rcu section to keep "from" dereference-able after checking for NULL. inet6_rtm_getroute(): 1. NULL checking is also needed on rt->from for a similar reason. Note that inet6_rtm_getroute() is using RTNL_FLAG_DOIT_UNLOCKED. Fixes: a68886a69180 ("net/ipv6: Make from in rt6_info rcu protected") Signed-off-by: Martin KaFai Lau <[email protected]> Acked-by: Wei Wang <[email protected]> Reviewed-by: David Ahern <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-01rds: ib: force endiannes annotationNicholas Mc Guire1-5/+3
While the endiannes is being handled correctly as indicated by the comment above the offending line - sparse was unhappy with the missing annotation as be64_to_cpu() expects a __be64 argument. To mitigate this annotation all involved variables are changed to a consistent __le64 and the conversion to uint64_t delayed to the call to rds_cong_map_updated(). Signed-off-by: Nicholas Mc Guire <[email protected]> Acked-by: Santosh Shilimkar <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-01Merge branch 'net-mvpp2-cls-Add-classification'David S. Miller4-84/+545
Maxime Chevallier says: ==================== net: mvpp2: cls: Add classification This series is a rework of the previously standalone patch adding classification support for mvpp2 : https://lore.kernel.org/netdev/[email protected]/ This patch has been reworked according to Saeed's review, to make sure that the location of the rule is always respected and serves as a way to prioritize rules between each other. This the 3rd iteration of this submission, but since it's now a series, I reset the revision numbering. This series implements that in a limited configuration for now, since we limit the total number of rules per port to 4. The main factors for this limitation are that : - We share the classification tables between all ports (4 max, although one is only used for internal loopback), hence we have to perform a logical separation between rules, which is done today by dedicated ranges for each port in each table - The "Flow table", which dictates which lookups operations are performed for an ingress packet, in subdivided into 22 "sub flows", each corresponding to a traffic type based on the L3 proto, L4 proto, the presence or not of a VLAN tag and the L3 fragmentation. This makes so that when adding a rule, it has to be added into each of these subflows, introducing duplications of entries and limiting our max number of entries. These limitations can be overcomed in several ways, but for readability sake, I'd rather submit basic classification offload support for now, and improve it gradually. This series also adds a small cosmetic cleanup patch (1), and also adds support for the "Drop" action compared to the first submission of this feature. It is simple enough to be added with this basic support. Compared to the first submissions, the NETIF_F_NTUPLE flag was also removed, following Saeed's comment. ==================== Signed-off-by: David S. Miller <[email protected]>
2019-05-01net: mvpp2: cls: Allow dropping packets with classification offloadMaxime Chevallier3-9/+32
This commit introduces support for the "Drop" action in classification offload. This corresponds to the "-1" action with ethtool -N. This is achieved using the color marking actions available in the C2 engine, which associate a color to a packet. These colors can be either Green, Yellow or Red, Red meaning that the packet should be dropped. Green and Yellow colors are interpreted by the Policer, which isn't supported yet. This method of dropping using the Classifier is different than the already existing early-drop features, such as VLAN filtering and MAC UC/MC filtering, which are performed during the Parsing step, and therefore take precedence over classification actions. Signed-off-by: Maxime Chevallier <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-01net: mvpp2: cls: Add Classification offload supportMaxime Chevallier4-12/+410
This commit introduces basic classification offloading support for the PPv2 controller. The PPv2 classifier has many classification engines, for now we only use the C2 TCAM match engine. This engine allows to perform ternary lookups on 64 bits keys (called Header Extracted Key), that are built by extracting fields from the packet header and concatenating them. At most 4 fields can be extracted for a single lookup. This basic implementation allows to build the HEK from the following fields : - L4 source and destination ports (for UDP and TCP) More fields are to be added in the future. Classification flows are added through the ethtool interface, using the newly introduced flow_rule infrastructure as an internal rule representation, allowing to more easily implement tc flower rules if need be. The internal design for now allocates one range of 4 rules per port due to the internal design of the flow table, which uses 22 sub-flows. When inserting a classification rule, the rule is created in every relevant sub-flow. This low rule-count is a very simple design which reaches quickly the limitations of the flow table ordering, but guarantees that the rule ordering will always be respected. This commit only introduces support for the "steer to rxq" action. Signed-off-by: Maxime Chevallier <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-01net: mvpp2: cls: Use a bitfield to represent the flow_typeMaxime Chevallier2-69/+109
As of today, the classification code is used only for RSS. We split the incoming traffic into multiple flows, that correspond to the ethtool flow_type parameter. We don't want to use the ethtool flow definitions such as TCP_V4_FLOW, for several reason : - We want to decorrelate the driver code from ethtool as much as possible, so that we can easily use other interfaces such as tc flower, - We want the flow_type to be a bitfield, so that we can match flows embedded into each other, such as TCP4 which is a subset of IP4. This commit does the conversion to the newer type. Signed-off-by: Maxime Chevallier <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-01net: mvpp2: cls: Remove extra whitespace in mvpp2_cls_flow_writeMaxime Chevallier1-3/+3
Cosmetic patch removing extra whitespaces when writing the flow_table entries Signed-off-by: Maxime Chevallier <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2019-05-01Merge branch 'mlx5-next' of ↵Saeed Mahameed28-247/+627
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux This merge commit includes some misc shared code updates from mlx5-next branch needed for net-next. 1) From Aya: Enable general events on all physical link types and restrict general event handling of subtype DELAY_DROP_TIMEOUT in mlx5 rdma driver to ethernet links only as it was intended. 2) From Eli: Introduce low level bits for prio tag mode 3) From Maor: Low level steering updates to support RDMA RX flow steering and enables RoCE loopback traffic when switchdev is enabled. 4) From Vu and Parav: Two small mlx5 core cleanups 5) From Yevgeny add HW definitions of geneve offloads Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01Merge tag 'arc-5.1-final' of ↵Linus Torvalds3-23/+25
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc Pull ARC fixes from Vineet Gupta: "A few minor fixes for ARC. - regression in memset if line size !64 - avoid panic if PAE and IOC" * tag 'arc-5.1-final' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARC: memset: fix build with L1_CACHE_SHIFT != 6 ARC: [hsdk] Make it easier to add PAE40 region to DTB ARC: PAE40: don't panic and instead turn off hw ioc
2019-05-01net/mlx5: Fix broken hca cap offsetSaeed Mahameed1-2/+2
The cited commit broke the offsets of hca cap struct, fix it. While at it, cleanup a white space introduced by the same commit. Fixes: b169e64a2444 ("net/mlx5: Geneve, Add flow table capabilities for Geneve decap with TLV options") Reported-by: Qian Cai <[email protected]> Cc: Yevgeny Kliteynik <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2019-05-01PCI/portdrv: Use shared MSI/MSI-X vector for Bandwidth ManagementAlex Williamson1-1/+2
The Interrupt Message Number in the PCIe Capabilities register (PCIe r4.0, sec 7.5.3.2) indicates which MSI/MSI-X vector is shared by interrupts related to the PCIe Capability, including Link Bandwidth Management and Link Autonomous Bandwidth Interrupts (Link Control, 7.5.3.7), Command Completed and Hot-Plug Interrupts (Slot Control, 7.5.3.10), and the PME Interrupt (Root Control, 7.5.3.12). pcie_message_numbers() checked whether we want to enable PME or Hot-Plug interrupts but neglected to check for Link Bandwidth Management, so if we only wanted the Bandwidth Management interrupts, it decided we didn't need any vectors at all. Then pcie_port_enable_irq_vec() tried to reallocate zero vectors, which failed, resulting in fallback to INTx. On some systems, e.g., an X79-based workstation, that INTx seems broken or not handled correctly, so we got spurious IRQ16 interrupts for Bandwidth Management events. Change pcie_message_numbers() so that if we want Link Bandwidth Management interrupts, we use the shared MSI/MSI-X vector from the PCIe Capabilities register. Fixes: e8303bb7a75c ("PCI/LINK: Report degraded links via link bandwidth notification") Link: https://lore.kernel.org/lkml/[email protected] Signed-off-by: Alex Williamson <[email protected]> [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas <[email protected]>
2019-05-01Merge tag 'acpi-5.1-rc8' of ↵Linus Torvalds1-5/+1
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI fix from Rafael Wysocki: "Revert a recent ACPICA change that caused initialization to fail on systems with Thunderbolt docking stations connected at the init time" * tag 'acpi-5.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: Revert "ACPICA: Clear status of GPEs before enabling them"
Powered by cgit, Gruvboxed by Blaster4385.