aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-02-28Merge tag 'v6.8-p5' of ↵Linus Torvalds2-4/+13
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "This fixes a regression in lskcipher and an out-of-bound access in arm64/neonbs" * tag 'v6.8-p5' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: arm64/neonbs - fix out-of-bounds access on short input crypto: lskcipher - Copy IV in lskcipher glue code always
2024-02-28Bluetooth: qca: Fix triggering coredump implementationZijun Hu1-5/+4
hci_coredump_qca() uses __hci_cmd_sync() to send a vendor-specific command to trigger firmware coredump, but the command does not have any event as its sync response, so it is not suitable to use __hci_cmd_sync(), fixed by using __hci_cmd_send(). Fixes: 06d3fdfcdf5c ("Bluetooth: hci_qca: Add qcom devcoredump support") Signed-off-by: Zijun Hu <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-02-28Bluetooth: hci_qca: Set BDA quirk bit if fwnode exists in DTJanaki Ramaiah Thota1-1/+12
BT adapter going into UNCONFIGURED state during BT turn ON when devicetree has no local-bd-address node. Bluetooth will not work out of the box on such devices, to avoid this problem, added check to set HCI_QUIRK_USE_BDADDR_PROPERTY based on local-bd-address node entry. When this quirk is not set, the public Bluetooth address read by host from controller though HCI Read BD Address command is considered as valid. Fixes: e668eb1e1578 ("Bluetooth: hci_core: Don't stop BT if the BD address missing in dts") Signed-off-by: Janaki Ramaiah Thota <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-02-28Bluetooth: qca: Fix wrong event type for patch config commandZijun Hu1-1/+1
Vendor-specific command patch config has HCI_Command_Complete event as response, but qca_send_patch_config_cmd() wrongly expects vendor-specific event for the command, fixed by using right event type. Btmon log for the vendor-specific command are shown below: < HCI Command: Vendor (0x3f|0x0000) plen 5 28 01 00 00 00 > HCI Event: Command Complete (0x0e) plen 5 Vendor (0x3f|0x0000) ncmd 1 Status: Success (0x00) 28 Fixes: 4fac8a7ac80b ("Bluetooth: btqca: sequential validation") Signed-off-by: Zijun Hu <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-02-28Bluetooth: Enforce validation on max value of connection intervalKai-Heng Feng2-1/+11
Right now Linux BT stack cannot pass test case "GAP/CONN/CPUP/BV-05-C 'Connection Parameter Update Procedure Invalid Parameters Central Responder'" in Bluetooth Test Suite revision GAP.TS.p44. [0] That was revoled by commit c49a8682fc5d ("Bluetooth: validate BLE connection interval updates"), but later got reverted due to devices like keyboards and mice may require low connection interval. So only validate the max value connection interval to pass the Test Suite, and let devices to request low connection interval if needed. [0] https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=229869 Fixes: 68d19d7d9957 ("Revert "Bluetooth: validate BLE connection interval updates"") Signed-off-by: Kai-Heng Feng <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-02-28Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUESTLuiz Augusto von Dentz1-1/+4
If we received HCI_EV_IO_CAPA_REQUEST while HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote does support SSP since otherwise this event shouldn't be generated. Link: https://lore.kernel.org/linux-bluetooth/CABBYNZ+9UdG1cMZVmdtN3U2aS16AKMCyTARZZyFX7xTEDWcMOw@mail.gmail.com/T/#t Fixes: c7f59461f5a7 ("Bluetooth: Fix a refcnt underflow problem for hci_conn") Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-02-28Bluetooth: mgmt: Fix limited discoverable off timeoutFrédéric Danis1-1/+3
LIMITED_DISCOVERABLE flag is not reset from Class of Device and advertisement on limited discoverable timeout. This prevents to pass PTS test GAP/DISC/LIMM/BV-02-C Calling set_discoverable_sync as when the limited discovery is set correctly update the Class of Device and advertisement. Signed-off-by: Frédéric Danis <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-02-28Bluetooth: hci_event: Fix wrongly recorded wakeup BD_ADDRZijun Hu1-2/+2
hci_store_wake_reason() wrongly parses event HCI_Connection_Request as HCI_Connection_Complete and HCI_Connection_Complete as HCI_Connection_Request, so causes recording wakeup BD_ADDR error and potential stability issue, fix it by using the correct field. Fixes: 2f20216c1d6f ("Bluetooth: Emit controller suspend and resume events") Signed-off-by: Zijun Hu <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-02-28Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_securityYuxuan Hu1-1/+1
During our fuzz testing of the connection and disconnection process at the RFCOMM layer, we discovered this bug. By comparing the packets from a normal connection and disconnection process with the testcase that triggered a KASAN report. We analyzed the cause of this bug as follows: 1. In the packets captured during a normal connection, the host sends a `Read Encryption Key Size` type of `HCI_CMD` packet (Command Opcode: 0x1408) to the controller to inquire the length of encryption key.After receiving this packet, the controller immediately replies with a Command Completepacket (Event Code: 0x0e) to return the Encryption Key Size. 2. In our fuzz test case, the timing of the controller's response to this packet was delayed to an unexpected point: after the RFCOMM and L2CAP layers had disconnected but before the HCI layer had disconnected. 3. After receiving the Encryption Key Size Response at the time described in point 2, the host still called the rfcomm_check_security function. However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;` had already been released, and when the function executed `return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`, specifically when accessing `conn->hcon`, a null-ptr-deref error occurred. To fix this bug, check if `sk->sk_state` is BT_CLOSED before calling rfcomm_recv_frame in rfcomm_process_rx. Signed-off-by: Yuxuan Hu <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-02-28Bluetooth: hci_sync: Fix accept_list when attempting to suspendLuiz Augusto von Dentz1-1/+4
During suspend, only wakeable devices can be in acceptlist, so if the device was previously added it needs to be removed otherwise the device can end up waking up the system prematurely. Fixes: 3b42055388c3 ("Bluetooth: hci_sync: Fix attempting to suspend with unfiltered passive scan") Signed-off-by: Clancy Shang <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Reviewed-by: Paul Menzel <[email protected]>
2024-02-28Bluetooth: Avoid potential use-after-free in hci_error_resetYing Hsu1-3/+4
While handling the HCI_EV_HARDWARE_ERROR event, if the underlying BT controller is not responding, the GPIO reset mechanism would free the hci_dev and lead to a use-after-free in hci_error_reset. Here's the call trace observed on a ChromeOS device with Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>] hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>] process_one_work+0x1d8/0x33f worker_thread+0x21b/0x373 kthread+0x13a/0x152 ? pr_cont_work+0x54/0x54 ? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30 This patch holds the reference count on the hci_dev while processing a HCI_EV_HARDWARE_ERROR event to avoid potential crash. Fixes: c7741d16a57c ("Bluetooth: Perform a power cycle when receiving hardware error event") Signed-off-by: Ying Hsu <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-02-28Bluetooth: hci_sync: Check the correct flag before starting a scanJonas Dreßler1-1/+1
There's a very confusing mistake in the code starting a HCI inquiry: We're calling hci_dev_test_flag() to test for HCI_INQUIRY, but hci_dev_test_flag() checks hdev->dev_flags instead of hdev->flags. HCI_INQUIRY is a bit that's set on hdev->flags, not on hdev->dev_flags though. HCI_INQUIRY equals the integer 7, and in hdev->dev_flags, 7 means HCI_BONDABLE, so we were actually checking for HCI_BONDABLE here. The mistake is only present in the synchronous code for starting an inquiry, not in the async one. Also devices are typically bondable while doing an inquiry, so that might be the reason why nobody noticed it so far. Fixes: abfeea476c68 ("Bluetooth: hci_sync: Convert MGMT_OP_START_DISCOVERY") Signed-off-by: Jonas Dreßler <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-02-28Bluetooth: hci_bcm4377: do not mark valid bd_addr as invalidJohan Hovold1-2/+1
A recent commit restored the original (and still documented) semantics for the HCI_QUIRK_USE_BDADDR_PROPERTY quirk so that the device address is considered invalid unless an address is provided by firmware. This specifically means that this flag must only be set for devices with invalid addresses, but the Broadcom BCM4377 driver has so far been setting this flag unconditionally. Fortunately the driver already checks for invalid addresses during setup and sets the HCI_QUIRK_INVALID_BDADDR flag, which can simply be replaced with HCI_QUIRK_USE_BDADDR_PROPERTY to indicate that the default address is invalid but can be overridden by firmware (long term, this should probably just always be allowed). Fixes: 6945795bc81a ("Bluetooth: fix use-bdaddr-property quirk") Cc: [email protected] # 6.5 Reported-by: Felix Zhang <[email protected]> Link: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Johan Hovold <[email protected]> Reported-by: Felix Zhang <[email protected]> Reviewed-by: Neal Gompa <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2024-02-28Merge branch 'eee-linkmode-bitmaps'David S. Miller12-147/+140
Andrew Lunn says: ==================== drivers: net: Convert EEE handling to use linkmode bitmaps EEE has until recently been limited to lower speeds due to the use of the legacy u32 for link speeds. This restriction has been lifted, with the use of linkmode bitmaps, added in the following patches: 1f069de63602 ethtool: add linkmode bitmap support to struct ethtool_keee 1d756ff13da6 ethtool: add suffix _u32 to legacy bitmap members of struct ethtool_keee 285cc15cc555 ethtool: adjust struct ethtool_keee to kernel needs 0b3100bc8fa7 ethtool: switch back from ethtool_keee to ethtool_eee for ioctl d80a52335374 ethtool: replace struct ethtool_eee with a new struct ethtool_keee on kernel side This patchset converts the remaining MAC drivers still using the old _u32 to link modes. A couple of Intel drivers do odd things with EEE, setting the autoneg bit. It is unclear why, no other driver does, ethtool does not display it, and EEE is always negotiated. One patch in this series deletes this code. With all users of the legacy _u32 changed to link modes, the _u32 values are removed from keee, and support for them in the ethtool core is removed. --- Changes in v5: - Restore zeroing eee_data.advertised in ax8817_178a - Fix lp_advertised -> supported in ixgdb - Link to v4: https://lore.kernel.org/r/[email protected] Changes in v4: - Add missing conversion in igb - Add missing conversion in r8152 - Add patch to remove now unused _u32 members - Link to v3: https://lore.kernel.org/r/[email protected] Changes in v3: - Add list of commits adding linkmodes to EEE to cover letter - Fix grammar error in cover letter. - Add Reviewed-by from Jacob Keller - Link to v2: https://lore.kernel.org/r/[email protected] Changes in v2: - igb: Fix type 100BaseT to 1000BaseT. - Link to v1: https://lore.kernel.org/r/[email protected] ==================== Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28net: ethtool: eee: Remove legacy _u32 from keeeAndrew Lunn3-49/+14
All MAC drivers have been converted to use the link mode members of keee. So remove the _u32 values, and the code in the ethtool core to convert the legacy _u32 values to link modes. Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28net: intel: igc: Use linkmode helpers for EEEAndrew Lunn1-4/+5
Make use of the existing linkmode helpers for converting PHY EEE register values into links modes, now that ethtool_keee uses link modes, rather than u32 values. Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28net: intel: igb: Use linkmode helpers for EEEAndrew Lunn1-12/+23
Make use of the existing linkmode helpers for converting PHY EEE register values into links modes, now that ethtool_keee uses link modes, rather than u32 values. Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28net: intel: e1000e: Use linkmode helpers for EEEAndrew Lunn1-5/+12
Make use of the existing linkmode helpers for converting PHY EEE register values into links modes, now that ethtool_keee uses link modes, rather than u32 values. Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28net: intel: i40e/igc: Remove setting Autoneg in EEE capabilitiesAndrew Lunn2-10/+1
Energy Efficient Ethernet should always be negotiated with the link peer. Don't include SUPPORTED_Autoneg in the results of get_eee() for supported, advertised or lp_advertised, since it is assumed. Additionally, ethtool(1) ignores the set bit, and no other driver sets this. Reviewed-by: Jacob Keller <[email protected]> Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28net: ethernet: ixgbe: Convert EEE to use linkmodesAndrew Lunn1-23/+25
Convert the tables to make use of ETHTOOL link mode bits, rather than the old u32 SUPPORTED speeds. Make use of the linkmode helps to set bits and compare linkmodes. As a result, the _u32 members of keee are no longer used, a step towards removing them. Signed-off-by: Andrew Lunn <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28net: qlogic: qede: Use linkmode helpers for EEEAndrew Lunn1-22/+38
Make use of the existing linkmode helpers for bit manipulation of EEE advertise, support and link partner support. The aim is to drop the restricted _u32 variants in the near future. Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28net: usb: ax88179_178a: Use linkmode helpers for EEEAndrew Lunn1-5/+5
Make use of the existing linkmode helpers for converting PHY EEE register values into links modes, now that ethtool_keee uses link modes, rather than u32 values. Signed-off-by: Andrew Lunn <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28net: usb: r8152: Use linkmode helpers for EEEAndrew Lunn2-17/+17
Make use of the existing linkmode helpers for converting PHY EEE register values into links modes, now that ethtool_keee uses link modes, rather than u32 values. Rework determining if EEE is active to make is similar as to how phylib decides, and make use of a phylib helper to validate if EEE is valid in for the current link mode. This then requires that PHYLIB is selected. Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28ipv6: raw: remove useless input parameter in rawv6_get/seticmpfilterZhengchao Shao1-4/+4
The input parameter 'level' in rawv6_get/seticmpfilter is not used. Therefore, remove it. Signed-off-by: Zhengchao Shao <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28Documentations: correct net_cachelines title for struct inet_sockHaiyue Wang1-3/+3
The fast path usage breakdown describes the detail for 'inet_sock', fix the markup title. Signed-off-by: Haiyue Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28stmmac: Clear variable when destroying workqueueJakub Raczynski1-1/+3
Currently when suspending driver and stopping workqueue it is checked whether workqueue is not NULL and if so, it is destroyed. Function destroy_workqueue() does drain queue and does clear variable, but it does not set workqueue variable to NULL. This can cause kernel/module panic if code attempts to clear workqueue that was not initialized. This scenario is possible when resuming suspended driver in stmmac_resume(), because there is no handling for failed stmmac_hw_setup(), which can fail and return if DMA engine has failed to initialize, and workqueue is initialized after DMA engine. Should DMA engine fail to initialize, resume will proceed normally, but interface won't work and TX queue will eventually timeout, causing 'Reset adapter' error. This then does destroy workqueue during reset process. And since workqueue is initialized after DMA engine and can be skipped, it will cause kernel/module panic. To secure against this possible crash, set workqueue variable to NULL when destroying workqueue. Log/backtrace from crash goes as follows: [88.031977]------------[ cut here ]------------ [88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out [88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398 <Skipping backtrace for watchdog timeout> [88.032251]---[ end trace e70de432e4d5c2c0 ]--- [88.032282]sxgmac 16d88000.ethernet eth0: Reset adapter. [88.036359]------------[ cut here ]------------ [88.036519]Call trace: [88.036523] flush_workqueue+0x3e4/0x430 [88.036528] drain_workqueue+0xc4/0x160 [88.036533] destroy_workqueue+0x40/0x270 [88.036537] stmmac_fpe_stop_wq+0x4c/0x70 [88.036541] stmmac_release+0x278/0x280 [88.036546] __dev_close_many+0xcc/0x158 [88.036551] dev_close_many+0xbc/0x190 [88.036555] dev_close.part.0+0x70/0xc0 [88.036560] dev_close+0x24/0x30 [88.036564] stmmac_service_task+0x110/0x140 [88.036569] process_one_work+0x1d8/0x4a0 [88.036573] worker_thread+0x54/0x408 [88.036578] kthread+0x164/0x170 [88.036583] ret_from_fork+0x10/0x20 [88.036588]---[ end trace e70de432e4d5c2c1 ]--- [88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 Fixes: 5a5586112b929 ("net: stmmac: support FPE link partner hand-shaking procedure") Signed-off-by: Jakub Raczynski <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28net: hsr: Fix typo in the hsr_forward_do() function commentLukasz Majewski1-1/+1
Correct type in the hsr_forward_do() comment. Signed-off-by: Lukasz Majewski <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28net: stmmac: dwmac-qcom-ethqos: Update link clock rate only for RGMIISarosh Hasan1-0/+3
Updating link clock rate for different speeds is only needed when using RGMII, as that mode requires changing clock speed when the link speed changes. Let's restrict updating the link clock speed in ethqos_update_link_clk() to just RGMII. Other modes such as SGMII only need to enable the link clock (which is already done in probe). Signed-off-by: Sarosh Hasan <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Reviewed-by: Andrew Halaney <[email protected]> Tested-by: Andrew Halaney <[email protected]> # sa8775p-ride Reviewed-by: Abhishek Chauhan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28Merge branch 'ioam6-mcast-events'David S. Miller4-0/+92
Justin Iurman says: ==================== ioam6: netlink multicast event v5: - remove the "must be the destination" check before sending an ioam6 event v4: - rebase on top of net merge v3: - patchset was mistakenly superseded due to same cover title used for iproute2-next equivalent patch -> resend (renamed) v2: - fix warnings Add generic netlink multicast event support to ioam6 as another solution to share IOAM data with user space. The other one being via IPv6 raw sockets combined with ancillary data (or packet socket, if the listener does not need the processing of the IOAM Option-Type, since the hook is before in that case). This patchset focuses on the IOAM Pre-allocated Trace (the only Option-Type currently supported in the kernel), and so on IOAM "trace" events. See an example of a consumer here [1]. [1] https://github.com/Advanced-Observability/ioam-agent-python/blob/netlink_event/ioam-agent.py ==================== Signed-off-by: David S. Miller <[email protected]>
2024-02-28net: exthdrs: ioam6: send trace eventJustin Iurman1-0/+4
If we're processing an IOAM Pre-allocated Trace Option-Type (the only one supported currently), then send the trace as an ioam6 event to the netlink multicast group. This way, user space apps will be able to collect IOAM data. Reviewed-by: David Ahern <[email protected]> Signed-off-by: Justin Iurman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28net: ioam6: multicast eventJustin Iurman2-0/+68
Add a multicast group to the ioam6 generic netlink family and provide ioam6_event() to send an ioam6 event to the multicast group. Reviewed-by: David Ahern <[email protected]> Signed-off-by: Justin Iurman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28uapi: ioam6: API for netlink multicast eventsJustin Iurman1-0/+20
Add new api to support ioam6 events for generic netlink multicast. A first "trace" event is added to the list of ioam6 events, which will represent an IOAM Pre-allocated Trace Option-Type. It provides another solution to share IOAM data with user space. Reviewed-by: David Ahern <[email protected]> Signed-off-by: Justin Iurman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28dt-bindings: net: ethernet-controller: drop redundant type from labelKrzysztof Kozlowski1-1/+0
dtschema defines label as string, so $ref in other bindings is redundant. Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28net: ethernet: adi: move PHYLIB from vendor to driver symbolRandy Dunlap1-1/+1
In a previous patch I added "select PHYLIB" at the wrong place for the ADIN1110 driver symbol, so move it to its correct place under the ADIN1110 kconfig symbol. Fixes: a9f80df4f514 ("net: ethernet: adi: requires PHYLIB support") Signed-off-by: Randy Dunlap <[email protected]> Reported-by: Michal Kubecek <[email protected]> Closes: https://lore.kernel.org/lkml/[email protected]/T/#m8ba397484738711edc0ad607b2c63ca02244e3c3 Cc: Lennart Franzen <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Paolo Abeni <[email protected]> Cc: [email protected] Cc: Nuno Sa <[email protected]> Tested-by: Michal Kubecek <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28Merge branch 'tcp-rcv-drop-reasons'David S. Miller8-43/+101
Jason Xing says: ==================== introduce drop reasons for tcp receive path When I was debugging the reason about why the skb should be dropped in syn cookie mode, I found out that this NOT_SPECIFIED reason is too general. Thus I decided to refine it. v10 Link: https://lore.kernel.org/netdev/[email protected]/ 1. fix three nit problems (Kuniyuki) 2. add reviewed-by tag (Kuniyuki) v9 Link: https://lore.kernel.org/netdev/[email protected]/ 1. nit: remove one unneeded 'else' (David) 2. add reviewed-by tags (Eric, David) v8 Link: https://lore.kernel.org/netdev/[email protected]/ 1. refine part of codes in patch [03/10] and patch [10/10] (Eric) 2. squash patch [11/11] in the last version into patch [10/11] (Eric) 3. add reviewed-by tags (Eric) v7 Link: https://lore.kernel.org/all/[email protected]/ 1. fix some misspelled problem (Kuniyuki) 2. remove redundant codes in tcp_v6_do_rcv() (Kuniyuki) 3. add reviewed-by tag in patch [02/11] (Kuniyuki) v6 Link: https://lore.kernel.org/all/[email protected]/ Link: https://lore.kernel.org/all/CAL+tcoAgSjwsmFnDh_Gs9ZgMi-y5awtVx+4VhJPNRADjo7LLSA@mail.gmail.com/ 1. Take one case into consideration in tcp_v6_do_rcv(), behave like old days, or else it will trigger errors (Paolo). 2. Extend NO_SOCKET reason to consider two more reasons for request socket and child socket. v5: Link: https://lore.kernel.org/netdev/[email protected]/ Link: https://lore.kernel.org/netdev/[email protected]/ 1. Use SKB_DROP_REASON_IP_OUTNOROUTES instead of introducing a new one (Eric, David) 2. Reuse SKB_DROP_REASON_NOMEM to handle failure of request socket allocation (Eric) 3. Reuse NO_SOCKET instead of introducing COOKIE_NOCHILD 4. avoid duplication of these opt_skb tests/actions (Eric) 5. Use new name (TCP_ABORT_ON_DATA) for readability (David) 6. Reuse IP_OUTNOROUTES instead of INVALID_DST (Eric) --- HISTORY This series is combined with 2 series sent before suggested by Jakub. So I'm going to separately write changelogs for each of them. PATCH 1/11 - 5/11 preivious Link: https://lore.kernel.org/netdev/[email protected]/ Summary 1. introduce all the dropreasons we need, [1/11] patch. 2. use new dropreasons in ipv4 cookie check, [2/11],[3/11] patch. 3. use new dropreasons ipv6 cookie check, [4/11],[5/11] patch. v4: Link: https://lore.kernel.org/netdev/[email protected]/ 1. Fix misspelled name in Kdoc as suggested by Jakub. v3: Link: https://lore.kernel.org/all/CANn89iK40SoyJ8fS2U5kp3pDruo=zfQNPL-ppOF+LYaS9z-MVA@mail.gmail.com/ 1. Split that patch into some smaller ones as suggested by Eric. v2: Link: https://lore.kernel.org/all/[email protected]/ 1. change the title of 2/2 patch. 2. fix some warnings checkpatch tool showed before. 3. use return value instead of adding more parameters suggested by Eric. PATCH 6/11 - 11/11 previous Link: https://lore.kernel.org/netdev/[email protected]/ v4: Link: https://lore.kernel.org/netdev/CANn89iJar+H3XkQ8HpsirH7b-_sbFe9NBUdAAO3pNJK3CKr_bg@mail.gmail.com/ Link: https://lore.kernel.org/netdev/[email protected]/ Already got rid of @acceptable in tcp_rcv_state_process(), so I need to remove *TCP_CONNREQNOTACCEPTABLE related codes which I wrote in the v3 series. v3: Link: https://lore.kernel.org/all/CANn89iK40SoyJ8fS2U5kp3pDruo=zfQNPL-ppOF+LYaS9z-MVA@mail.gmail.com/ 1. Split that patch into some smaller ones as suggested by Eric. v2: Link: https://lore.kernel.org/all/[email protected]/ 1. change the title of 2/2 patch. 2. fix some warnings checkpatch tool showed before. 3. use return value instead of adding more parameters suggested by Eric. ==================== Signed-off-by: David S. Miller <[email protected]>
2024-02-28tcp: make dropreason in tcp_child_process() workJason Xing2-11/+17
It's time to let it work right now. We've already prepared for this:) Signed-off-by: Jason Xing <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28tcp: make the dropreason really work when calling tcp_rcv_state_process()Jason Xing4-9/+11
Update three callers including both ipv4 and ipv6 and let the dropreason mechanism work in reality. Signed-off-by: Jason Xing <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28tcp: add dropreasons in tcp_rcv_state_process()Jason Xing2-8/+13
In this patch, I equipped this function with more dropreasons, but it still doesn't work yet, which I will do later. Signed-off-by: Jason Xing <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28tcp: add more specific possible drop reasons in tcp_rcv_synsent_state_process()Jason Xing1-1/+4
This patch does two things: 1) add two more new reasons 2) only change the return value(1) to various drop reason values for the future use For now, we still cannot trace those two reasons. We'll implement the full function in the subsequent patch in this series. Signed-off-by: Jason Xing <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28tcp: introduce dropreasons in receive pathJason Xing1-1/+14
Soon later patches can use these relatively more accurate reasons to recognise and find out the cause. Signed-off-by: Jason Xing <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28tcp: use drop reasons in cookie check for ipv6Jason Xing1-4/+12
Like what I did to ipv4 mode, refine this part: adding more drop reasons for better tracing. Signed-off-by: Jason Xing <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28tcp: directly drop skb in cookie check for ipv6Jason Xing2-4/+5
Like previous patch does, only moving skb drop logical code to cookie_v6_check() for later refinement. Signed-off-by: Jason Xing <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28tcp: use drop reasons in cookie check for ipv4Jason Xing1-6/+13
Now it's time to use the prepared definitions to refine this part. Four reasons used might enough for now, I think. Signed-off-by: Jason Xing <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28tcp: directly drop skb in cookie check for ipv4Jason Xing2-1/+5
Only move the skb drop from tcp_v4_do_rcv() to cookie_v4_check() itself, no other changes made. It can help us refine the specific drop reasons later. Signed-off-by: Jason Xing <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28tcp: add a dropreason definitions and prepare for cookie checkJason Xing1-1/+10
Adding one drop reason to detect the condition of skb dropped because of hook points in cookie check and extending NO_SOCKET to consider another two cases can be used later. Signed-off-by: Jason Xing <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28net: make SK_MEMORY_PCPU_RESERV tunableAdam Li4-2/+18
This patch adds /proc/sys/net/core/mem_pcpu_rsv sysctl file, to make SK_MEMORY_PCPU_RESERV tunable. Commit 3cd3399dd7a8 ("net: implement per-cpu reserves for memory_allocated") introduced per-cpu forward alloc cache: "Implement a per-cpu cache of +1/-1 MB, to reduce number of changes to sk->sk_prot->memory_allocated, which would otherwise be cause of false sharing." sk_prot->memory_allocated points to global atomic variable: atomic_long_t tcp_memory_allocated ____cacheline_aligned_in_smp; If increasing the per-cpu cache size from 1MB to e.g. 16MB, changes to sk->sk_prot->memory_allocated can be further reduced. Performance may be improved on system with many cores. Signed-off-by: Adam Li <[email protected]> Reviewed-by: Christoph Lameter (Ampere) <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28Merge branch 'dsa-realtek-reset'David S. Miller4-6/+44
Luiz Angelo Daros de Luca says: ==================== net: dsa: realtek: support reset controller and update docs The driver previously supported reset pins using GPIO, but it lacked support for reset controllers. Although a reset method is generally not required, the driver fails to detect the switch if the reset was kept asserted by a previous driver. This series adds support to reset a Realtek switch using a reset controller. It also updates the binding documentation to remove the requirement of a reset method and to add the new reset controller property. It was tested on a TL-WR1043ND v1 router (rtl8366rb via SMI). Signed-off-by: Luiz Angelo Daros de Luca <[email protected]> --- Changes in v5: - Fixed error checking logic when reset controller (de)assert fails - Link to v4: https://lore.kernel.org/r/[email protected] Changes in v4: - do not test for priv->reset,priv->reset_ctl - updated commit message - Link to v3: https://lore.kernel.org/r/[email protected] Changes in v3: - Rebased on the Realtek DSA driver refactoring (08f627164126) - Dropped the reset controller example in bindings - Used %pe in error printing - Linked to v2: https://lore.kernel.org/r/[email protected]/ Changes in v2: - Introduced a dedicated commit for removing the reset-gpios requirement - Placed binding patches before code changes - Removed the 'reset-names' property - Moved the example from the commit message to realtek.yaml - Split the reset function into _assert/_deassert variants - Modified reset functions to return a warning instead of a value - Utilized devm_reset_control_get_optional to prevent failure when the reset control is missing - Used 'true' and 'false' for boolean values - Removed the CONFIG_RESET_CONTROLLER check as stub methods are sufficient when undefined - Linked to v1: https://lore.kernel.org/r/[email protected]/ ==================== Signed-off-by: David S. Miller <[email protected]>
2024-02-28net: dsa: realtek: support reset controllerLuiz Angelo Daros de Luca3-5/+41
Add support for resetting the device using a reset controller, complementing the existing GPIO reset functionality (reset-gpios). Although the reset is optional and the driver performs a soft reset during setup, if the initial reset pin state was asserted, the driver will not detect the device until the reset is deasserted. Signed-off-by: Luiz Angelo Daros de Luca <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Alvin Šipraga <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28dt-bindings: net: dsa: realtek: add reset controllerLuiz Angelo Daros de Luca1-0/+3
Realtek switches can use a reset controller instead of reset-gpios. Signed-off-by: Luiz Angelo Daros de Luca <[email protected]> Cc: [email protected] Acked-by: Arınç ÜNAL <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Alvin Šipraga <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2024-02-28dt-bindings: net: dsa: realtek: reset-gpios is not requiredLuiz Angelo Daros de Luca1-1/+0
The 'reset-gpios' should not be mandatory. although they might be required for some devices if the switch reset was left asserted by a previous driver, such as the bootloader. Signed-off-by: Luiz Angelo Daros de Luca <[email protected]> Cc: [email protected] Acked-by: Arınç ÜNAL <[email protected]> Acked-by: Rob Herring <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Reviewed-by: Alvin Šipraga <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.