- 02 Oct, 2020 28 commits
-
-
Vladimir Oltean authored
Provide an example script which can be used as a skeleton for offloading TCAM rules in the Ocelot switches. Not all actions are demoed, mostly because of difficulty to automate this from a single board. For example, policing. We can set up an iperf3 UDP server and client and measure throughput at destination. But at least with DSA setups, network namespacing the individual ports is not possible because all switch ports are handled by the same DSA master. And we cannot assume that the target platform (an embedded board) has 2 other non-switch generator ports, we need to work with the generator ports as switch ports (this is the reason why mausezahn is used, and not IP traffic like ping). When somebody has an idea how to test policing, that can be added to this test. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
Via the OCELOT_MASK_MODE_REDIRECT flag put in the IS2 action vector, it is possible to replace previous forwarding decisions with the port mask installed in this rule. I have studied Table 54 "MASK_MODE and PORT_MASK Combinations" from the VSC7514 documentation and it appears to behave sanely when this rule is installed in either lookup 0 or 1. Namely, a redirect in lookup 1 will overwrite the forwarding decision taken by any entry in lookup 0. Signed-off-by:
-
Vladimir Oltean authored
The issue which led to the introduction of this check was that MAC_ETYPE rules, such as filters on dst_mac and src_mac, would only match non-IP frames. There is a knob in VCAP_S2_CFG which forces all IP frames to be treated as non-IP, which is what we're currently doing if the user requested a dst_mac filter, in order to maintain sanity. But that knob is actually per IS2 lookup. And the good thing with exposing the lookups to the user via tc chains is that we're now able to offload MAC_ETYPE keys to one lookup, and IP keys to the other lookup. So let's do that. Signed-off-by:
-
Vladimir Oltean authored
We were installing TCAM rules with the LOOKUP field as unmasked, meaning that all entries were matching on all lookups. Now that lookups are exposed as individual chains, let's make the LOOKUP explicit when offloading TCAM entries. Signed-off-by:
-
Xiaoliang Yang authored
VCAP ES0 is an egress VCAP operating on all outgoing frames. This patch added ES0 driver to support vlan push action of tc filter. Usage: tc filter add dev swp1 egress protocol 802.1Q flower indev swp0 skip_sw \ vlan_id 1 vlan_prio 1 action vlan push id 2 priority 2 Signed-off-by:Xiaoliang Yang <xiaoliang.yang_1@nxp.com> Signed-off-by:
-
Xiaoliang Yang authored
VCAP IS1 is a VCAP module which can filter on the most common L2/L3/L4 Ethernet keys, and modify the results of the basic QoS classification and VLAN classification based on those flow keys. There are 3 VCAP IS1 lookups, mapped over chains 10000, 11000 and 12000. Currently the driver is hardcoded to use IS1_ACTION_TYPE_NORMAL half keys. Note that the VLAN_MANGLE has been omitted for now. In hardware, the VCAP_IS1_ACT_VID_REPLACE_ENA field replaces the classified VLAN (metadata associated with the frame) and not the VLAN from the header itself. There are currently some issues which need to be addressed when operating in standalone, or in bridge with vlan_filtering=0 modes, because in those cases the switch ports have VLAN awareness disabled, and changing the classified VLAN to anything other than the pvid causes the packets to be dropped. Another issue is that on egress, we expect port tagging to push the classified VLAN, but port tagging is disabled in the modes mentioned above, so although the classified VLAN is replaced, it is not visible in the packet transmitted by the switch. Signed-off-by:
-
Vladimir Oltean authored
For Ocelot switches, there are 2 ingress pipelines for flow offload rules: VCAP IS1 (Ingress Classification) and IS2 (Security Enforcement). IS1 and IS2 support different sets of actions. The pipeline order for a packet on ingress is: Basic classification -> VCAP IS1 -> VCAP IS2 Furthermore, IS1 is looked up 3 times, and IS2 is looked up twice (each TCAM entry can be configured to match only on the first lookup, or only on the second, or on both etc). Because the TCAMs are completely independent in hardware, and because of the fixed pipeline, we actually have very limited options when it comes to offloading complex rules to them while still maintaining the same semantics with the software data path. This patch maps flow offload rules to ingress TCAMs according to a predefined chain index number. There is going to be a script in selftests that clarifies the usage model. There is also an egress TCAM (VCAP ES0, the Egress Rewriter), which is modeled on top of the default chain 0 of the egress qdisc, because it doesn't have multiple lookups. Suggested-by:
Allan W. Nielsen <allan.nielsen@microchip.com> Co-developed-by:
-
Vladimir Oltean authored
Since the mscc_ocelot_switch_lib is common between a pure switchdev and a DSA driver, the procedure of retrieving a net_device for a certain port index differs, as those are registered by their individual front-ends. Up to now that has been dealt with by always passing the port index to the switch library, but now, we're going to need to work with net_device pointers from the tc-flower offload, for things like indev, or mirred. It is not desirable to refactor that, so let's make sure that the flower offload core has the ability to translate between a net_device and a port index properly. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Vladimir Oltean authored
At this stage, the tc-flower offload of mscc_ocelot can only delegate rules to the VCAP IS2 security enforcement block. These rules have, in hardware, separate bits for policing and for overriding the destination port mask and/or copying to the CPU. So it makes sense that we attempt to expose some more of that low-level complexity instead of simply choosing between a single type of action. Something similar happens with the VCAP IS1 block, where the same action can contain enable bits for VLAN classification and for QoS classification at the same time. So model the action structure after the hardware description, and let the high-level ocelot_flower.c construct an action vector from multiple tc actions. Signed-off-by:
-
David S. Miller authored
Merge tag 'mac80211-next-for-net-next-2020-10-02' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== Another set of changes, this time with: * lots more S1G band support * 6 GHz scanning, finally * kernel-doc fixes * non-split wiphy dump fixes in nl80211 * various other small cleanups/features ==================== Signed-off-by:
-
Łukasz Stelmach authored
Use more generic eth_platform_get_mac_address() which can get a MAC address from other than DT platform specific sources too. Check if the obtained address is valid. Signed-off-by:
Łukasz Stelmach <l.stelmach@samsung.com> Signed-off-by:
-
Kurt Kanzenbach authored
The switch has a certain MDIO address and this needs to be specified using the reg property. Add it to the example. Signed-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: dsa: Improve dsa_untag_bridge_pvid() This patch series is based on the recent discussions with Vladimir: https://lore.kernel.org/netdev/20201001030623.343535-1-f.fainelli@gmail.com/ the simplest way forward was to call dsa_untag_bridge_pvid() after eth_type_trans() has been set which guarantees that skb->protocol is set to a correct value and this allows us to utilize __vlan_find_dev_deep_rcu() properly without playing or using the bridge master as a net_device reference. ==================== Signed-off-by:
-
Florian Fainelli authored
Now that we are guaranteed that dsa_untag_bridge_pvid() is called after eth_type_trans() we can utilize __vlan_find_dev_deep_rcu() which will take care of finding an 802.1Q upper on top of a bridge master. A common use case, prior to 12a1526d067 ("net: dsa: untag the bridge pvid from rx skbs") was to configure a bridge 802.1Q upper like this: ip link add name br0 type bridge vlan_filtering 0 ip link add link br0 name br0.1 type vlan id 1 in order to pop the default_pvid VLAN tag. With this change we restore that behavior while still allowing the DSA receive path to automatically pop the VLAN tag. Signed-off-by: -
Florian Fainelli authored
Now that dsa_untag_bridge_pvid() is called after eth_type_trans() we are guaranteed that skb->protocol will be set to a correct value, thus allowing us to avoid calling vlan_eth_hdr(). Signed-off-by:
-
Florian Fainelli authored
Indicate to the DSA receive path that we need to untage the bridge PVID, this allows us to remove the dsa_untag_bridge_pvid() calls from net/dsa/tag_brcm.c. Signed-off-by:
-
Florian Fainelli authored
When a DSA switch driver needs to call dsa_untag_bridge_pvid(), it can set dsa_switch::untag_brige_pvid to indicate this is necessary. This is a pre-requisite to making sure that we are always calling dsa_untag_bridge_pvid() after eth_type_trans() has been called. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-nextDavid S. Miller authored
Steffen Klassert says: ==================== pull request (net-next): ipsec-next 2020-10-02 1) Add a full xfrm compatible layer for 32-bit applications on 64-bit kernels. From Dmitry Safonov. Please pull or let me know if there are problems. ==================== Signed-off-by: -
Johannes Berg authored
[ Upstream commit a95bc734 ] If userspace doesn't complete the policy dump, we leak the allocated state. Fix this. Fixes: d07dcf9a ("netlink: add infrastructure to expose policies to userspace") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Thomas Pedersen authored
In ieee80211_determine_chantype(), the sband->ht_cap was being processed before S1G Operation element. Since the HT capability element should not be present on the S1G band, avoid processing potential garbage by moving the call to ieee80211_apply_htcap_overrides() to after the S1G block. Also, in case of a missing S1G Operation element, we would continue trying to process non-S1G elements (and return with a channel width of 20MHz). Instead, just assume primary channel is equal to operating and infer the operating width from the BSS channel, then return. Signed-off-by:
Thomas Pedersen <thomas@adapt-ip.com> Link: https://lore.kernel.org/r/20201001174748.24520-1-thomas@adapt-ip.comSigned-off-by:
-
Johannes Berg authored
When dumping wiphy information, we try to split the data into many submessages, but for old userspace we still support the old mode where this doesn't happen. However, in this case we were not resetting our state correctly and dumping multiple messages for each wiphy, which would have broken such older userspace. This was broken pretty much immediately afterwards because it only worked in the original commit where non-split dumps didn't have any more data than split dumps... Fixes: fe1abafd ("nl80211: re-add channel width and extended capa advertising") Signed-off-by:
-
Johannes Berg authored
When wiphy dumps cannot be split, such as in events or with older userspace that doesn't support it, the size can today be too big. Reduce it, by doing two things: 1) remove data that couldn't have been present before the split capability was introduced since it's new, such as HE capabilities 2) as suggested by Martin Willi, remove management frame subtypes from the split dumps, as just (1) isn't even enough due to other new code capabilities. This is fine as old consumers (really just wpa_supplicant) didn't check this data before they got support for split dumps. Reported-by:Martin Willi <martin@strongswan.org> Suggested-by:
-
Armin Wolf authored
Use netif_msg_init() to process param settings and use only the proper initialized value of ei_local->msg_level for later processing; Signed-off-by:
Armin Wolf <W_Armin@gmx.de> Signed-off-by:
-
Willy Liu authored
Realtek single-chip Ethernet PHY solutions can be separated as below: 10M/100Mbps: RTL8201X 1Gbps: RTL8211X 2.5Gbps: RTL8226/RTL8221X RTL8226 is the first version for realtek that compatible 2.5Gbps single PHY. Since RTL8226 is single port only, realtek changes its name to RTL8221B from the second version. PHY ID for RTL8226 is 0x001cc800 and RTL8226B/RTL8221B is 0x001cc840. RTL8125 is not a single PHY solution, it integrates PHY/MAC/PCIE bus controller and embedded memory. Signed-off-by:
Willy Liu <willy.liu@realtek.com> Signed-off-by:
-
Jing Xiangfeng authored
After commit a8c7687b ("caif_virtio: Check that vringh_config is not null"), the variable err is being initialized with '-EINVAL' that is meaningless. So remove it. Signed-off-by:
Jing Xiangfeng <jingxiangfeng@huawei.com> Signed-off-by:
-
Ye Bin authored
Fix follow warnings: [net/core/net-sysfs.c:1161]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'int'. [net/core/net-sysfs.c:1162]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'int'. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Ye Bin <yebin10@huawei.com> Signed-off-by:
-
Ye Bin authored
Fix follow warnings: [net/core/pktgen.c:925]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'signed int'. [net/core/pktgen.c:942]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'signed int'. [net/core/pktgen.c:962]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'signed int'. [net/core/pktgen.c:984]: (warning) %u in format string (no. 1) requires 'unsigned int' but the argument type is 'signed int'. [net/core/pktgen.c:1149]: (warning) %d in format string (no. 1) requires 'int' but the argument type is 'unsigned int'. Reported-by:
-
Xie He authored
The fr_hard_header function is used to prepend the header to skbs before transmission. It is used in 3 situations: 1) When a control packet is generated internally in this driver; 2) When a user sends an skb on an Ethernet-emulating PVC device; 3) When a user sends an skb on a normal PVC device. These 3 situations need to be handled differently by fr_hard_header. Different headers should be prepended to the skb in different situations. Currently fr_hard_header distinguishes these 3 situations using skb->protocol. For situation 1 and 2, a special skb->protocol value will be assigned before calling fr_hard_header, so that it can recognize these 2 situations. All skb->protocol values other than these special ones are treated by fr_hard_header as situation 3. However, it is possible that in situation 3, the user sends an skb with one of the special skb->protocol values. In this case, fr_hard_header would incorrectly treat it as situation 1 or 2. This patch tries to solve this issue by using skb->dev instead of skb->protocol to distinguish between these 3 situations. For situation 1, skb->dev would be NULL; for situation 2, skb->dev->type would be ARPHRD_ETHER; and for situation 3, skb->dev->type would be ARPHRD_DLCI. This way fr_hard_header would be able to distinguish these 3 situations correctly regardless what skb->protocol value the user tries to use in situation 3. Cc: Krzysztof Halasa <khc@pm.waw.pl> Signed-off-by:
Xie He <xie.he.0141@gmail.com> Signed-off-by:
-
- 01 Oct, 2020 12 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller authored
Daniel Borkmann says: ==================== pull-request: bpf-next 2020-10-01 The following pull-request contains BPF updates for your *net-next* tree. We've added 90 non-merge commits during the last 8 day(s) which contain a total of 103 files changed, 7662 insertions(+), 1894 deletions(-). Note that once bpf(/net) tree gets merged into net-next, there will be a small merge conflict in tools/lib/bpf/btf.c between commit 12450081 ("libbpf: Fix native endian assumption when parsing BTF") from the bpf tree and the commit 3289959b ("libbpf: Support BTF loading and raw data output in both endianness") from the bpf-next tree. Correct resolution would be to stick with bpf-next, it should look like: [...] /* check BTF magic */ if (fread(&magic, 1, sizeof(magic), f) < sizeof(magic)) { err = -EIO; goto err_out; } if (magic != BTF_MAGIC && magic != bswap_16(BTF_MAGIC)) { /* definitely not a raw BTF */ err = -EPROTO; goto err_out; } /* get file size */ [...] The main changes are: 1) Add bpf_snprintf_btf() and bpf_seq_printf_btf() helpers to support displaying BTF-based kernel data structures out of BPF programs, from Alan Maguire. 2) Speed up RCU tasks trace grace periods by a factor of 50 & fix a few race conditions exposed by it. It was discussed to take these via BPF and networking tree to get better testing exposure, from Paul E. McKenney. 3) Support multi-attach for freplace programs, needed for incremental attachment of multiple XDP progs using libxdp dispatcher model, from Toke Høiland-Jørgensen. 4) libbpf support for appending new BTF types at the end of BTF object, allowing intrusive changes of prog's BTF (useful for future linking), from Andrii Nakryiko. 5) Several BPF helper improvements e.g. avoid atomic op in cookie generator and add a redirect helper into neighboring subsys, from Daniel Borkmann. 6) Allow map updates on sockmaps from bpf_iter context in order to migrate sockmaps from one to another, from Lorenz Bauer. 7) Fix 32 bit to 64 bit assignment from latest alu32 bounds tracking which caused a verifier issue due to type downgrade to scalar, from John Fastabend. 8) Follow-up on tail-call support in BPF subprogs which optimizes x64 JIT prologue and epilogue sections, from Maciej Fijalkowski. 9) Add an option to perf RB map to improve sharing of event entries by avoiding remove- on-close behavior. Also, add BPF_PROG_TEST_RUN for raw_tracepoint, from Song Liu. 10) Fix a crash in AF_XDP's socket_release when memory allocation for UMEMs fails, from Magnus Karlsson. ==================== Signed-off-by:
-
David S. Miller authored
onfiguration' Geert Uytterhoeven says: ==================== net/ravb: Add support for explicit internal clock delay configuration Some Renesas EtherAVB variants support internal clock delay configuration, which can add larger delays than the delays that are typically supported by the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps" properties). Historically, the EtherAVB driver configured these delays based on the "rgmii-*id" PHY mode. This caused issues with PHY drivers that implement PHY internal delays properly[1]. Hence a backwards-compatible workaround was added by masking the PHY mode[2]. This patch series implements the next step of the plan outlined in [3], and adds proper support for explicit configuration of the MAC internal clock delays using new "[rt]x-internal-delay-ps" properties. If none of these properties is present, the driver falls back to the old handling. This can be considered the MAC counterpart of commit 9150069b ("dt-bindings: net: Add tx and rx internal delays"), which applies to the PHY. Note that unlike commit 92252eec ("net: phy: Add a helper to return the index for of the internal delay"), no helpers are provided to parse the DT properties, as so far there is a single user only, which supports only zero or a single fixed value. Of course such helpers can be added later, when the need arises, or when deemed useful otherwise. This series consists of 3 parts: 1. DT binding updates documenting the new properties, for both the generic ethernet-controller and the EtherAVB-specific bindings, 2. Conversion to json-schema of the Renesas EtherAVB DT bindings. Technically, the conversion is independent of all of the above. I included it in this series, as it shows how all sanity checks on "[rt]x-internal-delay-ps" values are implemented as DT binding checks, 3. EtherAVB driver update implementing support for the new properties. Given Rob has provided his acks for the DT binding updates, all of this can be merged through net-next. Changes compared to v3[4]: - Add Reviewed-by, - Drop the DT updates, as they will be merged through renesas-devel and arm-soc, and have a hard dependency on this series. Changes compared to v2[5]: - Update recently added board DTS files, - Add Reviewed-by. Changes compared to v1[6]: - Added "[PATCH 1/7] dt-bindings: net: ethernet-controller: Add internal delay properties", - Replace "renesas,[rt]xc-delay-ps" by "[rt]x-internal-delay-ps", - Incorporated EtherAVB DT binding conversion to json-schema, - Add Reviewed-by. Impacted, tested: - Salvator-X(S) with R-Car H3 ES1.0 and ES2.0, M3-W, and M3-N. Not impacted, tested: - Ebisu with R-Car E3. Impacted, not tested: - Salvator-X(S) with other SoC variants, - ULCB with R-Car H3/M3-W/M3-N variants, - V3MSK and Eagle with R-Car V3M, - Draak with R-Car V3H, - HiHope RZ/G2[MN] with RZ/G2M or RZ/G2N, - Beacon EmbeddedWorks RZ/G2M Development Kit. To ease testing, I have pushed this series and the DT updates to the topic/ravb-internal-clock-delays-v4 branch of my renesas-drivers repository at git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git. Thanks for applying! References: [1] Commit bcf3440c ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY") [2] Commit 9b23203c ("ravb: Mask PHY mode to avoid inserting delays twice"). https://lore.kernel.org/r/20200529122540.31368-1-geert+renesas@glider.be/ [3] https://lore.kernel.org/r/CAMuHMdU+MR-2tr3-pH55G0GqPG9HwH3XUd=8HZxprFDMGQeWUw@mail.gmail.com/ [4] https://lore.kernel.org/linux-devicetree/20200819134344.27813-1-geert+renesas@glider.be/ [5] https://lore.kernel.org/linux-devicetree/20200706143529.18306-1-geert+renesas@glider.be/ [6] https://lore.kernel.org/linux-devicetree/20200619191554.24942-1-geert+renesas@glider.be/ ==================== Signed-off-by:
-
Geert Uytterhoeven authored
Some EtherAVB variants support internal clock delay configuration, which can add larger delays than the delays that are typically supported by the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps" properties). Historically, the EtherAVB driver configured these delays based on the "rgmii-*id" PHY mode. This caused issues with PHY drivers that implement PHY internal delays properly[1]. Hence a backwards-compatible workaround was added by masking the PHY mode[2]. Add proper support for explicit configuration of the MAC internal clock delays using the new "[rt]x-internal-delay-ps" properties. Fall back to the old handling if none of these properties is present. [1] Commit bcf3440c ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY") [2] Commit 9b23203c ("ravb: Mask PHY mode to avoid inserting delays twice"). Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by:
-
Geert Uytterhoeven authored
Currently, full delay handling is done in both the probe and resume paths. Split it in two parts, so the resume path doesn't have to redo the parsing part over and over again. Signed-off-by:
-
Geert Uytterhoeven authored
Convert the Renesas Ethernet AVB (EthernetAVB-IF) Device Tree binding documentation to json-schema. Add missing properties. Update the example to match reality. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Geert Uytterhoeven authored
Some EtherAVB variants support internal clock delay configuration, which can add larger delays than the delays that are typically supported by the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps" properties). Add properties for configuring the internal MAC delays. These properties are mandatory, even when specified as zero, to distinguish between old and new DTBs. Update the (bogus) example accordingly. Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@gmail.com> Reviewed-by:
-
Geert Uytterhoeven authored
Internal Receive and Transmit Clock Delays are a common setting for RGMII capable devices. While these delays are typically applied by the PHY, some MACs support configuring internal clock delay settings, too. Hence add standardized properties to configure this. This is the MAC counterpart of commit 9150069b ("dt-bindings: net: Add tx and rx internal delays"), which applies to the PHY. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5-updates-2020-09-30 Updates and cleanups for mlx5 driver: 1) From Ariel, Dan Carpenter and Gostavo, Fixes to the previous mlx5 Connection track series. 2) From Yevgeny, trivial cleanups for Software steering 3) From Hamdan, Support for Flow source hint in software steering and E-Switch 4) From Parav and Sunil, Small and trivial E-Switch updates and cleanups in preparation for mlx5 Sub-functions support ==================== Signed-off-by: -
Alexei Starovoitov authored
Song Liu says: ==================== This set introduces BPF_F_PRESERVE_ELEMS to perf event array for better sharing of perf event. By default, perf event array removes the perf event when the map fd used to add the event is closed. With BPF_F_PRESERVE_ELEMS set, however, the perf event will stay in the array until it is removed, or the map is closed. --- Changes v3 => v5: 1. Clean up in selftest. (Alexei) Changes v2 => v3: 1. Move perf_event_fd_array_map_free() to avoid unnecessary forward declaration. (Daniel) Changes v1 => v2: 1. Rename the flag as BPF_F_PRESERVE_ELEMS. (Alexei, Daniel) 2. Simplify the code and selftest. (Daniel, Alexei) ==================== Signed-off-by:Alexei Starovoitov <ast@kernel.org>
-
Song Liu authored
Add tests for perf event array with and without BPF_F_PRESERVE_ELEMS. Add a perf event to array via fd mfd. Without BPF_F_PRESERVE_ELEMS, the perf event is removed when mfd is closed. With BPF_F_PRESERVE_ELEMS, the perf event is removed when the map is freed. Signed-off-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
-
Song Liu authored
Currently, perf event in perf event array is removed from the array when the map fd used to add the event is closed. This behavior makes it difficult to the share perf events with perf event array. Introduce perf event map that keeps the perf event open with a new flag BPF_F_PRESERVE_ELEMS. With this flag set, perf events in the array are not removed when the original map fd is closed. Instead, the perf event will stay in the map until 1) it is explicitly removed from the array; or 2) the array is freed. Signed-off-by:
-
Gustavo A. R. Silva authored
Calls to kzalloc() and kvzalloc() should be null-checked in order to avoid any potential failures. In this case, a potential null pointer dereference. Fix this by adding null checks for _parse_attr_ and _flow_ right after allocation. Addresses-Coverity-ID: 1497154 ("Dereference before null check") Fixes: c620b772 ("net/mlx5: Refactor tc flow attributes structure") Signed-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com>
-
