summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-02-16can: esd_usb: Improve readability on decoding ESD_EV_CAN_ERROR_EXT messagesFrank Jungclaus
As suggested by Marc introduce a union plus a struct ev_can_err_ext for easier decoding of an ESD_EV_CAN_ERROR_EXT event message (which simply is a rx_msg with some dedicated data). Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/linux-can/20220621071152.ggyhrr5sbzvwpkpx@pengutronix.de/ Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/all/20230216190450.3901254-4-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-16can: esd_usb: Make use of can_change_state() and relocate checking skb for NULLFrank Jungclaus
Start a rework initiated by Vincents remarks "You should not report the greatest of txerr and rxerr but the one which actually increased." [1] and "As far as I understand, those flags should be set only when the threshold is reached" [2] . Therefore make use of can_change_state() to (among others) set the flags CAN_ERR_CRTL_[RT]X_WARNING and CAN_ERR_CRTL_[RT]X_PASSIVE, maintain CAN statistic counters for error_warning, error_passive and bus_off. Relocate testing alloc_can_err_skb() for NULL to the end of esd_usb_rx_event(), to have things like can_bus_off(), can_change_state() working even in out of memory conditions. Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device") Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: [1] https://lore.kernel.org/all/CAMZ6RqKGBWe15aMkf8-QLf-cOQg99GQBebSm+1wEzTqHgvmNuw@mail.gmail.com/ Link: [2] https://lore.kernel.org/all/CAMZ6Rq+QBO1yTX_o6GV0yhdBj-RzZSRGWDZBS0fs7zbSTy4hmA@mail.gmail.com/ Link: https://lore.kernel.org/all/20230216190450.3901254-3-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-16can: esd_usb: Move mislocated storage of SJA1000_ECC_SEG bits in case of a ↵Frank Jungclaus
bus error Move the supply for cf->data[3] (bit stream position of CAN error), in case of a bus- or protocol-error, outside of the "switch (ecc & SJA1000_ECC_MASK){}"-statement, because this bit stream position is independent of the error type. Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device") Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/all/20230216190450.3901254-2-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-16Merge tag 'gpio-fixes-for-v6.2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fixes from Bartosz Golaszewski: - fix a potential Kconfig issue with gpio-mlxbf2 not selecting GPIOLIB_IRQCHIP - another immutable irqchip conversion, this time for gpio-vf610 - fix a wakeup issue on Clevo NH5xAx * tag 'gpio-fixes-for-v6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: mlxbf2: select GPIOLIB_IRQCHIP gpiolib: acpi: Add a ignore wakeup quirk for Clevo NH5xAx gpio: vf610: make irq_chip immutable gpiolib: acpi: remove redundant declaration
2023-02-16can: ctucanfd: ctucan_platform_probe(): use devm_platform_ioremap_resource()Yang Li
Convert platform_get_resource(), devm_ioremap_resource() to a single call to Use devm_platform_ioremap_resource(), as this is exactly what this function does. Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Acked-by: Pavel Pisa <pisa@cmp.felk.cvut.cz> Link: https://lore.kernel.org/all/20230216090610.130860-1-yang.lee@linux.alibaba.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-16stop mainaining UUIDChristoph Hellwig
The uuid code is very low maintainance now that the major overhaul has completed, and doesn't need it's own tree. All the recent work has been done by Andy who'd like to stay on as a reviewer without an explicit tree. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2023-02-16orphan sysvfsChristoph Hellwig
This code has been stale for years and I have no way to test it. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2023-02-16Merge branch 'mlx5-next' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux Leon Romanovsky says: ==================== mlx5-next changes Following previous conversations [1] and our clear commitment to do the TC work [2], please pull mlx5-next shared branch, which includes low-level steering logic to allow RoCEv2 traffic to be encrypted/ decrypted through IPsec. [1] https://lore.kernel.org/all/20230126230815.224239-1-saeed@kernel.org/ [2] https://lore.kernel.org/all/Y+Z7lVVWqnRBiPh2@nvidia.com/ * 'mlx5-next' of https://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux: net/mlx5: Configure IPsec steering for egress RoCEv2 traffic net/mlx5: Configure IPsec steering for ingress RoCEv2 traffic net/mlx5: Add IPSec priorities in RDMA namespaces net/mlx5: Implement new destination type TABLE_TYPE net/mlx5: Introduce new destination type TABLE_TYPE ==================== Link: https://lore.kernel.org/r/20230215095624.1365200-1-leon@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-16Merge tag 'wireless-next-2023-03-16' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Major stack changes: * EHT channel puncturing support (client & AP) * some support for AP MLD without mac80211 * fixes for A-MSDU on mesh connections Major driver changes: iwlwifi * EHT rate reporting * Bump FW API to 74 for AX devices * STEP equalizer support: transfer some STEP (connection to radio on platforms with integrated wifi) related parameters from the BIOS to the firmware mt76 * switch to using page pool allocator * mt7996 EHT (Wi-Fi 7) support * Wireless Ethernet Dispatch (WED) reset support libertas * WPS enrollee support brcmfmac * Rename Cypress 89459 to BCM4355 * BCM4355 and BCM4377 support mwifiex * SD8978 chipset support rtl8xxxu * LED support ath12k * new driver for Qualcomm Wi-Fi 7 devices ath11k * IPQ5018 support * Fine Timing Measurement (FTM) responder role support * channel 177 support ath10k * store WLAN firmware version in SMEM image table * tag 'wireless-next-2023-03-16' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (207 commits) wifi: brcmfmac: p2p: Introduce generic flexible array frame member wifi: mac80211: add documentation for amsdu_mesh_control wifi: cfg80211: remove gfp parameter from cfg80211_obss_color_collision_notify description wifi: mac80211: always initialize link_sta with sta wifi: mac80211: pass 'sta' to ieee80211_rx_data_set_sta() wifi: cfg80211: Set SSID if it is not already set wifi: rtw89: move H2C of del_pkt_offload before polling FW status ready wifi: rtw89: use readable return 0 in rtw89_mac_cfg_ppdu_status() wifi: rtw88: usb: drop now unnecessary URB size check wifi: rtw88: usb: send Zero length packets if necessary wifi: rtw88: usb: Set qsel correctly wifi: mac80211: fix off-by-one link setting wifi: mac80211: Fix for Rx fragmented action frames wifi: mac80211: avoid u32_encode_bits() warning wifi: mac80211: Don't translate MLD addresses for multicast wifi: cfg80211: call reg_notifier for self managed wiphy from driver hint wifi: cfg80211: get rid of gfp in cfg80211_bss_color_notify wifi: nl80211: Allow authentication frames and set keys on NAN interface wifi: mac80211: fix non-MLO station association wifi: mac80211: Allow NSS change only up to capability ... ==================== Link: https://lore.kernel.org/r/20230216105406.208416-1-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-16block: bio-integrity: Copy flags when bio_integrity_payload is clonedMartin K. Petersen
Make sure to copy the flags when a bio_integrity_payload is cloned. Otherwise per-I/O properties such as IP checksum flag will not be passed down to the HBA driver. Since the integrity buffer is owned by the original bio, the BIP_BLOCK_INTEGRITY flag needs to be masked off to avoid a double free in the completion path. Fixes: aae7df50190a ("block: Integrity checksum flag") Fixes: b1f01388574c ("block: Relocate bio integrity flags") Reported-by: Saurav Kashyap <skashyap@marvell.com> Tested-by: Saurav Kashyap <skashyap@marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Link: https://lore.kernel.org/r/20230215171801.21062-1-martin.petersen@oracle.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-02-16block: Fix io statistics for cgroup in throttle pathJinke Han
In the current code, io statistics are missing for cgroup when bio was throttled by blk-throttle. Fix it by moving the unreaching code to submit_bio_noacct_nocheck. Fixes: 3f98c753717c ("block: don't check bio in blk_throtl_dispatch_work_fn") Signed-off-by: Jinke Han <hanjinke.666@bytedance.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Acked-by: Muchun Song <songmuchun@bytedance.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20230216032250.74230-1-hanjinke.666@bytedance.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-02-16kvm: initialize all of the kvm_debugregs structure before sending it to ↵Greg Kroah-Hartman
userspace When calling the KVM_GET_DEBUGREGS ioctl, on some configurations, there might be some unitialized portions of the kvm_debugregs structure that could be copied to userspace. Prevent this as is done in the other kvm ioctls, by setting the whole structure to 0 before copying anything into it. Bonus is that this reduces the lines of code as the explicit flag setting and reserved space zeroing out can be removed. Cc: Sean Christopherson <seanjc@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: <x86@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: stable <stable@kernel.org> Reported-by: Xingyuan Mo <hdthky0@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Message-Id: <20230214103304.3689213-1-gregkh@linuxfoundation.org> Tested-by: Xingyuan Mo <hdthky0@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-02-16brd: mark as nowait compatibleJens Axboe
By default, non-mq drivers do not support nowait. This causes io_uring to use a slower path as the driver cannot be trust not to block. brd can safely set the nowait flag, as worst case all it does is a NOIO allocation. For io_uring, this makes a substantial difference. Before: submitter=0, tid=453, file=/dev/ram0, node=-1 polled=0, fixedbufs=1/0, register_files=1, buffered=0, QD=128 Engine=io_uring, sq_ring=128, cq_ring=128 IOPS=440.03K, BW=1718MiB/s, IOS/call=32/31 IOPS=428.96K, BW=1675MiB/s, IOS/call=32/32 IOPS=442.59K, BW=1728MiB/s, IOS/call=32/31 IOPS=419.65K, BW=1639MiB/s, IOS/call=32/32 IOPS=426.82K, BW=1667MiB/s, IOS/call=32/31 and after: submitter=0, tid=354, file=/dev/ram0, node=-1 polled=0, fixedbufs=1/0, register_files=1, buffered=0, QD=128 Engine=io_uring, sq_ring=128, cq_ring=128 IOPS=3.37M, BW=13.15GiB/s, IOS/call=32/31 IOPS=3.45M, BW=13.46GiB/s, IOS/call=32/31 IOPS=3.43M, BW=13.42GiB/s, IOS/call=32/32 IOPS=3.43M, BW=13.39GiB/s, IOS/call=32/31 IOPS=3.43M, BW=13.38GiB/s, IOS/call=32/31 or about an 8x in difference. Now that brd is prepared to deal with REQ_NOWAIT reads/writes, mark it as supporting that. Cc: stable@vger.kernel.org # 5.10+ Link: https://lore.kernel.org/linux-block/20230203103005.31290-1-p.raghav@samsung.com/ Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-02-16brd: check for REQ_NOWAIT and set correct page allocation maskJens Axboe
If REQ_NOWAIT is set, then do a non-blocking allocation if the operation is a write and we need to insert a new page. Currently REQ_NOWAIT cannot be set as the queue isn't marked as supporting nowait, this change is in preparation for allowing that. radix_tree_preload() warns on attempting to call it with an allocation mask that doesn't allow blocking. While that warning could arguably be removed, we need to handle radix insertion failures anyway as they are more likely if we cannot block to get memory. Remove legacy BUG_ON()'s and turn them into proper errors instead, one for the allocation failure and one for finding a page that doesn't match the correct index. Cc: stable@vger.kernel.org # 5.10+ Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-02-16brd: return 0/-error from brd_insert_page()Jens Axboe
It currently returns a page, but callers just check for NULL/page to gauge success. Clean this up and return the appropriate error directly instead. Cc: stable@vger.kernel.org # 5.10+ Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-02-16ASoC: SOF: Intel: hda-dai: fix possible stream_tag leakPierre-Louis Bossart
The HDaudio stream allocation is done first, and in a second step the LOSIDV parameter is programmed for the multi-link used by a codec. This leads to a possible stream_tag leak, e.g. if a DisplayAudio link is not used. This would happen when a non-Intel graphics card is used and userspace unconditionally uses the Intel Display Audio PCMs without checking if they are connected to a receiver with jack controls. We should first check that there is a valid multi-link entry to configure before allocating a stream_tag. This change aligns the dma_assign and dma_cleanup phases. Complements: b0cd60f3e9f5 ("ALSA/ASoC: hda: clarify bus_get_link() and bus_link_get() helpers") Link: https://github.com/thesofproject/linux/issues/4151 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20230216162340.19480-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-02-16ARM: dts: socfpga: Add enclustra PE1 devicetreeSteffen Trumtrar
The enclustra PE1 is a baseboard from enclustra GmbH for the enclustra Mercury AA1+ SOM. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2023-02-16dt-bindings: altera: Add enclustra mercury PE1Steffen Trumtrar
Add binding for the enclustra PE1 baseboard from enclustra GmbH. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2023-02-16erofs: fix an error code in z_erofs_init_zip_subsystem()Dan Carpenter
Return -ENOMEM if alloc_workqueue() fails. Don't return success. Fixes: d8a650adf429 ("erofs: add per-cpu threads for decompression as an option") Signed-off-by: Dan Carpenter <error27@gmail.com> Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com> Link: https://lore.kernel.org/r/Y+4d0FRsUq8jPoOu@kili Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2023-02-16block: sync mixed merged request's failfast with 1st bio'sMing Lei
We support mixed merge for requests/bios with different fastfail settings. When request fails, each time we only handle the portion with same failfast setting, then bios with failfast can be failed immediately, and bios without failfast can be retried. The idea is pretty good, but the current implementation has several defects: 1) initially RA bio doesn't set failfast, however bio merge code doesn't consider this point, and just check its failfast setting for deciding if mixed merge is required. Fix this issue by adding helper of bio_failfast(). 2) when merging bio to request front, if this request is mixed merged, we have to sync request's faifast setting with 1st bio's failfast. Fix it by calling blk_update_mixed_merge(). 3) when merging bio to request back, if this request is mixed merged, we have to mark the bio as failfast, because blk_update_request simply updates request failfast with 1st bio's failfast. Fix it by calling blk_update_mixed_merge(). Fixes one normal EXT4 READ IO failure issue, because it is observed that the normal READ IO is merged with RA IO, and the mixed merged request has different failfast setting with 1st bio's, so finally the normal READ IO doesn't get retried. Cc: Tejun Heo <tj@kernel.org> Fixes: 80a761fd33cf ("block: implement mixed merge of different failfast requests") Signed-off-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20230209125527.667004-1-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-02-16x86/hyperv: Fix hv_get/set_register for nested bringupNuno Das Neves
hv_get_nested_reg only translates SINT0, resulting in the wrong sint being registered by nested vmbus. Fix the issue with new utility function hv_is_sint_reg. While at it, improve clarity of hv_set_non_nested_register and hv_is_synic_reg. Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> Reviewed-by: Jinank Jain <jinankjain@linux.microsoft.com> Link: https://lore.kernel.org/r/1675980172-6851-1-git-send-email-nunodasneves@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
2023-02-16Merge tag 'asoc-fix-v6.2-rc8' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fix for v6.2 One non-urgent fix for v6.2, this could possibly wait till the merge window.
2023-02-16io_uring: Support calling io_uring_register with a registered ring fdJosh Triplett
Add a new flag IORING_REGISTER_USE_REGISTERED_RING (set via the high bit of the opcode) to treat the fd as a registered index rather than a file descriptor. This makes it possible for a library to open an io_uring, register the ring fd, close the ring fd, and subsequently use the ring entirely via registered index. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Link: https://lore.kernel.org/r/f2396369e638284586b069dbddffb8c992afba95.1676419314.git.josh@joshtriplett.org [axboe: remove extra high bit clear] Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-02-16Merge tag 'intel-gpio-v6.2-2' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-gpio-intel into gpio/for-current intel-gpio for v6.2-2 * Ignore spurious wakeup by touchpad on Clevo NH5xAx * Miscellaneous fix(es)
2023-02-16Merge branch 'seg6-add-psp-flavor-support-for-srv6-end-behavior'Paolo Abeni
Andrea Mayer says: ==================== seg6: add PSP flavor support for SRv6 End behavior Segment Routing for IPv6 (SRv6 in short) [1] is the instantiation of the Segment Routing (SR) [2] architecture on the IPv6 dataplane. In SRv6, the segment identifiers (SID) are IPv6 addresses and the segment list (SID List) is carried in the Segment Routing Header (SRH). A segment may be bound to a specific packet processing operation called "behavior". The RFC8986 [3] defines and standardizes the most common/relevant behaviors for network operators, e.g., End, End.X and End.T and so on. The RFC8986 also introduces the "flavors" framework aiming to modify or extend the capabilities of SRv6 End, End.X and End.T behaviors. Specifically, these behaviors support the following flavors (either individually or in combinations): - Penultimate Segment Pop (PSP); - Ultimate Segment Pop (USP); - Ultimate Segment Decapsulation (USD). Such flavors enable an End/End.X/End.T behavior to pop the SRH on the penultimate/ultimate SR endpoint node listed in the SID List or to perform a full decapsulation. Currently, the Linux kernel supports a large subset of behaviors described in RFC8986, including the End, End.X and End.T. However, PSP, USP and USD flavors have not yet been implemented. In this patchset, we extend the SRv6 subsystem to implement the PSP flavor in the SRv6 End behavior. To accomplish this task, we leverage the flavor framework previously introduced by another patchset required for supporting the efficient representation of the SID List through the NEXT-C-SID mechanism [4]. In details, the patchset is made of: - patch 1/3: seg6: factor out End lookup nexthop processing to a dedicated function - patch 2/3: seg6: add PSP flavor support for SRv6 End behavior - patch 3/3: selftests: seg6: add selftest for PSP flavor in SRv6 End behavior From the user space perspective, we do not need to change the iproute2 code to support the PSP flavor. However, we provide the man page for the PSP flavor in a separate patch. Comments, improvements and suggestions are always appreciated. [1] - RFC8754: https://datatracker.ietf.org/doc/html/rfc8754 [2] - RFC8402: https://datatracker.ietf.org/doc/html/rfc8402 [3] - RFC8986: https://datatracker.ietf.org/doc/html/rfc8986 [4] - https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression ==================== Link: https://lore.kernel.org/r/20230215134659.7613-1-andrea.mayer@uniroma2.it Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16selftests: seg6: add selftest for PSP flavor in SRv6 End behaviorAndrea Mayer
This selftest is designed for testing the PSP flavor in SRv6 End behavior. It instantiates a virtual network composed of several nodes: hosts and SRv6 routers. Each node is realized using a network namespace that is properly interconnected to others through veth pairs. The test makes use of the SRv6 End behavior and of the PSP flavor needed for removing the SRH from the IPv6 header at the penultimate node. The correct execution of the behavior is verified through reachability tests carried out between hosts. Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it> Signed-off-by: Paolo Lungaroni <paolo.lungaroni@uniroma2.it> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16seg6: add PSP flavor support for SRv6 End behaviorAndrea Mayer
The "flavors" framework defined in RFC8986 [1] represents additional operations that can modify or extend a subset of existing behaviors such as SRv6 End, End.X and End.T. We report these flavors hereafter: - Penultimate Segment Pop (PSP); - Ultimate Segment Pop (USP); - Ultimate Segment Decapsulation (USD). Depending on how the Segment Routing Header (SRH) has to be handled, an SRv6 End* behavior can support these flavors either individually or in combinations. In this patch, we only consider the PSP flavor for the SRv6 End behavior. A PSP enabled SRv6 End behavior is used by the Source/Ingress SR node (i.e., the one applying the SRv6 Policy) when it needs to instruct the penultimate SR Endpoint node listed in the SID List (carried by the SRH) to remove the SRH from the IPv6 header. Specifically, a PSP enabled SRv6 End behavior processes the SRH by: i) decreasing the Segment Left (SL) from 1 to 0; ii) copying the Last Segment IDentifier (SID) into the IPv6 Destination Address (DA); iii) removing (i.e., popping) the outer SRH from the extension headers following the IPv6 header. It is important to note that PSP operation (steps i, ii, iii) takes place only at a penultimate SR Segment Endpoint node (i.e., when the SL=1) and does not happen at non-penultimate Endpoint nodes. Indeed, when a SID of PSP flavor is processed at a non-penultimate SR Segment Endpoint node, the PSP operation is not performed because it would not be possible to decrease the SL from 1 to 0. SL=2 SL=1 SL=0 | | | For example, given the SRv6 policy (SID List := < X, Y, Z >): - a PSP enabled SRv6 End behavior bound to SID "Y" will apply the PSP operation as Segment Left (SL) is 1, corresponding to the Penultimate Segment of the SID List; - a PSP enabled SRv6 End behavior bound to SID "X" will *NOT* apply the PSP operation as the Segment Left is 2. This behavior instance will apply the "standard" End packet processing, ignoring the configured PSP flavor at all. [1] - RFC8986: https://datatracker.ietf.org/doc/html/rfc8986 Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16seg6: factor out End lookup nexthop processing to a dedicated functionAndrea Mayer
The End nexthop lookup/input operations are moved into a new helper function named input_action_end_finish(). This avoids duplicating the code needed to compute the nexthop in the different flavors of the End behavior. Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16net: dsa: ocelot: fix selecting MFD_OCELOTLukas Bulwahn
Commit 3d7316ac81ac ("net: dsa: ocelot: add external ocelot switch control") adds config NET_DSA_MSCC_OCELOT_EXT, which selects the non-existing config MFD_OCELOT_CORE. Replace this select with the intended and existing MFD_OCELOT. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Acked-by: Colin Foster <colin.foster@in-advantage.com> Link: https://lore.kernel.org/r/20230215104631.31568-1-lukas.bulwahn@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16Merge branch 'sfc-devlink-support-for-ef100'Paolo Abeni
Alejandro Lucero says: ==================== sfc: devlink support for ef100 This patchset adds devlink port support for ef100 allowing setting VFs mac addresses through the VF representor devlink ports. Basic devlink infrastructure is first introduced, then support for info command. Next changes for enumerating MAE ports which will be used for devlink port creation when netdevs are registered. Adding support for devlink port_function_hw_addr_get requires changes in the ef100 driver for getting the mac address based on a client handle. This allows to obtain VFs mac addresses during netdev initialization as well what is included in patch 6. Such client handle is used in patches 7 and 8 for getting and setting devlink port addresses. ==================== Link: https://lore.kernel.org/r/20230215090828.11697-1-alejandro.lucero-palau@amd.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16sfc: add support for devlink port_function_hw_addr_set in ef100Alejandro Lucero
Using the builtin client handle id infrastructure, add support for setting the mac address linked to mports in ef100. This implies to execute an MCDI command for giving the address to the firmware for the specific devlink port. Signed-off-by: Alejandro Lucero <alejandro.lucero-palau@amd.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16sfc: add support for devlink port_function_hw_addr_get in ef100Alejandro Lucero
Using the builtin client handle id infrastructure, add support for obtaining the mac address linked to mports in ef100. This implies to execute an MCDI command for getting the data from the firmware for each devlink port. Signed-off-by: Alejandro Lucero <alejandro.lucero-palau@amd.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16sfc: obtain device mac address based on firmware handle for ef100Alejandro Lucero
Getting device mac address is currently based on a specific MCDI command only available for the PF. This patch changes the MCDI command to a generic one for PFs and VFs based on a client handle. This allows both PFs and VFs to ask for their mac address during initialization using the CLIENT_HANDLE_SELF. Moreover, the patch allows other client handles which will be used by the PF to ask for mac addresses linked to VFs. This is necessary for suporting the port_function_hw_addr_get devlink function in further patches. Signed-off-by: Alejandro Lucero <alejandro.lucero-palau@amd.com> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16sfc: add devlink port support for ef100Alejandro Lucero
Using the data when enumerating mports, create devlink ports just before netdevs are registered and remove those devlink ports after netdev has been unregistered. Signed-off-by: Alejandro Lucero <alejandro.lucero-palau@amd.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16sfc: add mport lookup based on driver's mport dataAlejandro Lucero
Obtaining mport id is based on asking the firmware about it. This is still needed for mport initialization itself, but once the mport data is now kept by the driver, further mport id request can be satisfied internally without firmware interaction. Previous function is just modified in name making clear the firmware interaction. The new function uses the old name and looks for the data in the mport data structure. Signed-off-by: Alejandro Lucero <alejandro.lucero-palau@amd.com> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16sfc: enumerate mports in ef100Alejandro Lucero
MAE ports (mports) are the ports on the EF100 embedded switch such as networking PCIe functions, the physical port, and potentially others. Signed-off-by: Alejandro Lucero <alejandro.lucero-palau@amd.com> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16sfc: add devlink info support for ef100Alejandro Lucero
Add devlink info support for ef100. The information reported is obtained through the MCDI interface with the specific meaning defined in new documentation file. Signed-off-by: Alejandro Lucero <alejandro.lucero-palau@amd.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16sfc: add devlink support for ef100Alejandro Lucero
Add devlink infrastructure support. Further patches add devlink info and devlink port support. Signed-off-by: Alejandro Lucero <alejandro.lucero-palau@amd.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Acked-by: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16devlink: Fix netdev notifier chain corruptionIdo Schimmel
Cited commit changed devlink to register its netdev notifier block on the global netdev notifier chain instead of on the per network namespace one. However, when changing the network namespace of the devlink instance, devlink still tries to unregister its notifier block from the chain of the old namespace and register it on the chain of the new namespace. This results in corruption of the notifier chains, as the same notifier block is registered on two different chains: The global one and the per network namespace one. In turn, this causes other problems such as the inability to dismantle namespaces due to netdev reference count issues. Fix by preventing devlink from moving its notifier block between namespaces. Reproducer: # echo "10 1" > /sys/bus/netdevsim/new_device # ip netns add test123 # devlink dev reload netdevsim/netdevsim10 netns test123 # ip netns del test123 [ 71.935619] unregister_netdevice: waiting for lo to become free. Usage count = 2 [ 71.938348] leaked reference. Fixes: 565b4824c39f ("devlink: change port event netdev notifier from per-net to global") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/r/20230215073139.1360108-1-idosch@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16Merge branch 'net-sched-transition-actions-to-pcpu-stats-and-rcu'Paolo Abeni
Pedro Tammela says: ==================== net/sched: transition actions to pcpu stats and rcu Following the work done for act_pedit[0], transition the remaining tc actions to percpu stats and rcu, whenever possible. Percpu stats make updating the action stats very cheap, while combining it with rcu action parameters makes it possible to get rid of the per action lock in the datapath. For act_connmark and act_nat we run the following tests: - tc filter add dev ens2f0 ingress matchall action connmark - tc filter add dev ens2f0 ingress matchall action nat ingress any 10.10.10.10 Our setup consists of a 26 cores Intel CPU and a 25G NIC. We use TRex to shoot 10mpps TCP packets and take perf measurements. Both actions improved performance as expected since the datapath lock disappeared. For act_pedit we move the drop counter to percpu, when available. For act_gate we move the counters to percpu, when available. [0] https://lore.kernel.org/all/20230131145149.3776656-1-pctammela@mojatatu.com/ ==================== Link: https://lore.kernel.org/r/20230214211534.735718-1-pctammela@mojatatu.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16net/sched: act_pedit: use percpu overlimit counter when availablePedro Tammela
Since act_pedit now has access to percpu counters, use the tcf_action_inc_overlimit_qstats wrapper that will use the percpu counter whenever they are available. Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Pedro Tammela <pctammela@mojatatu.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16net/sched: act_gate: use percpu statsPedro Tammela
The tc action act_gate was using shared stats, move it to percpu stats. tdc results: 1..12 ok 1 5153 - Add gate action with priority and sched-entry ok 2 7189 - Add gate action with base-time ok 3 a721 - Add gate action with cycle-time ok 4 c029 - Add gate action with cycle-time-ext ok 5 3719 - Replace gate base-time action ok 6 d821 - Delete gate action with valid index ok 7 3128 - Delete gate action with invalid index ok 8 7837 - List gate actions ok 9 9273 - Flush gate actions ok 10 c829 - Add gate action with duplicate index ok 11 3043 - Add gate action with invalid index ok 12 2930 - Add gate action with cookie Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Pedro Tammela <pctammela@mojatatu.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16net/sched: act_connmark: transition to percpu stats and rcuPedro Tammela
The tc action act_connmark was using shared stats and taking the per action lock in the datapath. Improve it by using percpu stats and rcu. perf before: - 13.55% tcf_connmark_act - 81.18% _raw_spin_lock 80.46% native_queued_spin_lock_slowpath perf after: - 2.85% tcf_connmark_act tdc results: 1..15 ok 1 2002 - Add valid connmark action with defaults ok 2 56a5 - Add valid connmark action with control pass ok 3 7c66 - Add valid connmark action with control drop ok 4 a913 - Add valid connmark action with control pipe ok 5 bdd8 - Add valid connmark action with control reclassify ok 6 b8be - Add valid connmark action with control continue ok 7 d8a6 - Add valid connmark action with control jump ok 8 aae8 - Add valid connmark action with zone argument ok 9 2f0b - Add valid connmark action with invalid zone argument ok 10 9305 - Add connmark action with unsupported argument ok 11 71ca - Add valid connmark action and replace it ok 12 5f8f - Add valid connmark action with cookie ok 13 c506 - Replace connmark with invalid goto chain control ok 14 6571 - Delete connmark action with valid index ok 15 3426 - Delete connmark action with invalid index Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Pedro Tammela <pctammela@mojatatu.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16net/sched: act_nat: transition to percpu stats and rcuPedro Tammela
The tc action act_nat was using shared stats and taking the per action lock in the datapath. Improve it by using percpu stats and rcu. perf before: - 10.48% tcf_nat_act - 81.83% _raw_spin_lock 81.08% native_queued_spin_lock_slowpath perf after: - 0.48% tcf_nat_act tdc results: 1..27 ok 1 7565 - Add nat action on ingress with default control action ok 2 fd79 - Add nat action on ingress with pipe control action ok 3 eab9 - Add nat action on ingress with continue control action ok 4 c53a - Add nat action on ingress with reclassify control action ok 5 76c9 - Add nat action on ingress with jump control action ok 6 24c6 - Add nat action on ingress with drop control action ok 7 2120 - Add nat action on ingress with maximum index value ok 8 3e9d - Add nat action on ingress with invalid index value ok 9 f6c9 - Add nat action on ingress with invalid IP address ok 10 be25 - Add nat action on ingress with invalid argument ok 11 a7bd - Add nat action on ingress with DEFAULT IP address ok 12 ee1e - Add nat action on ingress with ANY IP address ok 13 1de8 - Add nat action on ingress with ALL IP address ok 14 8dba - Add nat action on egress with default control action ok 15 19a7 - Add nat action on egress with pipe control action ok 16 f1d9 - Add nat action on egress with continue control action ok 17 6d4a - Add nat action on egress with reclassify control action ok 18 b313 - Add nat action on egress with jump control action ok 19 d9fc - Add nat action on egress with drop control action ok 20 a895 - Add nat action on egress with DEFAULT IP address ok 21 2572 - Add nat action on egress with ANY IP address ok 22 37f3 - Add nat action on egress with ALL IP address ok 23 6054 - Add nat action on egress with cookie ok 24 79d6 - Add nat action on ingress with cookie ok 25 4b12 - Replace nat action with invalid goto chain control ok 26 b811 - Delete nat action with valid index ok 27 a521 - Delete nat action with invalid index Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Pedro Tammela <pctammela@mojatatu.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16Merge branch 'net-core-commmon-prints-for-promisc'Paolo Abeni
Jesse Brandeburg says: ==================== net/core: commmon prints for promisc Add a print to the kernel log for allmulticast entry and exit, and standardize the print for entry and exit of promiscuous mode. These prints are useful to both user and developer and should have the triggering driver/bus/device info that netdev_info (optionally) gives. ==================== Link: https://lore.kernel.org/r/20230214210117.23123-1-jesse.brandeburg@intel.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16net/core: refactor promiscuous mode messageJesse Brandeburg
The kernel stack can be more consistent by printing the IFF_PROMISC aka promiscuous enable/disable messages with the standard netdev_info message which can include bus and driver info as well as the device. typical command usage from user space looks like: ip link set eth0 promisc <on|off> But lots of utilities such as bridge, tcpdump, etc put the interface into promiscuous mode. old message: [ 406.034418] device eth0 entered promiscuous mode [ 408.424703] device eth0 left promiscuous mode new message: [ 406.034431] ice 0000:17:00.0 eth0: entered promiscuous mode [ 408.424715] ice 0000:17:00.0 eth0: left promiscuous mode Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16net/core: print message for allmulticastJesse Brandeburg
When the user sets or clears the IFF_ALLMULTI flag in the netdev, there are no log messages printed to the kernel log to indicate anything happened. This is inexplicably different from most other dev->flags changes, and could suprise the user. Typically this occurs from user-space when a user: ip link set eth0 allmulticast <on|off> However, other devices like bridge set allmulticast as well, and many other flows might trigger entry into allmulticast as well. The new message uses the standard netdev_info print and looks like: [ 413.246110] ixgbe 0000:17:00.0 eth0: entered allmulticast mode [ 415.977184] ixgbe 0000:17:00.0 eth0: left allmulticast mode Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16wifi: brcmfmac: p2p: Introduce generic flexible array frame memberKees Cook
Silence run-time memcpy() false positive warning when processing management frames: memcpy: detected field-spanning write (size 27) of single field "&mgmt_frame->u" at drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:1469 (size 26) Due to this (soon to be fixed) GCC bug[1], FORTIFY_SOURCE (via __builtin_dynamic_object_size) doesn't recognize that the union may end with a flexible array, and returns "26" (the fixed size of the union), rather than the remaining size of the allocation. Add an explicit flexible array member and set it as the destination here, so that we get the correct coverage for the memcpy(). [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832 Reported-by: Ard Biesheuvel <ardb@kernel.org> Cc: Arend van Spriel <aspriel@gmail.com> Cc: Franky Lin <franky.lin@broadcom.com> Cc: Hante Meuleman <hante.meuleman@broadcom.com> Cc: Kalle Valo <kvalo@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Darrick J. Wong" <djwong@kernel.org> Cc: Colin Ian King <colin.i.king@gmail.com> Cc: Brian Henriquez <brian.henriquez@cypress.com> Cc: linux-wireless@vger.kernel.org Cc: brcm80211-dev-list.pdl@broadcom.com Cc: SHA-cyfmac-dev-list@infineon.com Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230215224110.never.022-kees@kernel.org [rename 'frame' to 'body'] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-02-16Merge branch 'net-sched-retire-some-tc-qdiscs-and-classifiers'Paolo Abeni
Jamal Hadi Salim says: ==================== net/sched: Retire some tc qdiscs and classifiers The CBQ + dsmark qdiscs and the tcindex + rsvp classifiers have served us for over 2 decades. Unfortunately, they have not been getting much attention due to reduced usage. While we dont have a good metric for tabulating how much use a specific kernel feature gets, for these specific features we observed that some of the functionality has been broken for some time and no users complained. In addition, syzkaller has been going to town on most of these and finding issues; and while we have been fixing those issues, at times it becomes obvious that we would need to perform bigger surgeries to resolve things found while getting a syzkaller fix in place. After some discussion we feel that in order to reduce the maintenance burden it is best to retire them. This patchset leaves the UAPI alone. I could send another version which deletes the UAPI as well. AFAIK, this has not been done before - so it wasnt clear what how to handle UAPI. It seems legit to just delete it but we would need to coordinate with iproute2 (given they sync up with kernel uapi headers). There are probably other users we don't know of that copy kernel headers. If folks feel differently I will resend the patches deleting UAPI for these qdiscs and classifiers. I will start another thread on iproute2 before sending any patches to iproute2. ==================== Link: https://lore.kernel.org/r/20230214134915.199004-1-jhs@mojatatu.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-02-16net/sched: Retire rsvp classifierJamal Hadi Salim
The rsvp classifier has served us well for about a quarter of a century but has has not been getting much maintenance attention due to lack of known users. Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Acked-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>