summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-06-22Merge patch series "can: sja1000: Prepare the use of a threaded handler"Marc Kleine-Budde
Miquel Raynal provides a series for the sja1000 driver to work around overrun stalls with a soft reset on Renesas SoCs. Link: https://lore.kernel.org/all/20230616134553.2786391-1-miquel.raynal@bootlin.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: sja1000: Prevent overrun stalls with a soft reset on Renesas SoCsMiquel Raynal
In their RZN1 SoC, Renesas put a CAN controller supposed to act very similarly to the original Philips sja1000. In practice, while flooding the bus with another device, we discovered that the controller very often after an overrun situation would just refuse any new frame, drop them all and trigger over and over again the overrun interrupt, even though the buffer would have been totally emptied. The controller acts like if its internal buffer offsets (where it writes and where the host reads) where totally screwed-up. Renesas manual mentions a single action to perform in order to resynchronize the read and write offsets within the buffer: performing a soft reset. Performing a soft reset takes a bit of time and involves small delays, so better do that in a threaded handler rather than inside the hard IRQ handler. Add platform data to recognize the platforms which need this workaround, and when the faulty situation is diagnosed, stop what is being performed and request the threaded handler to be executed in order to perform the reset. Tested-by: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com> # 5.10 Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/all/20230616134553.2786391-2-miquel.raynal@bootlin.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: sja1000: Prepare the use of a threaded handlerMiquel Raynal
In order to support a flavor of the sja1000 which sometimes freezes, it will be needed upon certain interrupts to perform a soft reset. The soft reset operation takes a bit of time, so better not do it within the hard interrupt handler but rather in a threaded handler. Let's prepare the possibility for sja1000_err() to request "interrupting" the current flow and request the threaded handler to be run while keeping the interrupt line low. There is no functional change. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/all/20230616134553.2786391-1-miquel.raynal@bootlin.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22Merge patch series "can: esd_usb: More preparation before supporting esd ↵Marc Kleine-Budde
CAN-USB/3 (addendum)" Frank Jungclaus <frank.jungclaus@esd.eu> says: While trying to again merge my code changes for CAN-USB/3, I came across some more places where it could make sense to change them analogous to the previous clean-up patch series [1]. [1] [PATCH v2 0/6] can: esd_usb: More preparation before supporting esd CAN-USB/3 Link: https://lore.kernel.org/all/20230519195600.420644-1-frank.jungclaus@esd.eu Link: https://lore.kernel.org/r/20230523173105.3175086-1-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: esd_usb: Use consistent prefix ESD_USB_ for macrosFrank Jungclaus
Rename the following macros: - ESD_RTR to ESD_USB_RTR - ESD_EV_CAN_ERROR_EXT to ESD_USB_EV_CAN_ERROR_EXT Additionally remove the double newline trailing to definition of ESD_USB_RTR. Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/r/20230523173105.3175086-3-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: esd_usb: Make use of kernel macros BIT() and GENMASK()Frank Jungclaus
Make use of kernel macros BIT() and GENMASK(). Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/r/20230523173105.3175086-2-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22Merge patch series "can: esd_usb: More preparation before supporting esd ↵Marc Kleine-Budde
CAN-USB/3" Frank Jungclaus <frank.jungclaus@esd.eu> says: Apply another small batch of patches as preparation for adding support of the newly available esd CAN-USB/3 to esd_usb.c. v1 -> v2: * Make use of GENMASK() macro for ESD_USB_NO_BAUDRATE and ESD_USB_IDMASK * Also use the BIT() macro for ESD_USB2_3_SAMPLES * Removed comments with redundant hexadecimal values from BIT()-constants * Reworded (shortened) the commit messages * Changed the macro ESD_USB_3_SAMPLES to ESD_USB_TRIPLE_SAMPLES v1: * Link: https://lore.kernel.org/all/20230517192251.2405290-1-frank.jungclaus@esd.eu Link: https://lore.kernel.org/r/20230519195600.420644-1-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: esd_usb: Don't bother the user with nonessential log messageFrank Jungclaus
Replace a netdev_info(), emitting an informational message about the BTR value to be send to the controller, with a debug message by means of netdev_dbg(). Link: https://lore.kernel.org/all/20230509-superglue-hazy-38108aa66bfa-mkl@pengutronix.de/ Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de> Suggested-by: Vincent MAILHOL <mailhol.vincent@wanadoo.fr> Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/r/20230519195600.420644-7-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: esd_usb: Replace hardcoded message length given to USB commandsFrank Jungclaus
Replace all hardcoded values supplied to the len element of esd_usb_msg (and its siblings) by more readable expressions, based on sizeof(), offsetof(), etc. Also spend documentation / comments that the len element of esd_usb_msg is in multiples of 32bit words and not in bytes. Link: https://lore.kernel.org/all/CAMZ6RqLaDNy-fZ2G0+QMhUEckkXLL+ZyELVSDFmqpd++aBzZQg@mail.gmail.com/ Suggested-by: Vincent MAILHOL <mailhol.vincent@wanadoo.fr> Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/r/20230519195600.420644-6-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: esd_usb: Prefix all structures with the device nameFrank Jungclaus
Prefix all the structures with the device name. For commonly used structures make use of (the module name) esd_usb_. For esd CAN-USB/2 and CAN-USB/Micro specific structures use esd_usb_2_ and esd_usb_m. Link: https://lore.kernel.org/all/CAMZ6RqLaDNy-fZ2G0+QMhUEckkXLL+ZyELVSDFmqpd++aBzZQg@mail.gmail.com/ Suggested-by: Vincent MAILHOL <mailhol.vincent@wanadoo.fr> Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/r/20230519195600.420644-5-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: esd_usb: Use consistent prefixes for macrosFrank Jungclaus
Add the consistent prefix ESD_USB_ to all macros defined within esd_usb.c. For macros specific to esd CAN-USB/2 use ESD_USB_2_ as prefix. For macros specific to esd CAN-USB/Micro use ESD_USB_M_ as prefix. Change the macro ESD_USB_3_SAMPLES to ESD_USB_TRIPLE_SAMPLES to not mix up with the prefix ESD_USB_3_ which will be introduced for the CAN-USB/3 device. Link: https://lore.kernel.org/all/CAMZ6RqLaDNy-fZ2G0+QMhUEckkXLL+ZyELVSDFmqpd++aBzZQg@mail.gmail.com/ Suggested-by: Vincent MAILHOL <mailhol.vincent@wanadoo.fr> Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/r/20230519195600.420644-4-frank.jungclaus@esd.eu Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-22can: esd_usb: Replace initializer macros used for struct can_bittiming_constFrank Jungclaus
Replace the macros used to initialize the members of struct can_bittiming_const with direct values. Then also use those struct members to do the calculations in esd_usb2_set_bittiming(). Link: https://lore.kernel.org/all/CAMZ6RqLaDNy-fZ2G0+QMhUEckkXLL+ZyELVSDFmqpd++aBzZQg@mail.gmail.com/ Suggested-by: Vincent MAILHOL <mailhol.vincent@wanadoo.fr> Signed-off-by: Frank Jungclaus <frank.jungclaus@esd.eu> Link: https://lore.kernel.org/r/20230519195600.420644-3-frank.jungclaus@esd.eu [mkl: esd_usb2_set_bittiming() use esd_usb2_bittiming_const instead of priv->can.bittiming_const] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-06-21wifi: mac80211: report all unusable beacon framesBenjamin Berg
Properly check for RX_DROP_UNUSABLE now that the new drop reason infrastructure is used. Without this change, the comparison will always be false as a more specific reason is given in the lower bits of result. Fixes: baa951a1c177 ("mac80211: use the new drop reasons infrastructure") Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://lore.kernel.org/r/20230621120543.412920-2-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21Merge branch 'mptcp-expose-more-info-and-small-improvements'Jakub Kicinski
Matthieu Baerts says: ==================== mptcp: expose more info and small improvements Patch 1-3/9 track and expose some aggregated data counters at the MPTCP level: the number of retransmissions and the bytes that have been transferred. The first patch prepares the work by moving where snd_una is updated for fallback sockets while the last patch adds some tests to cover the new code. Patch 4-6/9 introduce a new getsockopt for SOL_MPTCP: MPTCP_FULL_INFO. This new socket option allows to combine info from MPTCP_INFO, MPTCP_TCPINFO and MPTCP_SUBFLOW_ADDRS socket options into one. It can be needed to have all info in one because the path-manager can close and re-create subflows between getsockopt() and fooling the accounting. The first patch introduces a unique subflow ID to easily detect when subflows are being re-created with the same 5-tuple while the last patch adds some tests to cover the new code. Please note that patch 5/9 ("mptcp: introduce MPTCP_FULL_INFO getsockopt") can reveal a bug that were there for a bit of time, see [1]. A fix has recently been fixed to netdev for the -net tree: "mptcp: ensure listener is unhashed before updating the sk status", see [2]. There is no conflicts between the two patches but it might be better to apply this series after the one for -net and after having merged "net" into "net-next". Patch 7/9 is similar to commit 47867f0a7e83 ("selftests: mptcp: join: skip check if MIB counter not supported") recently applied in the -net tree but here it adapts the new code that is only in net-next (and it fixes a merge conflict resolution which didn't have any impact). Patch 8 and 9/9 are two simple refactoring. One to consolidate the transition to TCP_CLOSE in mptcp_do_fastclose() and avoid duplicated code. The other one reduces the scope of an argument passed to mptcp_pm_alloc_anno_list() function. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/407 [1] Link: https://lore.kernel.org/netdev/20230620-upstream-net-20230620-misc-fixes-for-v6-4-v1-0-f36aa5eae8b9@tessares.net/ [2] ==================== Link: https://lore.kernel.org/r/20230620-upstream-net-next-20230620-mptcp-expose-more-info-and-misc-v1-0-62b9444bfd48@tessares.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21mptcp: pass addr to mptcp_pm_alloc_anno_listGeliang Tang
Pass addr parameter to mptcp_pm_alloc_anno_list() instead of entry. We can reduce the scope, e.g. in mptcp_pm_alloc_anno_list(), we only access "entry->addr", we can then restrict to the pointer to "addr" then. Signed-off-by: Geliang Tang <geliang.tang@suse.com> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21mptcp: consolidate transition to TCP_CLOSE in mptcp_do_fastclose()Paolo Abeni
The MPTCP code always set the msk state to TCP_CLOSE before calling performing the fast-close. Move such state transition in mptcp_do_fastclose() to avoid some code duplication. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21selftests: mptcp: join: skip check if MIB counter not supported (part 2)Matthieu Baerts
Selftests are supposed to run on any kernels, including the old ones not supporting all MPTCP features. One of them is the MPTCP MIB counters introduced in commit fc518953bc9c ("mptcp: add and use MIB counter infrastructure") and more later. The MPTCP Join selftest heavily relies on these counters. If a counter is not supported by the kernel, it is not displayed when using 'nstat -z'. We can then detect that and skip the verification. A new helper (get_counter()) has been added recently in the -net tree to do the required checks and return an error if the counter is not available. This commit is similar to the one with the same title applied in the -net tree but it modifies code only present in net-next for the moment, see the Fixes commit below. While at it, we can also remove the use of ${extra_msg} variable which is never assigned in chk_rm_tx_nr() function and use 'echo' without '-n' parameter. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368 Fixes: 0639fa230a21 ("selftests: mptcp: add explicit check for new mibs") Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21selftests: mptcp: add MPTCP_FULL_INFO testcasePaolo Abeni
Add a testcase explicitly triggering the newly introduce MPTCP_FULL_INFO getsockopt. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/388 Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Co-developed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21mptcp: introduce MPTCP_FULL_INFO getsockoptPaolo Abeni
Some user-space applications want to monitor the subflows utilization. Dumping the per subflow tcp_info is not enough, as the PM could close and re-create the subflows under-the-hood, fooling the accounting. Even checking the src/dst addresses used by each subflow could not be enough, because new subflows could re-use the same address/port of the just closed one. This patch introduces a new socket option, allow dumping all the relevant information all-at-once (everything, everywhere...), in a consistent manner. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/388 Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21mptcp: add subflow unique idPaolo Abeni
The user-space need to properly account the data received/sent by individual subflows. When additional subflows are created and/or closed during the MPTCP socket lifetime, the information currently exposed via MPTCP_TCPINFO are not enough: subflows are identified only by the sequential position inside the info dumps, and that will change with the above mentioned events. To solve the above problem, this patch introduces a new subflow identifier that is unique inside the given MPTCP socket scope. The initial subflow get the id 1 and the other subflows get incremental values at join time. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/388 Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21selftests: mptcp: explicitly tests aggregate countersPaolo Abeni
Update the existing sockopt test-case to do some basic checks on the newly added counters. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/385 Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21mptcp: track some aggregate data countersPaolo Abeni
Currently there are no data transfer counters accounting for all the subflows used by a given MPTCP socket. The user-space can compute such figures aggregating the subflow info, but that is inaccurate if any subflow is closed before the MPTCP socket itself. Add the new counters in the MPTCP socket itself and expose them via the existing diag and sockopt. While touching mptcp_diag_fill_info(), acquire the relevant locks before fetching the msk data, to ensure better data consistency Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/385 Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21mptcp: move snd_una update earlier for fallback socketPaolo Abeni
That will avoid an unneeded conditional in both the fast-path and in the fallback case and will simplify a bit the next patch. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21Merge branch 'mptcp-fixes-for-6-4'Jakub Kicinski
Matthieu Baerts says: ==================== mptcp: fixes for 6.4 Patch 1 correctly handles disconnect() failures that can happen in some specific cases: now the socket state is set as unconnected as expected. That fixes an issue introduced in v6.2. Patch 2 fixes a divide by zero bug in mptcp_recvmsg() with a fix similar to a recent one from Eric Dumazet for TCP introducing sk_wait_pending flag. It should address an issue present in MPTCP from almost the beginning, from v5.9. Patch 3 fixes a possible list corruption on passive MPJ even if the race seems very unlikely, better be safe than sorry. The possible issue is present from v5.17. Patch 4 consolidates fallback and non fallback state machines to avoid leaking some MPTCP sockets. The fix is likely needed for versions from v5.11. Patch 5 drops code that is no longer used after the introduction of patch 4/6. This is not really a fix but this patch can probably land in the -net tree as well not to leave unused code. Patch 6 ensures listeners are unhashed before updating their sk status to avoid possible deadlocks when diag info are going to be retrieved with a lock. Even if it should not be visible with the way we are currently getting diag info, the issue is present from v5.17. ==================== Link: https://lore.kernel.org/r/20230620-upstream-net-20230620-misc-fixes-for-v6-4-v1-0-f36aa5eae8b9@tessares.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21mptcp: ensure listener is unhashed before updating the sk statusPaolo Abeni
The MPTCP protocol access the listener subflow in a lockless manner in a couple of places (poll, diag). That works only if the msk itself leaves the listener status only after that the subflow itself has been closed/disconnected. Otherwise we risk deadlock in diag, as reported by Christoph. Address the issue ensuring that the first subflow (the listener one) is always disconnected before updating the msk socket status. Reported-by: Christoph Paasch <cpaasch@apple.com> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/407 Fixes: b29fcfb54cd7 ("mptcp: full disconnect implementation") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21mptcp: drop legacy code around RX EOFPaolo Abeni
Thanks to the previous patch -- "mptcp: consolidate fallback and non fallback state machine" -- we can finally drop the "temporary hack" used to detect rx eof. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21mptcp: consolidate fallback and non fallback state machinePaolo Abeni
An orphaned msk releases the used resources via the worker, when the latter first see the msk in CLOSED status. If the msk status transitions to TCP_CLOSE in the release callback invoked by the worker's final release_sock(), such instance of the workqueue will not take any action. Additionally the MPTCP code prevents scheduling the worker once the socket reaches the CLOSE status: such msk resources will be leaked. The only code path that can trigger the above scenario is the __mptcp_check_send_data_fin() in fallback mode. Address the issue removing the special handling of fallback socket in __mptcp_check_send_data_fin(), consolidating the state machine for fallback and non fallback socket. Since non-fallback sockets do not send and do not receive data_fin, the mptcp code can update the msk internal status to match the next step in the SM every time data fin (ack) should be generated or received. As a consequence we can remove a bunch of checks for fallback from the fastpath. Fixes: 6e628cd3a8f7 ("mptcp: use mptcp release_cb for delayed tasks") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21mptcp: fix possible list corruption on passive MPJPaolo Abeni
At passive MPJ time, if the msk socket lock is held by the user, the new subflow is appended to the msk->join_list under the msk data lock. In mptcp_release_cb()/__mptcp_flush_join_list(), the subflows in that list are moved from the join_list into the conn_list under the msk socket lock. Append and removal could race, possibly corrupting such list. Address the issue splicing the join list into a temporary one while still under the msk data lock. Found by code inspection, the race itself should be almost impossible to trigger in practice. Fixes: 3e5014909b56 ("mptcp: cleanup MPJ subflow list handling") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21mptcp: fix possible divide by zero in recvmsg()Paolo Abeni
Christoph reported a divide by zero bug in mptcp_recvmsg(): divide error: 0000 [#1] PREEMPT SMP CPU: 1 PID: 19978 Comm: syz-executor.6 Not tainted 6.4.0-rc2-gffcc7899081b #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 RIP: 0010:__tcp_select_window+0x30e/0x420 net/ipv4/tcp_output.c:3018 Code: 11 ff 0f b7 cd c1 e9 0c b8 ff ff ff ff d3 e0 89 c1 f7 d1 01 cb 21 c3 eb 17 e8 2e 83 11 ff 31 db eb 0e e8 25 83 11 ff 89 d8 99 <f7> 7c 24 04 29 d3 65 48 8b 04 25 28 00 00 00 48 3b 44 24 10 75 60 RSP: 0018:ffffc90000a07a18 EFLAGS: 00010246 RAX: 000000000000ffd7 RBX: 000000000000ffd7 RCX: 0000000000040000 RDX: 0000000000000000 RSI: 000000000003ffff RDI: 0000000000040000 RBP: 000000000000ffd7 R08: ffffffff820cf297 R09: 0000000000000001 R10: 0000000000000000 R11: ffffffff8103d1a0 R12: 0000000000003f00 R13: 0000000000300000 R14: ffff888101cf3540 R15: 0000000000180000 FS: 00007f9af4c09640(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b33824000 CR3: 000000012f241001 CR4: 0000000000170ee0 Call Trace: <TASK> __tcp_cleanup_rbuf+0x138/0x1d0 net/ipv4/tcp.c:1611 mptcp_recvmsg+0xcb8/0xdd0 net/mptcp/protocol.c:2034 inet_recvmsg+0x127/0x1f0 net/ipv4/af_inet.c:861 ____sys_recvmsg+0x269/0x2b0 net/socket.c:1019 ___sys_recvmsg+0xe6/0x260 net/socket.c:2764 do_recvmmsg+0x1a5/0x470 net/socket.c:2858 __do_sys_recvmmsg net/socket.c:2937 [inline] __se_sys_recvmmsg net/socket.c:2953 [inline] __x64_sys_recvmmsg+0xa6/0x130 net/socket.c:2953 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x47/0xa0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f9af58fc6a9 Code: 5c c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 4f 37 0d 00 f7 d8 64 89 01 48 RSP: 002b:00007f9af4c08cd8 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 00000000006bc050 RCX: 00007f9af58fc6a9 RDX: 0000000000000001 RSI: 0000000020000140 RDI: 0000000000000004 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000f00 R11: 0000000000000246 R12: 00000000006bc05c R13: fffffffffffffea8 R14: 00000000006bc050 R15: 000000000001fe40 </TASK> mptcp_recvmsg is allowed to release the msk socket lock when blocking, and before re-acquiring it another thread could have switched the sock to TCP_LISTEN status - with a prior connect(AF_UNSPEC) - also clearing icsk_ack.rcv_mss. Address the issue preventing the disconnect if some other process is concurrently performing a blocking syscall on the same socket, alike commit 4faeee0cf8a5 ("tcp: deny tcp_disconnect() when threads are waiting"). Fixes: a6b118febbab ("mptcp: add receive buffer auto-tuning") Cc: stable@vger.kernel.org Reported-by: Christoph Paasch <cpaasch@apple.com> Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/404 Signed-off-by: Paolo Abeni <pabeni@redhat.com> Tested-by: Christoph Paasch <cpaasch@apple.com> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21mptcp: handle correctly disconnect() failuresPaolo Abeni
Currently the mptcp code has assumes that disconnect() can fail only at mptcp_sendmsg_fastopen() time - to avoid a deadlock scenario - and don't even bother returning an error code. Soon mptcp_disconnect() will handle more error conditions: let's track them explicitly. As a bonus, explicitly annotate TCP-level disconnect as not failing: the mptcp code never blocks for event on the subflows. Fixes: 7d803344fdc3 ("mptcp: fix deadlock in fastopen error path") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Tested-by: Christoph Paasch <cpaasch@apple.com> Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21net: ena: Fix rst format issues in readmeDavid Arinzon
This patch fixes a warning in the ena documentation file identified by the kernel automatic tools. The patch also adds a missing newline between sections. Signed-off-by: David Arinzon <darinzon@amazon.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306171804.U7E92zoE-lkp@intel.com/ Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230620133544.32584-1-darinzon@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21dt-bindings: arm: socionext: add Synquacer platformsJassi Brar
Socionext's DeveloperBox is based on the SC2A11B SoC (Synquacer). Specify bindings for the platform and boards based on that. Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Link: https://lore.kernel.org/r/20230621153658.60646-1-jaswinder.singh@linaro.org Signed-off-by: Rob Herring <robh@kernel.org>
2023-06-21dt-bindings: connector: usb: allow a single HS portFabrice Gasnier
Allow a single HS port to be used e.g. without reg property and a unit address. OF graph allows a single port node, without 'reg' property. This removes a couple of Warnings or errors on STM32MP boards. When using single HS port currently, when doing building with W=1: arch/arm/boot/dts/stm32mp157c-dk2.dtb: stusb1600@28: connector: Unevaluated properties are not allowed ('port' was unexpected) Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Link: https://lore.kernel.org/r/20230620085633.533187-1-fabrice.gasnier@foss.st.com Signed-off-by: Rob Herring <robh@kernel.org>
2023-06-21inet: Cleanup on charging memory for newly accepted socketsAbel Wu
If there is no net-memcg associated with the sock, don't bother calculating its memory usage for charge. Signed-off-by: Abel Wu <wuyun.abel@bytedance.com> Link: https://lore.kernel.org/r/20230620092712.16217-1-wuyun.abel@bytedance.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21selftests: tc-testing: add one test for flushing explicitly created chainrenmingshuai
Add the test for additional reference to chains that are explicitly created by RTM_NEWCHAIN message. The test result: 1..1 ok 1 c2b4 - soft lockup alarm will be not generated after delete the prio 0 filter of the chain This is a follow up to commit c9a82bec02c3 ("net/sched: cls_api: Fix lockup on flushing explicitly created chain"). Signed-off-by: Mingshuai Ren <renmingshuai@huawei.com> Acked-by: Pedro Tammela <pctammela@mojatatu.com> Acked-by: Victor Nogueira <victor@mojatatu.com> Link: https://lore.kernel.org/r/20230620014939.2034054-1-renmingshuai@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21dt-bindings: net: micrel,ks8851: allow SPI device propertiesKrzysztof Kozlowski
The Micrel KS8851 can be attached to SPI or parallel bus and the difference is expressed in compatibles. Allow common SPI properties when this is a SPI variant and narrow the parallel memory bus properties to the second case. This fixes dtbs_check warning: qcom-msm8960-cdp.dtb: ethernet@0: Unevaluated properties are not allowed ('spi-max-frequency' was unexpected) Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230619170134.65395-1-krzysztof.kozlowski@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21dt-bindings: net: bluetooth: qualcomm: document VDD_CH1Krzysztof Kozlowski
WCN3990 comes with two chains - CH0 and CH1 - where each takes VDD regulator. It seems VDD_CH1 is optional (Linux driver does not care about it), so document it to fix dtbs_check warnings like: sdm850-lenovo-yoga-c630.dtb: bluetooth: 'vddch1-supply' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230617165716.279857-1-krzysztof.kozlowski@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21net: hsr: Disable promiscuous mode in offload modeRavi Gunasekaran
When port-to-port forwarding for interfaces in HSR node is enabled, disable promiscuous mode since L2 frame forward happens at the offloaded hardware. Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230614114710.31400-1-r-gunasekaran@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21selftests/bpf: Add vrf_socket_lookup testsGilad Sever
Verify that socket lookup via TC/XDP with all BPF APIs is VRF aware. Signed-off-by: Gilad Sever <gilad9366@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Eyal Birger <eyal.birger@gmail.com> Acked-by: Stanislav Fomichev <sdf@google.com> Link: https://lore.kernel.org/bpf/20230621104211.301902-5-gilad9366@gmail.com
2023-06-21bpf: Fix bpf socket lookup from tc/xdp to respect socket VRF bindingsGilad Sever
When calling bpf_sk_lookup_tcp(), bpf_sk_lookup_udp() or bpf_skc_lookup_tcp() from tc/xdp ingress, VRF socket bindings aren't respoected, i.e. unbound sockets are returned, and bound sockets aren't found. VRF binding is determined by the sdif argument to sk_lookup(), however when called from tc the IP SKB control block isn't initialized and thus inet{,6}_sdif() always returns 0. Fix by calculating sdif for the tc/xdp flows by observing the device's l3 enslaved state. The cg/sk_skb hooking points which are expected to support inet{,6}_sdif() pass sdif=-1 which makes __bpf_skc_lookup() use the existing logic. Fixes: 6acc9b432e67 ("bpf: Add helper to retrieve socket in BPF") Signed-off-by: Gilad Sever <gilad9366@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Reviewed-by: Eyal Birger <eyal.birger@gmail.com> Acked-by: Stanislav Fomichev <sdf@google.com> Cc: David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/bpf/20230621104211.301902-4-gilad9366@gmail.com
2023-06-21bpf: Call __bpf_sk_lookup()/__bpf_skc_lookup() directly via TC hookpointGilad Sever
skb->dev always exists in the tc flow. There is no need to use bpf_skc_lookup(), bpf_sk_lookup() from this code path. This change facilitates fixing the tc flow to be VRF aware. Signed-off-by: Gilad Sever <gilad9366@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Reviewed-by: Eyal Birger <eyal.birger@gmail.com> Acked-by: Stanislav Fomichev <sdf@google.com> Link: https://lore.kernel.org/bpf/20230621104211.301902-3-gilad9366@gmail.com
2023-06-21bpf: Factor out socket lookup functions for the TC hookpoint.Gilad Sever
Change BPF helper socket lookup functions to use TC specific variants: bpf_tc_sk_lookup_tcp() / bpf_tc_sk_lookup_udp() / bpf_tc_skc_lookup_tcp() instead of sharing implementation with the cg / sk_skb hooking points. This allows introducing a separate logic for the TC flow. The tc functions are identical to the original code. Signed-off-by: Gilad Sever <gilad9366@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> Reviewed-by: Eyal Birger <eyal.birger@gmail.com> Acked-by: Stanislav Fomichev <sdf@google.com> Link: https://lore.kernel.org/bpf/20230621104211.301902-2-gilad9366@gmail.com
2023-06-21Merge branch 'leds-trigger-netdev-add-additional-modes'Jakub Kicinski
Christian Marangi says: ==================== leds: trigger: netdev: add additional modes This is a continue of [1]. It was decided to take a more gradual approach to implement LEDs support for switch and phy starting with basic support and then implementing the hw control part when we have all the prereq done. This should be the final part for the netdev trigger. I added net-next tag and added netdev mailing list since I was informed that this should be merged with netdev branch. We collect some info around and we found a good set of modes that are common in almost all the PHY and Switch. These modes are: - Modes for dedicated link speed(10, 100, 1000 mbps). Additional mode can be added later following this example. - Modes for half and full duplex. The original idea was to add hw control only modes. While the concept makes sense in practice it would results in lots of additional code and extra check to make sure we are setting correct modes. With the suggestion from Andrew it was pointed out that using the ethtool APIs we can actually get the current link speed and duplex and this effectively removed the problem of having hw control only modes since we can fallback to software. Since these modes are supported by software, we can skip providing an user for this in the LED driver to support hw control for these new modes (that will come right after this is merged) and prevent this to be another multi subsystem series. For link speed and duplex we use ethtool APIs. To call ethtool APIs, rtnl lock is needed but this can be skipped on handling netdev events as the lock is already held. [1] https://lore.kernel.org/lkml/20230216013230.22978-1-ansuelsmth@gmail.com/ ==================== Link: https://lore.kernel.org/r/20230619204700.6665-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21leds: trigger: netdev: expose hw_control status via sysfsChristian Marangi
Expose hw_control status via sysfs for the netdev trigger to give userspace better understanding of the current state of the trigger and the LED. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21leds: trigger: netdev: add additional specific link duplex modeChristian Marangi
Add additional modes for specific link duplex. Use ethtool APIs to get the current link duplex and enable the LED accordingly. Under netdev event handler the rtnl lock is already held and is not needed to be set to access ethtool APIs. This is especially useful for PHY and Switch that supports LEDs hw control for specific link duplex. Add additional modes: - half_duplex: Turn on LED when link is half duplex - full_duplex: Turn on LED when link is full duplex Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21leds: trigger: netdev: add additional specific link speed modeChristian Marangi
Add additional modes for specific link speed. Use ethtool APIs to get the current link speed and enable the LED accordingly. Under netdev event handler the rtnl lock is already held and is not needed to be set to access ethtool APIs. This is especially useful for PHY and Switch that supports LEDs hw control for specific link speed. (example scenario a PHY that have 2 LED connected one green and one orange where the green is turned on with 1000mbps speed and orange is turned on with 10mpbs speed) On mode set from sysfs we check if we have enabled split link speed mode and reject enabling generic link mode to prevent wrong and redundant configuration. Rework logic on the set baseline state to support these new modes to select if we need to turn on or off the LED. Add additional modes: - link_10: Turn on LED when link speed is 10mbps - link_100: Turn on LED when link speed is 100mbps - link_1000: Turn on LED when link speed is 1000mbps Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21bnxt_en: Link representors to PCI deviceIvan Vecera
Link VF representors to parent PCI device to benefit from systemd defined naming scheme. Without this change the representor is visible as ethN. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20230620144855.288443-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21Merge branch ↵Jakub Kicinski
'selftests-preparations-for-out-of-order-operations-patches-in-mlxsw' Petr Machata says: ==================== selftests: Preparations for out-of-order-operations patches in mlxsw The mlxsw driver currently makes the assumption that the user applies configuration in a bottom-up manner. Thus netdevices need to be added to the bridge before IP addresses are configured on that bridge or SVI added on top of it. Enslaving a netdevice to another netdevice that already has uppers is in fact forbidden by mlxsw for this reason. Despite this safety, it is rather easy to get into situations where the offloaded configuration is just plain wrong. Over the course of the following several patchsets, mlxsw code is going to be adjusted to diminish the space of wrongly offloaded configurations. Ideally the offload state will reflect the actual state, regardless of the sequence of operation used to construct that state. Several selftests build configurations that will not be offloadable in the future on some systems. The reason is that what will get offloaded is the actual configuration, not the configuration steps. For example, when a port is added to a bridge that has an IP address, that bridge will get a RIF, which it would not have with the current code. But on Nvidia Spectrum-1 machines, MAC addresses of all RIFs need to have the same prefix, which the bridge will violate. The RIF thus couldn't be created, and the enslavement is therefore canceled, because it would lead to an unoffloadable configuration. This breaks some selftests. In this patchset, adjust selftests to avoid the configurations that mlxsw would be incapable of offloading, while maintaining relevance with regards to the feature that is being tested. There are generally two cases of fixes: - Disabling IPv6 autogen on bridges that do not participate in routing, either because of the abovementioned requirement to keep the same MAC prefix on all in-HW router interfaces, or, on 802.1ad bridges, because in-HW router interfaces are not supported at all. - Setting the bridge MAC address to what it will become after the first member port is attached, so that the in-HW router interface is created with a supported MAC address. The patchset is then split thus: - Patches #1-#7 adjust generic selftests - Patches #8-#16 adjust mlxsw-specific selftests ==================== Link: https://lore.kernel.org/r/cover.1687265905.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21selftests: mlxsw: one_armed_router: Use port MAC for bridge addressPetr Machata
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge, the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The bridge eventually inherits MAC address from its first member, after the enslavement is acked. A number of (mainly VXLAN) selftests already work around the problem by setting the MAC address to whatever it will eventually be anyway. Do the same for this selftest. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21selftests: mlxsw: vxlan: Disable IPv6 autogen on bridgesPetr Machata
In a future patch, mlxsw will start adding RIFs to uppers of front panel port netdevices, if they have an IP address. At the time that the front panel port is enslaved to the bridge (this holds for all bridges used here), the bridge MAC address does not have the same prefix as other interfaces in the system. On Nvidia Spectrum-1 machines all the RIFs have to have the same 38-bit MAC address prefix. Since the bridge does not obey this limitation, the RIF cannot be created, and the enslavement attempt is vetoed on the grounds of the configuration not being offloadable. The selftest itself however checks various aspects of VXLAN offloading and the bridges do not need to participate in routing traffic. The IP addresses or the RIFs are irrelevant. Fix by disabling automatic IPv6 address generation for the HW-offloaded bridges in this selftest, thus exempting them from mlxsw router attention. Signed-off-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-14 20:34:15 +0000