summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-06-22ethtool: Document behavior when module EEPROM bank attribute is omittedIdo Schimmel1-0/+2
The kernel assumes bank 0 when 'ETHTOOL_MSG_MODULE_EEPROM_GET' is sent without 'ETHTOOL_A_MODULE_EEPROM_BANK'. Document it as part of the interface documentation. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22ethtool: Decrease size of module EEPROM get policy arrayIdo Schimmel1-1/+1
The 'ETHTOOL_A_MODULE_EEPROM_DATA' attribute is not part of the get request. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22ethtool: Document correct attribute typeIdo Schimmel2-2/+2
'ETHTOOL_A_MODULE_EEPROM_DATA' is a binary attribute, not a nested one. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22ethtool: Use correct command name in titleIdo Schimmel1-2/+2
The command is called 'ETHTOOL_MSG_MODULE_EEPROM_GET', not 'ETHTOOL_MSG_MODULE_EEPROM'. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22bridge: cfm: remove redundant returngushengxian1-1/+1
Return statements are not needed in Void function. Signed-off-by: gushengxian <gushengxian@yulong.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22hv_netvsc: Avoid field-overflowing memcpy()Kees Cook2-4/+3
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Add flexible array to represent start of buf_info, improving readability and avoid future warning where memcpy() thinks it is writing past the end of the structure. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22net: dsa: b53: Create default VLAN entry explicitlyFlorian Fainelli1-8/+19
In case CONFIG_VLAN_8021Q is not set, there will be no call down to the b53 driver to ensure that the default PVID VLAN entry will be configured with the appropriate untagged attribute towards the CPU port. We were implicitly relying on dsa_slave_vlan_rx_add_vid() to do that for us, instead make it explicit. Reported-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22octeontx2-af: Avoid field-overflowing memcpy()Kees Cook1-1/+1
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. To avoid having memcpy() think a u64 "prof" is being written beyond, adjust the prof member type by adding struct nix_bandprof_s to the union to match the other structs. This silences the following future warning: In file included from ./include/linux/string.h:253, from ./include/linux/bitmap.h:10, from ./include/linux/cpumask.h:12, from ./arch/x86/include/asm/cpumask.h:5, from ./arch/x86/include/asm/msr.h:11, from ./arch/x86/include/asm/processor.h:22, from ./arch/x86/include/asm/timex.h:5, from ./include/linux/timex.h:65, from ./include/linux/time32.h:13, from ./include/linux/time.h:60, from ./include/linux/stat.h:19, from ./include/linux/module.h:13, from drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c:11: In function '__fortify_memcpy_chk', inlined from '__fortify_memcpy' at ./include/linux/fortify-string.h:310:2, inlined from 'rvu_nix_blk_aq_enq_inst' at drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c:910:5: ./include/linux/fortify-string.h:268:4: warning: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); please use struct_group() [-Wattribute-warning] 268 | __write_overflow_field(); | ^~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c: ... else if (req->ctype == NIX_AQ_CTYPE_BANDPROF) memcpy(&rsp->prof, ctx, sizeof(struct nix_bandprof_s)); ... Signed-off-by: Kees Cook <keescook@chromium.org> Tested-by: Subbaraya Sundeep<sbhatta@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22Merge branch 'wwan-link-creation-improvements'David S. Miller7-108/+282
Sergey Ryazanov says: ==================== net: WWAN link creation improvements This series is intended to make the WWAN network links management easier for WWAN device drivers. The series begins with adding support for network links creation to the WWAN HW simulator to facilitate code testing. Then there are a couple of changes that prepe the WWAN core code for further modifications. The following patches (4-6) simplify driver unregistering procedures by performing the created links cleanup in the WWAN core. 7th patch is to avoid the odd hold of a driver module. Next patches (8th and 9th) make it easier for drivers to create a network interface for a default data channel. Finally, 10th patch adds support for reporting of data link (aka channel aka context) id to make user aware which network interface is bound to which WWAN device data channel. All core changes have been tested with the HW simulator. The MHI and IOSM drivers were only compile tested as I have no access to this hardware. So the coresponding patches require ACK from the driver authors. Changelog: v1 -> v2: * rebased on top of latest net-next * patch that reworks the creation of mhi_net default netdev was dropped; as Loic explained, this network device has different purpose depending on a driver mode; Loic has a plan to rework the mhi_net driver, so we will defer the default netdev creation reworkings * add a new patch that creates a default network interface for IOSM modems * 7th, 8th, 10th patches have a minor updates (see the patches for details) ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22wwan: core: add WWAN common private data for netdevSergey Ryazanov5-15/+61
The WWAN core not only multiplex the netdev configuration data, but process it too, and needs some space to store its private data associated with the netdev. Add a structure to keep common WWAN core data. The structure will be stored inside the netdev private data before WWAN driver private data and have a field to make it easier to access the driver data. Also add a helper function that simplifies drivers access to their data. At the moment we use the common WWAN private data to store the WWAN data link (channel) id at the time the link is created, and report it back to user using the .fill_info() RTNL callback. This should help the user to be aware which network interface is bound to which WWAN device data channel. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> CC: M Chetan Kumar <m.chetan.kumar@intel.com> CC: Intel Corporation <linuxwwan@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22net: iosm: create default link via WWAN coreSergey Ryazanov2-1/+5
Utilize the just introduced WWAN core feature to create a default netdev for the default data (IP MUX) channel. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> CC: M Chetan Kumar <m.chetan.kumar@intel.com> CC: Intel Corporation <linuxwwan@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22wwan: core: support default netdev creationSergey Ryazanov5-5/+86
Most, if not each WWAN device driver will create a netdev for the default data channel. Therefore, add an option for the WWAN netdev ops registration function to create a default netdev for the WWAN device. A WWAN device driver should pass a default data channel link id to the ops registering function to request the creation of a default netdev, or a special value WWAN_NO_DEFAULT_LINK to inform the WWAN core that the default netdev should not be created. For now, only wwan_hwsim utilize the default link creation option. Other drivers will be reworked next. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> CC: M Chetan Kumar <m.chetan.kumar@intel.com> CC: Intel Corporation <linuxwwan@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22wwan: core: no more hold netdev ops owning moduleSergey Ryazanov4-15/+1
The WWAN netdev ops owner holding was used to protect from the unexpected memory disappear. This approach causes a dependency cycle (driver -> core -> driver) and effectively prevents a WWAN driver unloading. E.g. WWAN hwsim could not be unloaded until all simulated devices are removed: ~# modprobe wwan_hwsim devices=2 ~# lsmod | grep wwan wwan_hwsim 16384 2 wwan 20480 1 wwan_hwsim ~# rmmod wwan_hwsim rmmod: ERROR: Module wwan_hwsim is in use ~# echo > /sys/kernel/debug/wwan_hwsim/hwsim0/destroy ~# echo > /sys/kernel/debug/wwan_hwsim/hwsim1/destroy ~# lsmod | grep wwan wwan_hwsim 16384 0 wwan 20480 1 wwan_hwsim ~# rmmod wwan_hwsim For a real device driver this will cause an inability to unload module until a served device is physically detached. Since the last commit we are removing all child netdev(s) when a driver unregister the netdev ops. This allows us to permit the driver unloading, since any sane driver will call ops unregistering on a device deinitialization. So, remove the holding of an ops owner to make it easier to unload a driver module. The owner field has also beed removed from the ops structure as there are no more users of this field. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22net: iosm: drop custom netdev(s) removingSergey Ryazanov1-14/+1
Since the last commit, the WWAN core will remove all our network interfaces for us at the time of the WWAN netdev ops unregistering. Therefore, we can safely drop the custom code that cleans the list of created netdevs. Anyway it no longer removes any netdev, since all netdevs were removed earlier in the wwan_unregister_ops() call. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Reviewed-by: M Chetan Kumar <m.chetan.kumar@intel.com> CC: M Chetan Kumar <m.chetan.kumar@intel.com> CC: Intel Corporation <linuxwwan@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22wwan: core: remove all netdevs on ops unregisteringSergey Ryazanov1-9/+31
We use the ops owner module hold to protect against ops memory disappearing. But this approach does not protect us from a driver that unregisters ops but forgets to remove netdev(s) that were created using this ops. In such case, we are left with netdev(s), which can not be removed since ops is gone. Moreover, batch netdevs removing on deinitialization is a desireable option for WWAN drivers as it is a quite common task. Implement deletion of all created links on WWAN netdev ops unregistering in the same way that RTNL removes all links on RTNL ops unregistering. Simply remove all child netdevs of a device whose WWAN netdev ops is unregistering. This way we protecting the kernel from buggy drivers and make it easier to write a driver deinitialization code. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22wwan: core: multiple netdevs deletion supportSergey Ryazanov1-1/+1
Use unregister_netdevice_queue() instead of simple unregister_netdevice() if the WWAN netdev ops does not provide a dellink callback. This will help to accelerate deletion of multiple netdevs. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22wwan: core: require WWAN netdev setup callback existenceSergey Ryazanov1-1/+1
The setup callback will be unconditionally passed to the alloc_netdev_mqs(), where the NULL pointer dereference will cause the kernel panic. So refuse to register WWAN netdev ops with warning generation if the setup callback is not provided. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Reviewed-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22wwan: core: relocate ops registering codeSergey Ryazanov1-71/+71
It is unlikely that RTNL callbacks will call WWAN ops (un-)register functions, but it is highly likely that the ops (un-)register functions will use RTNL link create/destroy handlers. So move the WWAN network interface ops (un-)register functions below the RTNL callbacks to be able to call them without forward declarations. No functional changes, just code relocation. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22wwan_hwsim: support network interface creationSergey Ryazanov1-0/+48
Add support for networking interface creation via the WWAN core by registering the WWAN netdev creation ops for each simulated WWAN device. Implemented minimalistic netdev support where the xmit callback just consumes all egress skbs. This should help with WWAN network interfaces creation testing. Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22Merge branch 'mptcp-optimizations'David S. Miller7-121/+62
Mat Martineau says: ==================== mptcp: A few optimizations Here is a set of patches that we've accumulated and tested in the MPTCP tree. Patch 1 removes the MPTCP-level tx skb cache that added complexity but did not provide a meaningful benefit. Patch 2 uses the fast socket lock in more places. Patch 3 improves handling of a data-ready flag. Patch 4 deletes an unnecessary and racy connection state check. Patch 5 adds a MIB counter for one type of invalid MPTCP header. Patch 6 improves self test failure output. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22selftests: mptcp: display proper reason to abort testsMatthieu Baerts1-16/+36
Without this modification, we were often displaying this error messages: FAIL: Could not even run loopback test But $ret could have been set to a non 0 value in many different cases: - net.mptcp.enabled=0 is not working as expected - setsockopt(..., TCP_ULP, "mptcp", ...) is allowed - ping between each netns are failing - tests between ns1 as a receiver and ns>1 are failing - other tests not involving ns1 as a receiver are failing So not only for the loopback test. Now a clearer message, including the time it took to run all tests, is displayed. Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22mptcp: add MIB counter for invalid mappingPaolo Abeni3-1/+5
Account this exceptional events for better introspection. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22mptcp: drop redundant test in move_skbs_to_msk()Paolo Abeni1-3/+0
Currently we check the msk state to avoid enqueuing new skbs at msk shutdown time. Such test is racy - as we can't acquire the msk socket lock - and useless, as the caller already checked the subflow field 'disposable', covering the same scenario in a race free manner - read and updated under the ssk socket lock. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22mptcp: don't clear MPTCP_DATA_READY in sk_wait_event()Paolo Abeni1-4/+2
If we don't flush entirely the receive queue, we need set again such bit later. We can simply avoid clearing it. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22mptcp: use fast lock for subflows when possiblePaolo Abeni2-10/+15
There are a bunch of callsite where the ssk socket lock is acquired using the full-blown version eligible for the fast variant. Let's move to the latter. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22mptcp: drop tx skb cachePaolo Abeni2-87/+4
The mentioned cache was introduced to reduce the number of skb allocation in atomic context, but the required complexity is excessive. This change remove the mentioned cache. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22Merge branch 'marvell-mdio-ACPI'David S. Miller8-23/+125
Marcin Wojtas says: ==================== ACPI MDIO support for Marvell controllers The third version of the patchset main change is dropping a clock handling optimisation patch for mvmdio driver. Other than that it sets explicit dependency on FWNODE_MDIO for CONFIG_FSL_XGMAC_MDIO and applies minor cosmetic improvements (please see the 'Changelog' below). The firmware ACPI description is exposed in the public github branch: https://github.com/semihalf-wojtas-marcin/edk2-platforms/commits/acpi-mdio-r20210613 There is also MacchiatoBin firmware binary available for testing: https://drive.google.com/file/d/1eigP_aeM4wYQpEaLAlQzs3IN_w1-kQr0 I'm looking forward to the comments or remarks. Best regards, Marcin Changelog: v2->v3 * Rebase on top of net-next/master. * Drop "net: mvmdio: simplify clock handling" patch. * 1/6 - fix code block comments. * 2/6 - unchanged * 3/6 - add "depends on FWNODE_MDIO" for CONFIG_FSL_XGMAC_MDIO * 4/6 - drop mention about the clocks from the commit message. * 5/6 - unchanged * 6/6 - add Andrew's RB. v1->v2 * 1/7 - new patch * 2/7 - new patch * 3/7 - new patch * 4/7 - new patch * 5/7 - remove unnecessary `if (has_acpi_companion())` and rebase onto the new clock handling * 6/7 - remove deprecated comment * 7/7 - no changes ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22net: mvpp2: remove unused 'has_phy' fieldMarcin Wojtas2-4/+0
The 'has_phy' field from struct mvpp2_port is no longer used. Remove it. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22net: mvpp2: enable using phylink with ACPIMarcin Wojtas1-5/+17
Now that the MDIO and phylink are supported in the ACPI world, enable to use them in the mvpp2 driver. Ensure a backward compatibility with the firmware whose ACPI description does not contain the necessary elements for the proper phy handling and fall back to relying on the link interrupts instead. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22net: mvmdio: add ACPI supportMarcin Wojtas1-2/+12
This patch introducing ACPI support for the mvmdio driver by adding acpi_match_table with two entries: * "MRVL0100" for the SMI operation * "MRVL0101" for the XSMI mode Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22net/fsl: switch to fwnode_mdiobus_registerMarcin Wojtas2-12/+3
Utilize the newly added helper routine for registering the MDIO bus via fwnode_ interface. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22net: mdiobus: Introduce fwnode_mdbiobus_register()Marcin Wojtas2-0/+34
This patch introduces a new helper function that wraps acpi_/of_ mdiobus_register() and allows its usage via common fwnode_ interface. Fall back to raw mdiobus_register() in case CONFIG_FWNODE_MDIO is not enabled, in order to satisfy compatibility in all future user drivers. Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22Documentation: ACPI: DSD: describe additional MAC configurationMarcin Wojtas1-0/+59
Document additional MAC configuration modes which can be processed by the existing fwnode_ phylink helpers: * "managed" standard ACPI _DSD property [1] * "fixed-link" data-only subnode linked in the _DSD package via generic mechanism of the hierarchical data extension [2] [1] https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf [2] https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22virtio/vsock: avoid NULL deref in virtio_transport_seqpacket_allow()Eric Dumazet1-1/+3
Make sure the_virtio_vsock is not NULL before dereferencing it. general protection fault, probably for non-canonical address 0xdffffc0000000071: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000388-0x000000000000038f] CPU: 0 PID: 8452 Comm: syz-executor406 Not tainted 5.13.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:virtio_transport_seqpacket_allow+0xbf/0x210 net/vmw_vsock/virtio_transport.c:503 Code: e8 c6 d9 ab f8 84 db 0f 84 0f 01 00 00 e8 09 d3 ab f8 48 8d bd 88 03 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 2a 01 00 00 44 0f b6 a5 88 03 00 00 RSP: 0018:ffffc90003757c18 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000071 RSI: ffffffff88c908e7 RDI: 0000000000000388 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff88c90a06 R11: 0000000000000000 R12: 0000000000000000 R13: ffffffff88c90840 R14: 0000000000000000 R15: 0000000000000001 FS: 0000000001bee300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000082 CR3: 000000002847e000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vsock_assign_transport+0x575/0x700 net/vmw_vsock/af_vsock.c:490 vsock_connect+0x200/0xc00 net/vmw_vsock/af_vsock.c:1337 __sys_connect_file+0x155/0x1a0 net/socket.c:1824 __sys_connect+0x161/0x190 net/socket.c:1841 __do_sys_connect net/socket.c:1851 [inline] __se_sys_connect net/socket.c:1848 [inline] __x64_sys_connect+0x6f/0xb0 net/socket.c:1848 do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x43ee69 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 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 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd49e7c788 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000000400488 RCX: 000000000043ee69 RDX: 0000000000000010 RSI: 0000000020000080 RDI: 0000000000000003 RBP: 0000000000402e50 R08: 0000000000000000 R09: 0000000000400488 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000402ee0 R13: 0000000000000000 R14: 00000000004ac018 R15: 0000000000400488 Fixes: 53efbba12cc7 ("virtio/vsock: enable SEQPACKET for transport") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Arseny Krasnov <arseny.krasnov@kaspersky.com> Reported-by: syzbot <syzkaller@googlegroups.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22ibmvnic: Use strscpy() instead of strncpy()Kees Cook1-3/+3
Since these strings are expected to be NUL-terminated and the buffers are exactly sized (in vnic_client_data_len()) with no padding, strncpy() can be safely replaced with strscpy() here, as strncpy() on NUL-terminated string is considered deprecated[1]. This has the side-effect of silencing a -Warray-bounds warning due to the compiler being confused about the vlcd incrementing: In file included from ./include/linux/string.h:253, from ./include/linux/bitmap.h:10, from ./include/linux/cpumask.h:12, from ./include/linux/mm_types_task.h:14, from ./include/linux/mm_types.h:5, from ./include/linux/buildid.h:5, from ./include/linux/module.h:14, from drivers/net/ethernet/ibm/ibmvnic.c:35: In function '__fortify_strncpy', inlined from 'vnic_add_client_data' at drivers/net/ethernet/ibm/ibmvnic.c:3919:2: ./include/linux/fortify-string.h:39:30: warning: '__builtin_strncpy' offset 12 from the object at 'v lcd' is out of the bounds of referenced subobject 'name' with type 'char[]' at offset 12 [-Warray-bo unds] 39 | #define __underlying_strncpy __builtin_strncpy | ^ ./include/linux/fortify-string.h:51:9: note: in expansion of macro '__underlying_strncpy' 51 | return __underlying_strncpy(p, q, size); | ^~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/ibm/ibmvnic.c: In function 'vnic_add_client_data': drivers/net/ethernet/ibm/ibmvnic.c:3883:7: note: subobject 'name' declared here 3883 | char name[]; | ^~~~ [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings Cc: Dany Madden <drt@linux.ibm.com> Cc: Sukadev Bhattiprolu <sukadev@linux.ibm.com> Cc: Thomas Falcon <tlfalcon@linux.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: netdev@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22net: handle ARPHRD_IP6GRE in dev_is_mac_header_xmit()Guillaume Nault1-0/+1
Similar to commit 3b707c3008ca ("net: dev_is_mac_header_xmit() true for ARPHRD_RAWIP"), add ARPHRD_IP6GRE to dev_is_mac_header_xmit(), to make ip6gre compatible with act_mirred and __bpf_redirect(). Signed-off-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22Revert "net/sched: cls_flower: Remove match on n_proto"Boris Sukholitko1-1/+2
This reverts commit 0dca2c7404a938cb10c85d0515cee40ed5348788. The commit in question breaks hardware offload of flower filters. Quoting Vladimir Oltean <olteanv@gmail.com>: fl_hw_replace_filter() and fl_reoffload() create a struct flow_cls_offload with a rule->match.mask member derived from the mask of the software classifier: &f->mask->key - that same mask that is used for initializing the flow dissector keys, and the one from which Boris removed the basic.n_proto member because it was bothering him. Reported-by: Vadym Kochan <vadym.kochan@plvision.eu> Signed-off-by: Boris Sukholitko <boris.sukholitko@broadcom.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22net: ll_temac: Remove left-over debug messageEsben Haabendal1-3/+1
Fixes: f63963411942 ("net: ll_temac: Avoid ndo_start_xmit returning NETDEV_TX_BUSY") Signed-off-by: Esben Haabendal <esben@geanix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22net: add pf_family_names[] for protocol familyYejune Deng1-2/+50
Modify the pr_info content from int to char * in sock_register() and sock_unregister(), this looks more readable. Fixed build error in ARCH=sparc64. Signed-off-by: Yejune Deng <yejune.deng@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22Merge branch 'ingenic-fixes'David S. Miller1-1/+1
Zhou Yanjie says: ==================== Fix for Ingenic MAC support. 1.Remove the unexpected "snps,dwmac" item in the example. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22dt-bindings: dwmac: Remove unexpected item.周琰杰 (Zhou Yanjie)1-1/+1
Remove the unexpected "snps,dwmac" item in the example. Fixes: 3b8401066e5a ("dt-bindings: dwmac: Add bindings for new Ingenic SoCs.") Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22net: hns3: Fix a memory leak in an error handling path in ↵Christophe JAILLET1-2/+4
'hclge_handle_error_info_log()' If this 'kzalloc()' fails we must free some resources as in all the other error handling paths of this function. Fixes: 2e2deee7618b ("net: hns3: add the RAS compatibility adaptation solution") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Jiaran Zhang <zhangjiaran@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22Merge branch 'fec-tx'David S. Miller2-5/+43
Joakim Zhang says: ==================== net: fec: fix TX bandwidth fluctuations This patch set intends to fix TX bandwidth fluctuations, any feedback would be appreciated. --- ChangeLogs: V1: remove RFC tag, RFC discussions please turn to below: https://lore.kernel.org/lkml/YK0Ce5YxR2WYbrAo@lunn.ch/T/ V2: change functions to be static in this patch set. And add the t-b tag. V3: fix sparse warining: ntohs()->htons() ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22net: fec: add ndo_select_queue to fix TX bandwidth fluctuationsFugang Duan1-0/+32
As we know that AVB is enabled by default, and the ENET IP design is queue 0 for best effort, queue 1&2 for AVB Class A&B. Bandwidth of each queue 1&2 set in driver is 50%, TX bandwidth fluctuated when selecting tx queues randomly with FEC_QUIRK_HAS_AVB quirk available. This patch adds ndo_select_queue callback to select queues for transmitting to fix this issue. It will always return queue 0 if this is not a vlan packet, and return queue 1 or 2 based on priority of vlan packet. You may complain that in fact we only use single queue for trasmitting if we are not targeted to VLAN. Yes, but seems we have no choice, since AVB is enabled when the driver probed, we can't switch this feature dynamicly. After compare multiple queues to single queue, TX throughput almost no improvement. One way we can implemet is to configure the driver to multiple queues with Round-robin scheme by default. Then add ndo_setup_tc callback to enable/disable AVB feature for users. Unfortunately, ENET AVB IP seems not follow the standard 802.1Qav spec. We only can program DMAnCFG[IDLE_SLOPE] field to calculate bandwidth fraction. And idle slope is restricted to certain valus (a total of 19). It's far away from CBS QDisc implemented in Linux TC framework. If you strongly suggest to do this, I think we only can support limited numbers of bandwidth and reject others, but it's really urgly and wried. With this patch, VLAN tagged packets route to queue 0/1/2 based on vlan priority; VLAN untagged packets route to queue 0. Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> Reported-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Fugang Duan <fugang.duan@nxp.com> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-22net: fec: add FEC_QUIRK_HAS_MULTI_QUEUES represents i.MX6SX ENET IPJoakim Zhang2-5/+11
Frieder Schrempf reported a TX throuthput issue [1], it happens quite often that the measured bandwidth in TX direction drops from its expected/nominal value to something like ~50% (for 100M) or ~67% (for 1G) connections. [1] https://lore.kernel.org/linux-arm-kernel/421cc86c-b66f-b372-32f7-21e59f9a98bc@kontron.de/ The issue becomes clear after digging into it, Net core would select queues when transmitting packets. Since FEC have not impletemented ndo_select_queue callback yet, so it will call netdev_pick_tx to select queues randomly. For i.MX6SX ENET IP with AVB support, driver default enables this feature. According to the setting of QOS/RCMRn/DMAnCFG registers, AVB configured to Credit-based scheme, 50% bandwidth of each queue 1&2. With below tests let me think more: 1) With FEC_QUIRK_HAS_AVB quirk, can reproduce TX bandwidth fluctuations issue. 2) Without FEC_QUIRK_HAS_AVB quirk, can't reproduce TX bandwidth fluctuations issue. The related difference with or w/o FEC_QUIRK_HAS_AVB quirk is that, whether we program FTYPE field of TxBD or not. As I describe above, AVB feature is enabled by default. With FEC_QUIRK_HAS_AVB quirk, frames in queue 0 marked as non-AVB, and frames in queue 1&2 marked as AVB Class A&B. It's unreasonable if frames in queue 1&2 are not required to be time-sensitive. So when Net core select tx queues ramdomly, Credit-based scheme would work and lead to TX bandwidth fluctuated. On the other hand, w/o FEC_QUIRK_HAS_AVB quirk, frames in queue 1&2 are all marked as non-AVB, so Credit-based scheme would not work. Till now, how can we fix this TX throughput issue? Yes, please remove FEC_QUIRK_HAS_AVB quirk if you suffer it from time-nonsensitive networking. However, this quirk is used to indicate i.MX6SX, other setting depends on it. So this patch adds a new quirk FEC_QUIRK_HAS_MULTI_QUEUES to represent i.MX6SX, it is safe for us remove FEC_QUIRK_HAS_AVB quirk now. FEC_QUIRK_HAS_AVB quirk is set by default in the driver, and users may not know much about driver details, they would waste effort to find the root cause, that is not we want. The following patch is a implementation to fix it and users don't need to modify the driver. Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> Reported-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-21Merge branch 'dsa-cross-chip'David S. Miller6-103/+53
Vladimir Oltean says: ==================== Improvement for DSA cross-chip setups This series improves some aspects in multi-switch DSA tree topologies: - better device tree validation - better handling of MTU changes - better handling of multicast addresses - removal of some unused code ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-21net: dsa: remove cross-chip support from the MRP notifiersVladimir Oltean1-48/+7
With MRP hardware assist being supported only by the ocelot switch family, which by design does not support cross-chip bridging, the current match functions are at best a guess and have not been confirmed in any way to do anything relevant in a multi-switch topology. Drop the code and make the notifiers match only on the targeted switch port. Cc: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-21net: dsa: targeted MTU notifiers should only match on one portVladimir Oltean4-11/+15
dsa_slave_change_mtu() calls dsa_port_mtu_change() twice: - it sends a cross-chip notifier with the MTU of the CPU port which is used to update the DSA links. - it sends one targeted MTU notifier which is supposed to only match the user port on which we are changing the MTU. The "propagate_upstream" variable is used here to bypass the cross-chip notifier system from switch.c But due to a mistake, the second, targeted notifier matches not only on the user port, but also on the DSA link which is a member of the same switch, if that exists. And because the DSA links of the entire dst were programmed in a previous round to the largest_mtu via a "propagate_upstream == true" notification, then the dsa_port_mtu_change(propagate_upstream == false) call that is immediately upcoming will break the MTU on the one DSA link which is chip-wise local to the dp whose MTU is changing right now. Example given this daisy chain topology: sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 [ cpu ] [ user ] [ user ] [ dsa ] [ user ] [ x ] [ ] [ ] [ x ] [ ] | +---------+ | sw1p0 sw1p1 sw1p2 sw1p3 sw1p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] [ ] [ ] [ ] [ ] [ x ] ip link set sw0p1 mtu 9000 ip link set sw1p1 mtu 9000 # at this stage, sw0p1 and sw1p1 can talk # to one another using jumbo frames ip link set sw0p2 mtu 1500 # this programs the sw0p3 DSA link first to # the largest_mtu of 9000, then reprograms it to # 1500 with the "propagate_upstream == false" # notifier, breaking communication between # sw0p1 and sw1p1 To escape from this situation, make the targeted match really match on a single port - the user port, and rename the "propagate_upstream" variable to "targeted_match" to clarify the intention and avoid future issues. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-21net: dsa: calculate the largest_mtu across all ports in the treeVladimir Oltean1-6/+7
If we have a cross-chip topology like this: sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 [ cpu ] [ user ] [ user ] [ dsa ] [ user ] | +---------+ | sw1p0 sw1p1 sw1p2 sw1p3 sw1p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] and we issue the following commands: 1. ip link set sw0p1 mtu 1700 2. ip link set sw1p1 mtu 1600 we notice the following happening: Command 1. emits a non-targeted MTU notifier for the CPU port (sw0p0) with the largest_mtu calculated across switch 0, of 1700. This matches sw0p0, sw0p3 and sw1p4 (all CPU ports and DSA links). Then, it emits a targeted MTU notifier for the user port (sw0p1), again with MTU 1700 (this doesn't matter). Command 2. emits a non-targeted MTU notifier for the CPU port (sw0p0) with the largest_mtu calculated across switch 1, of 1600. This matches the same group of ports as above, and decreases the MTU for the CPU port and the DSA links from 1700 to 1600. As a result, the sw0p1 user port can no longer communicate with its CPU port at MTU 1700. To address this, we should calculate the largest_mtu across all switches that may share a CPU port, and only emit MTU notifiers with that value. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-21net: dsa: execute dsa_switch_mdb_add only for routing port in cross-chip ↵Vladimir Oltean1-23/+2
topologies Currently, the notifier for adding a multicast MAC address matches on the targeted port and on all DSA links in the system, be they upstream or downstream links. This leads to a considerable amount of useless traffic. Consider this daisy chain topology, and a MDB add notifier emitted on sw0p0. It matches on sw0p0, sw0p3, sw1p3 and sw2p4. sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 [ user ] [ user ] [ user ] [ dsa ] [ cpu ] [ x ] [ ] [ ] [ x ] [ ] | +---------+ | sw1p0 sw1p1 sw1p2 sw1p3 sw1p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] [ ] [ ] [ ] [ x ] [ x ] | +---------+ | sw2p0 sw2p1 sw2p2 sw2p3 sw2p4 [ user ] [ user ] [ user ] [ user ] [ dsa ] [ ] [ ] [ ] [ ] [ x ] But switch 0 has no reason to send the multicast traffic for that MAC address on sw0p3, which is how it reaches switches 1 and 2. Those switches don't expect, according to the user configuration, to receive this multicast address from switch 1, and they will drop it anyway, because the only valid destination is the port they received it on. They only need to configure themselves to deliver that multicast address _towards_ switch 1, where the MDB entry is installed. Similarly, switch 1 should not send this multicast traffic towards sw1p3, because that is how it reaches switch 2. With this change, the heat map for this MDB notifier changes as follows: sw0p0 sw0p1 sw0p2 sw0p3 sw0p4 [ user ] [ user ] [ user ] [ dsa ] [ cpu ] [ x ] [ ] [ ] [ ] [ ] | +---------+ | sw1p0 sw1p1 sw1p2 sw1p3 sw1p4 [ user ] [ user ] [ user ] [ dsa ] [ dsa ] [ ] [ ] [ ] [ ] [ x ] | +---------+ | sw2p0 sw2p1 sw2p2 sw2p3 sw2p4 [ user ] [ user ] [ user ] [ user ] [ dsa ] [ ] [ ] [ ] [ ] [ x ] Now the mdb notifier behaves the same as the fdb notifier. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.0) at 2024-08-16 21:25:17 +0300