- 23 Jan, 2021 28 commits
-
-
Arjun Roy authored
At present, tcp_recvmsg() uses flags to track if any CMSGs are pending and what those CMSGs are. These flags are currently magic numbers, used only within tcp_recvmsg(). To prepare for receive timestamp support in tcp receive zerocopy, gently refactor these magic numbers into enums. Signed-off-by:
Arjun Roy <arjunroy@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Nikolay Aleksandrov says: ==================== net: bridge: multicast: add initial EHT support This set adds explicit host tracking support for IGMPv3/MLDv2. The already present per-port fast leave flag is used to enable it since that is the primary goal of EHT, to track a group and its S,Gs usage per-host and when left without any interested hosts delete them before the standard timers. The EHT code is pretty self-contained and not enabled by default. There is no new uAPI added, all of the functionality is currently hidden behind the fast leave flag. In the future that will change (more below). The host tracking uses two new sets per port group: one having an entry for each host which contains that host's view of the group (source list and filter mode), and one set which contains an entry for each source having an internal set which contains an entry for each host that has reported an interest for that source. RB trees are used for all sets so they're compact when not used and fast when we need to do lookups. To illustrate it: [ bridge port group ] ` [ host set (rb) ] ` [ host entry with a list of sources and filter mode ] ` [ source set (rb) ] ` [ source entry ] ` [ source host set (rb) ] ` [ source host entry with a timer ] The number of tracked sources per host is limited to the maximum total number of S,G entries per port group - PG_SRC_ENT_LIMIT (currently 32). The number of hosts is unlimited, I think the argument that a local attacker can exhaust the memory/cause high CPU usage can be applied to fdb entries as well which are unlimited. In the future if needed we can add an option to limit these, but I don't think it's necessary for a start. All of the new sets are protected by the bridge's multicast lock. I'm pretty sure we'll be changing the cases and improving the convergence time in the future, but this seems like a good start. Patch breakdown: patch 1 - 4: minor cleanups and preparations for EHT patch 5: adds the new structures which will be used in the following patches patch 6: adds support to create, destroy and lookup host entries patch 7: adds support to create, delete and lokup source set entries patch 8: adds a host "delete" function which is just a host's source list flush since that would automatically delete the host patch 9 - 10: add support for handling all IGMPv3/MLDv2 report types more information can be found in the individual patches patch 11: optmizes a specific TO_INCLUDE use-case with host timeouts patch 12: handles per-host filter mode changing (include <-> exclude) patch 13: pulls out block group deletion since now it can be deleted in both filter modes patch 14: marks deletions done due to fast leave Future plans: - export host information - add an option to reduce queries - add an option to limit the number of host entries - tune more fast leave cases for quicker convergence By the way I think this is the first open-source EHT implementation, I couldn't find any while researching it. :) ==================== Link: https://lore.kernel.org/r/20210120145203.1109140-1-razor@blackwall.orgSigned-off-by: -
Nikolay Aleksandrov authored
Mark groups which were deleted due to fast leave/EHT. Signed-off-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
-
Nikolay Aleksandrov authored
A block report can result in empty source and host sets for both include and exclude groups so if there are no hosts left we can safely remove the group. Pull the block group handling so it can cover both cases and add a check if EHT requires the delete. Signed-off-by:
-
Nikolay Aleksandrov authored
We should be able to handle host filter mode changing. For exclude mode we must create a zero-src entry so the group will be kept even without any S,G entries (non-zero source sets). That entry doesn't count to the entry limit and can always be created, its timer is refreshed on new exclude reports and if we change the host filter mode to include then it gets removed and we rely only on the non-zero source sets. Signed-off-by:
-
Nikolay Aleksandrov authored
This is an optimization specifically for TO_INCLUDE which sends queries for the older entries and thus lowers the S,G timers to LMQT. If we have the following situation for a group in either include or exclude mode: - host A was interested in srcs X and Y, but is timing out - host B sends TO_INCLUDE src Z, the bridge lowers X and Y's timeouts to LMQT - host B sends BLOCK src Z after LMQT time has passed => since host B is the last host we can delete the group, but if we still have host A's EHT entries for X and Y (i.e. if they weren't lowered to LMQT previously) then we'll have to wait another LMQT time before deleting the group, with this optimization we can directly remove it regardless of the group mode as there are no more interested hosts Signed-off-by: -
Nikolay Aleksandrov authored
Add support for IGMPv3/MLDv2 include and exclude EHT handling. Similar to how the reports are processed we have 2 cases when the group is in include or exclude mode, these are processed as follows: - group include - is_include: create missing entries - to_include: flush existing entries and create a new set from the report, obviously if the src set is empty then we delete the group - group exclude - is_exclude: create missing entries - to_exclude: flush existing entries and create a new set from the report, any empty source set entries are removed If the group is in a different mode then we just flush all entries reported by the host and we create a new set with the new mode entries created from the report. If the report is include type, the source list is empty and the group has empty sources' set then we remove it. Any source set entries which are empty are removed as well. If the group is in exclude mode it can exist without any S,G entries (allowing for all traffic to pass). Signed-off-by: -
Nikolay Aleksandrov authored
Add support for IGMPv3/MLDv2 allow/block EHT handling. Similar to how the reports are processed we have 2 cases when the group is in include or exclude mode, these are processed as follows: - group include - allow: create missing entries - block: remove existing matching entries and remove the corresponding S,G entries if there are no more set host entries, then possibly delete the whole group if there are no more S,G entries - group exclude - allow - host include: create missing entries - host exclude: remove existing matching entries and remove the corresponding S,G entries if there are no more set host entries - block - host include: remove existing matching entries and remove the corresponding S,G entries if there are no more set host entries, then possibly delete the whole group if there are no more S,G entries - host exclude: create missing entries Signed-off-by: -
Nikolay Aleksandrov authored
Now that we can delete set entries, we can use that to remove EHT hosts. Since the group's host set entries exist only when there are related source set entries we just have to flush all source set entries joined by the host set entry and it will be automatically removed. Signed-off-by:
-
Nikolay Aleksandrov authored
Add EHT source set and set-entry create, delete and lookup functions. These allow to manipulate source sets which contain their own host sets with entries which joined that S,G. We're limiting the maximum number of tracked S,G entries per host to PG_SRC_ENT_LIMIT (currently 32) which is the current maximum of S,G entries for a group. There's a per-set timer which will be used to destroy the whole set later. Signed-off-by:
-
Nikolay Aleksandrov authored
Add functions to create, destroy and lookup an EHT host. These are per-host entries contained in the eht_host_tree in net_bridge_port_group which are used to store a list of all sources (S,G) entries joined for that group by each host, the host's current filter mode and total number of joined entries. No functional changes yet, these would be used in later patches. Signed-off-by:
-
Nikolay Aleksandrov authored
Add EHT structures for tracking hosts and sources per group. We keep one set for each host which has all of the host's S,G entries, and one set for each multicast source which has all hosts that have joined that S,G. For each host, source entry we record the filter_mode and we keep an expiry timer. There is also one global expiry timer per source set, it is updated with each set entry update, it will be later used to lower the set's timer instead of lowering each entry's timer separately. Signed-off-by:
-
Nikolay Aleksandrov authored
We need to preserve the srcs pointer since we'll be passing it for EHT handling later. Signed-off-by:
-
Nikolay Aleksandrov authored
Prepare __grp_src_block_incl() for being able to cause a notification due to changes. Currently it cannot happen, but EHT would change that since we'll be deleting sources immediately. Make sure that if the pg is deleted we don't return true as that would cause the caller to access freed pg. This patch shouldn't cause any functional change. Signed-off-by:
-
Nikolay Aleksandrov authored
We need to pass the host address so later it can be used for explicit host tracking. No functional change. Signed-off-by:
-
Nikolay Aleksandrov authored
Rename src_size argument to addr_size in preparation for passing host address as an argument to IGMPv3/MLDv2 functions. No functional change. Signed-off-by:
-
Xin Long authored
Commit fa821170 ("net: add inline function skb_csum_is_sctp") missed replacing skb->csum_not_inet check in hns3. This patch is to replace it with skb_csum_is_sctp(). Reported-by:
Xin Long <lucien.xin@gmail.com> Link: https://lore.kernel.org/r/3ad3c22c08beb0947f5978e790bd98d2aa063df9.1611307861.git.lucien.xin@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Paolo Abeni says: ==================== mptcp: re-enable sndbuf autotune The sendbuffer autotuning was unintentionally disabled as a side effect of the recent workqueue removal refactor. These patches re-enable id, with some extra care: with autotuning enable/large send buffer we need a more accurate packet scheduler to be able to use efficiently the available subflow bandwidth, especially when the subflows have different capacities. The first patch cleans-up subflow socket handling, making the actual re-enable (patch 2) simpler. Patches 3 and 4 improve the packet scheduler, to better cope with non trivial scenarios and large send buffer. Finally patch 5 adds and uses some infrastructure to avoid the workqueue usage for the packet scheduler operations introduced by the previous patches. ==================== Link: https://lore.kernel.org/r/cover.1611153172.git.pabeni@redhat.comSigned-off-by:
-
Paolo Abeni authored
On MPTCP-level ack reception, the packet scheduler may select a subflow other then the current one. Prior to this commit we rely on the workqueue to trigger action on such subflow. This changeset introduces an infrastructure that allows any MPTCP subflow to schedule actions (MPTCP xmit) on others subflows without resorting to (multiple) process reschedule. A dummy NAPI instance is used instead. When MPTCP needs to trigger action an a different subflow, it enqueues the target subflow on the NAPI backlog and schedule such instance as needed. The dummy NAPI poll method walks the sockets backlog and tries to acquire the (BH) socket lock on each of them. If the socket is owned by the user space, the action will be completed by the sock release cb, otherwise push is started. This change leverages the delegated action infrastructure to avoid invoking the MPTCP worker to spool the pending data, when the packet scheduler picks a subflow other then the one currently processing the incoming MPTCP-level ack. Additionally we further refine the subflow selection invoking the packet scheduler for each chunk of data even inside __mptcp_subflow_push_pending(). v1 -> v2: - fix possible UaF at shutdown time, resetting sock ops after removing the ulp context Reviewed-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Paolo Abeni authored
Otherwise the packet scheduler policy will not be enforced when pushing pending data at MPTCP-level ack reception time. Reviewed-by:
-
Paolo Abeni authored
The current packet scheduler can enqueue up to sndbuf data on each subflow. If the send buffer is large and the subflows are not symmetric, this could lead to suboptimal aggregate bandwidth utilization. Limit the amount of queued data to the maximum send window. Reviewed-by:
-
Paolo Abeni authored
After commit 6e628cd3 ("mptcp: use mptcp release_cb for delayed tasks"), MPTCP never sets the flag bit SOCK_NOSPACE on its subflow. As a side effect, autotune never takes place, as it happens inside tcp_new_space(), which in turn is called only when the mentioned bit is set. Let's sendmsg() set the subflows NOSPACE bit when looking for more memory and use the subflow write_space callback to propagate the snd buf update and wake-up the user-space. Additionally, this allows dropping a bunch of duplicate code and makes the SNDBUF_LIMITED chrono relevant again for MPTCP subflows. Fixes: 6e628cd3 ("mptcp: use mptcp release_cb for delayed tasks") Reviewed-by:
-
Paolo Abeni authored
Currently, incoming subflows link to the parent socket, while outgoing ones link to a per subflow socket. The latter is not really needed, except at the initial connect() time and for the first subflow. Always graft the outgoing subflow to the parent socket and free the unneeded ones early. This allows some code cleanup, reduces the amount of memory used and will simplify the next patch Reviewed-by:
-
Ivan Babrou authored
Without this change the driver tries to allocate too many queues, breaching the number of available msi-x interrupts on machines with many logical cpus and default adapter settings: Insufficient resources for 12 XDP event queues (24 other channels, max 32) Which in turn triggers EINVAL on XDP processing: sfc 0000:86:00.0 ext0: XDP TX failed (-22) Signed-off-by:
Ivan Babrou <ivan@cloudflare.com> Acked-by:
Edward Cree <ecree.xilinx@gmail.com> Link: https://lore.kernel.org/r/20210120212759.81548-1-ivan@cloudflare.comSigned-off-by:
-
Yousuk Seung authored
This patch adds TCP_NLA_TTL to SCM_TIMESTAMPING_OPT_STATS that exports the time-to-live or hop limit of the latest incoming packet with SCM_TSTAMP_ACK. The value exported may not be from the packet that acks the sequence when incoming packets are aggregated. Exporting the time-to-live or hop limit value of incoming packets helps to estimate the hop count of the path of the flow that may change over time. Signed-off-by:
Yousuk Seung <ysseung@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Neal Cardwell <ncardwell@google.com> Link: https://lore.kernel.org/r/20210120204155.552275-1-ysseung@google.comSigned-off-by:
-
Pengcheng Yang authored
Since the early retransmit has been removed by commit bec41a11 ("tcp: remove early retransmit"), we also remove the unused ICSK_TIME_EARLY_RETRANS macro. Signed-off-by:
Pengcheng Yang <yangpc@wangsu.com> Signed-off-by:
-
Yuusuke Ashizuka authored
RTL9000AA/AN as 100BASE-T1 is following: - 100 Mbps - Full duplex - Link Status Change Interrupt - Master/Slave configuration Signed-off-by:
Yuusuke Ashizuka <ashiduka@fujitsu.com> Signed-off-by:
Torii Kenichi <torii.ken1@fujitsu.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20210121080254.21286-1-ashiduka@fujitsu.comSigned-off-by:
-
Wolfram Sang authored
Document the compatible value for the RAVB block in the Renesas R-Car V3U (R8A779A0) SoC. This variant has no stream buffer, so we only need to add the new compatible and add it to the TX delay block. Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210121100619.5653-2-wsa+renesas@sang-engineering.comSigned-off-by:
-
- 22 Jan, 2021 9 commits
-
-
Jakub Kicinski authored
Alex Elder says: ==================== net: ipa: remove a build dependency Unlike the original (temporary) IPA notification mechanism, the generic remoteproc SSR notification code does not require the IPA driver to maintain a pointer to the modem subsystem remoteproc structure. The IPA driver was converted to use the newer SSR notifiers, but the specification and use of a phandle for the modem subsystem was never removed. This series removes the lookup of the remoteproc pointer, and that removes the need for the modem DT property. It also removes the reference to the "modem-remoteproc" property from the DT binding, and from the DT files that specified them. ==================== Link: https://lore.kernel.org/r/20210120212606.12556-1-elder@linaro.orgSigned-off-by:
-
Alex Elder authored
The "modem-remoteproc" property is no longer required for the IPA driver, so get rid of it. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
The "modem-remoteproc" property is no longer required for the IPA driver, so get rid of it. Signed-off-by:
-
Alex Elder authored
The IPA driver uses the remoteproc SSR notifier now, rather than the temporary IPA notification system used initially. As a result it no longer needs a property identifying the modem subsystem DT node. Use GIC_SPI rather than 0 in the example interrupt definition. Signed-off-by:
-
Alex Elder authored
The IPA driver currently requires a DT property to be defined whose value is the phandle for the modem subsystem. This was needed to look up a remoteproc structure pointer used when registering for notifications in the original IPA notification mechanism. Remoteproc provides a more generic SSR notifier system, and the IPA driver switched over to it last summer, but this remoteproc phandle dependency was not removed at that time. Get rid of the IPA remoteproc pointer and stop requiring the phandle be specified. This avoids a link error (rproc_put() not defined) for certain configurations. Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Michael Walle authored
If the MII interface is used, the PHY is the clock master, thus don't set the clock rate. On Zynq-7000, this will prevent the following warning: macb e000b000.ethernet eth0: unable to generate target frequency: 25000000 Hz Signed-off-by:
Michael Walle <michael@walle.cc> Reviewed-by:
-
Arnd Bergmann authored
The tango4 platform is getting removed, and this driver has no other known users, so it can be removed. Cc: Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Mans Rullgard <mans@mansr.com> Link: https://lore.kernel.org/r/20210120150703.1629527-1-arnd@kernel.orgSigned-off-by:
-
Heiner Kallweit authored
The comment is quite weird, there is no such thing as a vendor-specific VPD id. 0x82 is the value of PCI_VPD_LRDT_ID_STRING. So what we are doing here is simply checking whether the byte at VPD address VPD_BASE is a valid string LRDT, same as what is done a few lines later in the code. LRDT = Large Resource Data Tag, see PCI 2.2 spec, VPD chapter v2: - don't set VPD_BASE / VPD_BASE_OLD separately Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/644ef22f-e86a-5cc1-0f27-f873ab165696@gmail.comSigned-off-by:
-
Jiapeng Zhong authored
Fix the following coccicheck warnings: ./drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:5142:2-33: WARNING: Assignment of 0/1 to bool variable. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Zhong <abaci-bugfix@linux.alibaba.com> Link: https://lore.kernel.org/r/1611126111-22079-1-git-send-email-abaci-bugfix@linux.alibaba.comSigned-off-by:
-
- 21 Jan, 2021 3 commits
-
-
George McCollister authored
Add myself as maintainer of the Arrow SpeedChips XRS7000 series Ethernet switch driver. Suggested-by:
George McCollister <george.mccollister@gmail.com> Link: https://lore.kernel.org/r/20210120135323.73856-1-george.mccollister@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Rasmus Villemoes says: ==================== ucc_geth improvements This is a resend of some improvements to the ucc_geth driver that was previously sent together with bug fixes, which have by now been applied. v2: rebase to net/master; address minor style issues; don't introduce a use-after-free in patch "don't statically allocate eight ucc_geth_info". ==================== Link: https://lore.kernel.org/r/20210119150802.19997-1-rasmus.villemoes@prevas.dkSigned-off-by:
-
Rasmus Villemoes authored
Since kmalloc() is nowadays [1] guaranteed to return naturally aligned (i.e., aligned to the size itself) memory for power-of-2 sizes, we don't need to over-allocate the align amount, compute an aligned address within the allocation, and (for later freeing) also storing the original pointer [2]. Instead, just round up the length we want to allocate to the alignment requirements, then round that up to the next power of 2. In theory, this could allocate up to about twice as much memory as we needed. In practice, (a) kmalloc() would in most cases anyway return a power-of-2-sized allocation and (b) with the default values of the bdRingLen[RT]x fields, the length is already itself a power of 2 greater than the alignment. So we actually end up saving memory compared to the current situtation (e.g. for tx, we currently allocate 128+32 bytes, which kmalloc() likely rounds up to 192 or 256; with this patch, we just allocate 128 bytes.) Also struct ucc_geth_private becomes a little smaller. [1] 59bb4798 ("mm, sl[aou]b: guarantee natural alignment for kmalloc(power-of-two)") [2] That storing was anyway done in a u32, which works on 32 bit machines, but is not very elegant and certainly makes a reader of the code pause for a while. Signed-off-by:
Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by:
-
