- 04 Jun, 2019 23 commits
-
-
Florian Westphal authored
syzbot triggered following splat when strict netlink validation is enabled: net/ipv4/devinet.c:1766 suspicious rcu_dereference_check() usage! This occurs because we hold RTNL mutex, but no rcu read lock. The second call site holds both, so just switch to the _rtnl variant. Reported-by: syzbot+bad6e32808a3a97b1515@syzkaller.appspotmail.com Fixes: 2638eb8b ("net: ipv4: provide __rcu annotation for ifa_list") Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Jiri Pirko says: ==================== expose flash update status to user When user is flashing device using devlink, he currenly does not see any information about what is going on, percentages, etc. Drivers, for example mlxsw and mlx5, have notion about the progress and what is happening. This patchset exposes this progress information to userspace. Example output for existing flash command: $ devlink dev flash pci/0000:01:00.0 file firmware.bin Preparing to flash Flashing 100% Flashing done See this console recording which shows flashing FW on a Mellanox Spectrum device: https://asciinema.org/a/247926 Please see individual patches for changelog. v2->v3 only adds tags and the last selftest patch ==================== Signed-off-by:
-
Jiri Pirko authored
Utilizes the devlink flash code. Suggested-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Acked-by:
-
Jiri Pirko authored
Signed-off-by:
-
Jiri Pirko authored
Implement mlxfw status_notify op by passing notification down to devlink. Also notify about flash update begin and end. Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Jiri Pirko authored
Add new op status_notify which is called to update the user about flashing status. Signed-off-by:
-
Jiri Pirko authored
Introduce a function to be called from drivers during flash. It sends notification to userspace about flash update progress. Signed-off-by:
-
Jiri Pirko authored
Currently the error messages are printed to dmesg. Propagate them also to directly to user doing the flashing through extack. Signed-off-by:
-
Jiri Pirko authored
Benefit from the devlink flash update implementation and ethtool fallback to it and move firmware flash implementation there. Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Jiri Pirko authored
Benefit from the devlink flash update implementation and ethtool fallback to it and move firmware flash implementation there. Signed-off-by:
-
Dinh Nguyen authored
Add option for enabling RMII phy mode. Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Wei Liang Lim <wei.liang.lim@intel.com> Signed-off-by:
Dinh Nguyen <dinguyen@kernel.org> Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== FDB updates for SJA1105 DSA driver This patch series adds: - FDB switchdev support for the second generation of switches (P/Q/R/S). I could test/code these now that I got a board with a SJA1105Q. - Management route support for SJA1105 P/Q/R/S. This is needed to send PTP/STP/management frames over the CPU port. - Logic to hide private DSA VLANs from the 'bridge fdb' commands. The new FDB code was also tested and still works on SJA1105T. ==================== Signed-off-by: -
Vladimir Oltean authored
TX VLANs and RX VLANs are an internal implementation detail of DSA for frame tagging. They work by installing special VLANs on switch ports in the operating modes where no behavior change w.r.t. VLANs can be observed by the user. Therefore it makes sense to hide these VLANs in the 'bridge fdb' command, as well as translate the pvid into the RX VID and TX VID on 'bridge fdb add' and 'bridge fdb del' commands. Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
This is a cosmetic patch that simplifies the code by removing a redundant check. A logical AND-with-zero performed on a zero is still zero. Signed-off-by:
-
Vladimir Oltean authored
This adds support for manipulating the L2 forwarding database (dump, add, delete) for the second generation of NXP SJA1105 switches. At the moment only FDB entries installed statically through 'bridge fdb' are visible in the dump callback - the dynamically learned ones are still under investigation. Signed-off-by:
-
Vladimir Oltean authored
Management routes are one-shot FDB rules installed on the CPU port for sending link-local traffic. They are a prerequisite for STP, PTP etc to work. Also make a note that removing a management route was not supported on the previous generation of switches. Signed-off-by:
-
Vladimir Oltean authored
Conceptually, if an entry is not found in the requested hardware table, it is not an invalid request - so change the error returned appropriately. Signed-off-by:
-
Vladimir Oltean authored
These are needed in order to implement the switchdev FDB callbacks. Compared to the E/T generation, not only the ABI (bit offsets) is different, but also the introduction of the HOSTCMD field which permits O(1) TCAM search for an FDB entry. Make use of the newly introduce OP_SEARCH to permit that. It will be used while adding and deleting an FDB entry (to see whether it exists or not). Signed-off-by:
-
Vladimir Oltean authored
The DSA callbacks were written with the E/T (first generation) in mind, which is quite different. For P/Q/R/S completely new implementations need to be provided, which are held as function pointers in the priv->info structure. We are taking a slightly roundabout way for this (a function from sja1105_main.c reads a structure defined in sja1105_spi.c that points to a function defined in sja1105_main.c), but it is what it is. The FDB dump callback works for both families, hence no function pointer for that. Signed-off-by:
-
Vladimir Oltean authored
Only a single dynamic configuration table of the SJA1105 P/Q/R/S supports this operation: the FDB. To keep the existing structure in place (sja1105_dynamic_config_read and sja1105_dynamic_config_write) and not introduce any new function, a convention is made for sja1105_dynamic_config_read that a negative index argument denotes a search for the entry provided as argument. Signed-off-by:
-
Vladimir Oltean authored
This appends to the L2 Forwarding and L2 Forwarding Parameters tables (originally added for first-generation switches) the bits that are new in the second generation. Signed-off-by:
-
Vladimir Oltean authored
This was inadvertently copied from the SJA1105 E/T structure and not tested. Cross-checking with the P/Q/R/S documentation (UM11040) makes it immediately obvious what the correct bit offsets for this field are. Signed-off-by:
-
Vladimir Oltean authored
This structure is merely an implementation detail and should be hidden from the sja1105_dynamic_config.h header, which provides to the rest of the driver an abstract access to the dynamic configuration interface of the switch. Signed-off-by:
-
- 03 Jun, 2019 17 commits
-
-
David S. Miller authored
Heiner Kallweit says: ==================== r8169: make firmware handling code ready to be factored out This series contains the final steps to make firmware handling code ready to be factored out into a separate source code file. ==================== Signed-off-by: -
Heiner Kallweit authored
Add rtl_fw_request_firmware and rtl_fw_release_firmware which will be part of the API when factoring out the firmware handling code. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
In preparation of factoring out the firmware handling code avoid any usage of struct rtl8169_private internals. As part of it we can inline rtl_check_firmware. Signed-off-by:
-
Heiner Kallweit authored
Similar to rtl_fw_data_ok() we can simplify the code by moving incrementing the index to the for loop initialization. Signed-off-by:
-
Heiner Kallweit authored
Replace the firmware opcode defines with a proper enum. The BUG() in rtl_fw_write_firmware() can be removed because the call to rtl_fw_data_ok() ensures all opcodes are valid. Signed-off-by:
-
David S. Miller authored
Huazhong Tan says: ==================== code optimizations & bugfixes for HNS3 driver This patch-set includes code optimizations and bugfixes for the HNS3 ethernet controller driver. [patch 1/10] removes the redundant core reset type [patch 2/10 - 3/10] fixes two VLAN related issues [patch 4/10] fixes a TM issue [patch 5/10 - 10/10] includes some patches related to RAS & MSI-X error Change log: V1->V2: removes two patches which needs to change HNS's infiniband driver as well, they will be upstreamed later with the infiniband's one. ==================== Signed-off-by: -
Weihang Li authored
All RAS and MSI-X should be enabled just in the final stage of HNS3 initialization. It means that they should be enabled in hclge_init_xxx_client_instance instead of hclge_ae_dev(). Especially MSI-X, if it is enabled before opening vector0 IRQ, there are some chances that a MSI-X error will cause failure on initialization of NIC client instane. So this patch delays enabling of HW errors. Otherwise, we also separate enabling of ROCE RAS from NIC, because it's not reasonable to enable ROCE RAS if we even don't have a ROCE driver. Signed-off-by:
Weihang Li <liweihang@hisilicon.com> Signed-off-by:
Peng Li <lipeng321@huawei.com> Signed-off-by:
Huazhong tan <tanhuazhong@huawei.com> Signed-off-by:
-
Weihang Li authored
There are four commands being used to query and clear RAS and MSI-X interrupts status. They should be contained in array of special opcodes because these commands have several descriptors, and we need to judge return value in the first descriptor rather than the last one as other opcodes. In addition, we shouldn't set the NEXT_FLAG of first descriptor. This patch fixes above issues. Signed-off-by:
-
Weihang Li authored
We shouldn't set HNAE3_NONE_RESET bit of the variable that represents a reset request during handling of MSI-X errors, or may cause issue when trigger reset. Signed-off-by:
-
Weihang Li authored
LINK_UP and LINK_DOWN are two bits of MAC tunnel interrupts, but previous HNS3 driver didn't handle them. If they were enabled, value of these two bits will change during link down and link up, which will cause HNS3 driver keep receiving IRQ but can't handle them. This patch adds handling of these two bits of interrupts, we will record and clear them as what we do to other MAC tunnel interrupts. Signed-off-by:
-
Weihang Li authored
The hclge/hclgevf and hns3 module can be unloaded independently, when hclge/hclgevf unloaded firstly, the ops of ae_dev should be set to NULL, otherwise it will cause an use-after-free problem. Fixes: 38caee9d ("net: hns3: Add support of the HNAE3 framework") Signed-off-by:
-
Weihang Li authored
If we add a VF without loading hclgevf.ko and then there is a RAS error occurs, PCIe AER will call error_detected and slot_reset of all functions, and will get a NULL pointer when we check ad_dev->ops->handle_hw_ras_error. This will cause a call trace and failures on handling of follow-up RAS errors. This patch check ae_dev and ad_dev->ops at first to solve above issues. Signed-off-by:
-
Yunsheng Lin authored
This patch sets the port shaper according to the MAC speed as suggested by hardware user manual. Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Signed-off-by:
-
Jian Shen authored
In orginal codes, the driver only restore VLAN filter entries for PF after reset, the VLAN entries of VF will lose in this case. This patch fixes it by recording VLAN IDs for each function when add VLAN, and restore the VLAN IDs after reset. Fixes: 681ec399 ("net: hns3: fix for vlan table lost problem when resetting") Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
-
Jian Shen authored
VF VLAN table can only support no more than 256 VLANs. When user adds too many VLANs, the VF VLAN table will be full, and firmware will close the VF VLAN table for the function. When VF VLAN table is full, and user keeps adding new VLANs, it's unnecessary to configure the VF VLAN table, because it will always fail, and print warning message. The worst case is adding 4K VLANs, and doing reset, it will take much time to restore these VLANs, which may cause VF reset fail by timeout. Fixes: 6c251711 ("net: hns3: Disable vf vlan filter when vf vlan table is full") Signed-off-by:
-
Huazhong Tan authored
Since core reset is similar to the global reset, so this patch removes it and uses global reset to replace it. Signed-off-by:
-
Eric Dumazet authored
syzbot reported nasty use-after-free [1] Lets remove frag_list field from structs ip_fraglist_iter and ip6_fraglist_iter. This seens not needed anyway. [1] : BUG: KASAN: use-after-free in kfree_skb_list+0x5d/0x60 net/core/skbuff.c:706 Read of size 8 at addr ffff888085a3cbc0 by task syz-executor303/8947 CPU: 0 PID: 8947 Comm: syz-executor303 Not tainted 5.2.0-rc2+ #12 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:188 __kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 kasan_report+0x12/0x20 mm/kasan/common.c:614 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132 kfree_skb_list+0x5d/0x60 net/core/skbuff.c:706 ip6_fragment+0x1ef4/0x2680 net/ipv6/ip6_output.c:882 __ip6_finish_output+0x577/0xaa0 net/ipv6/ip6_output.c:144 ip6_finish_output+0x38/0x1f0 net/ipv6/ip6_output.c:156 NF_HOOK_COND include/linux/netfilter.h:294 [inline] ip6_output+0x235/0x7f0 net/ipv6/ip6_output.c:179 dst_output include/net/dst.h:433 [inline] ip6_local_out+0xbb/0x1b0 net/ipv6/output_core.c:179 ip6_send_skb+0xbb/0x350 net/ipv6/ip6_output.c:1796 ip6_push_pending_frames+0xc8/0xf0 net/ipv6/ip6_output.c:1816 rawv6_push_pending_frames net/ipv6/raw.c:617 [inline] rawv6_sendmsg+0x2993/0x35e0 net/ipv6/raw.c:947 inet_sendmsg+0x141/0x5d0 net/ipv4/af_inet.c:802 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:671 ___sys_sendmsg+0x803/0x920 net/socket.c:2292 __sys_sendmsg+0x105/0x1d0 net/socket.c:2330 __do_sys_sendmsg net/socket.c:2339 [inline] __se_sys_sendmsg net/socket.c:2337 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2337 do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x44add9 Code: e8 7c e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 1b 05 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f826f33bce8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00000000006e7a18 RCX: 000000000044add9 RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005 RBP: 00000000006e7a10 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000006e7a1c R13: 00007ffcec4f7ebf R14: 00007f826f33c9c0 R15: 20c49ba5e353f7cf Allocated by task 8947: save_stack+0x23/0x90 mm/kasan/common.c:71 set_track mm/kasan/common.c:79 [inline] __kasan_kmalloc mm/kasan/common.c:489 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:462 kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:497 slab_post_alloc_hook mm/slab.h:437 [inline] slab_alloc_node mm/slab.c:3269 [inline] kmem_cache_alloc_node+0x131/0x710 mm/slab.c:3579 __alloc_skb+0xd5/0x5e0 net/core/skbuff.c:199 alloc_skb include/linux/skbuff.h:1058 [inline] __ip6_append_data.isra.0+0x2a24/0x3640 net/ipv6/ip6_output.c:1519 ip6_append_data+0x1e5/0x320 net/ipv6/ip6_output.c:1688 rawv6_sendmsg+0x1467/0x35e0 net/ipv6/raw.c:940 inet_sendmsg+0x141/0x5d0 net/ipv4/af_inet.c:802 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:671 ___sys_sendmsg+0x803/0x920 net/socket.c:2292 __sys_sendmsg+0x105/0x1d0 net/socket.c:2330 __do_sys_sendmsg net/socket.c:2339 [inline] __se_sys_sendmsg net/socket.c:2337 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2337 do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 8947: save_stack+0x23/0x90 mm/kasan/common.c:71 set_track mm/kasan/common.c:79 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:451 kasan_slab_free+0xe/0x10 mm/kasan/common.c:459 __cache_free mm/slab.c:3432 [inline] kmem_cache_free+0x86/0x260 mm/slab.c:3698 kfree_skbmem net/core/skbuff.c:625 [inline] kfree_skbmem+0xc5/0x150 net/core/skbuff.c:619 __kfree_skb net/core/skbuff.c:682 [inline] kfree_skb net/core/skbuff.c:699 [inline] kfree_skb+0xf0/0x390 net/core/skbuff.c:693 kfree_skb_list+0x44/0x60 net/core/skbuff.c:708 __dev_xmit_skb net/core/dev.c:3551 [inline] __dev_queue_xmit+0x3034/0x36b0 net/core/dev.c:3850 dev_queue_xmit+0x18/0x20 net/core/dev.c:3914 neigh_direct_output+0x16/0x20 net/core/neighbour.c:1532 neigh_output include/net/neighbour.h:511 [inline] ip6_finish_output2+0x1034/0x2550 net/ipv6/ip6_output.c:120 ip6_fragment+0x1ebb/0x2680 net/ipv6/ip6_output.c:863 __ip6_finish_output+0x577/0xaa0 net/ipv6/ip6_output.c:144 ip6_finish_output+0x38/0x1f0 net/ipv6/ip6_output.c:156 NF_HOOK_COND include/linux/netfilter.h:294 [inline] ip6_output+0x235/0x7f0 net/ipv6/ip6_output.c:179 dst_output include/net/dst.h:433 [inline] ip6_local_out+0xbb/0x1b0 net/ipv6/output_core.c:179 ip6_send_skb+0xbb/0x350 net/ipv6/ip6_output.c:1796 ip6_push_pending_frames+0xc8/0xf0 net/ipv6/ip6_output.c:1816 rawv6_push_pending_frames net/ipv6/raw.c:617 [inline] rawv6_sendmsg+0x2993/0x35e0 net/ipv6/raw.c:947 inet_sendmsg+0x141/0x5d0 net/ipv4/af_inet.c:802 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:671 ___sys_sendmsg+0x803/0x920 net/socket.c:2292 __sys_sendmsg+0x105/0x1d0 net/socket.c:2330 __do_sys_sendmsg net/socket.c:2339 [inline] __se_sys_sendmsg net/socket.c:2337 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2337 do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff888085a3cbc0 which belongs to the cache skbuff_head_cache of size 224 The buggy address is located 0 bytes inside of 224-byte region [ffff888085a3cbc0, ffff888085a3cca0) The buggy address belongs to the page: page:ffffea0002168f00 refcount:1 mapcount:0 mapping:ffff88821b6f63c0 index:0x0 flags: 0x1fffc0000000200(slab) raw: 01fffc0000000200 ffffea00027bbf88 ffffea0002105b88 ffff88821b6f63c0 raw: 0000000000000000 ffff888085a3c080 000000010000000c 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888085a3ca80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888085a3cb00: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc >ffff888085a3cb80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ^ ffff888085a3cc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888085a3cc80: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc Fixes: 0feca619 ("net: ipv6: add skbuff fraglist splitter") Fixes: c8b17be0 ("net: ipv4: add skbuff fraglist splitter") Signed-off-by:Eric Dumazet <edumazet@google.com> Cc: Pablo Neira Ayuso <pablo@netfilter.org> Acked-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
