- 22 Jun, 2021 33 commits
-
-
Ido Schimmel authored
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>
-
Ido Schimmel authored
'ETHTOOL_A_MODULE_EEPROM_DATA' is a binary attribute, not a nested one. Signed-off-by:
-
Ido Schimmel authored
The command is called 'ETHTOOL_MSG_MODULE_EEPROM_GET', not 'ETHTOOL_MSG_MODULE_EEPROM'. Signed-off-by:
-
gushengxian authored
Return statements are not needed in Void function. Signed-off-by:
gushengxian <gushengxian@yulong.com> Signed-off-by:
-
Kees Cook authored
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:
-
Florian Fainelli authored
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:
-
Kees Cook authored
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: -
David S. Miller authored
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: -
Sergey Ryazanov authored
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:
-
Sergey Ryazanov authored
Utilize the just introduced WWAN core feature to create a default netdev for the default data (IP MUX) channel. Signed-off-by:
-
Sergey Ryazanov authored
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 authored
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:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
Sergey Ryazanov authored
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:
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:
-
Sergey Ryazanov authored
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 authored
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 authored
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 authored
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 authored
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:
-
David S. Miller authored
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: -
Matthieu Baerts authored
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:
-
Paolo Abeni authored
Account this exceptional events for better introspection. Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Paolo Abeni authored
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 authored
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 authored
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 authored
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:
-
David S. Miller authored
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:
-
Marcin Wojtas authored
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:
-
Marcin Wojtas authored
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 authored
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 authored
Utilize the newly added helper routine for registering the MDIO bus via fwnode_ interface. Signed-off-by:
-
Marcin Wojtas authored
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 authored
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.pdfSigned-off-by:
-
Eric Dumazet authored
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: 53efbba1 ("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:
-
- 21 Jun, 2021 7 commits
-
-
Kees Cook authored
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: -
Guillaume Nault authored
Similar to commit 3b707c30 ("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:
-
Boris Sukholitko authored
This reverts commit 0dca2c74. 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:
-
Esben Haabendal authored
Fixes: f6396341 ("net: ll_temac: Avoid ndo_start_xmit returning NETDEV_TX_BUSY") Signed-off-by:
Esben Haabendal <esben@geanix.com> Signed-off-by:
-
Yejune Deng authored
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 authored
Zhou Yanjie says: ==================== Fix for Ingenic MAC support. 1.Remove the unexpected "snps,dwmac" item in the example. ==================== Signed-off-by: -
周琰杰 (Zhou Yanjie) authored
Remove the unexpected "snps,dwmac" item in the example. Fixes: 3b840106 ("dt-bindings: dwmac: Add bindings for new Ingenic SoCs.") Signed-off-by:
周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> Signed-off-by:
-
