* Re: [PATCH net-next v6 1/2] net: dsa: realtek: rtl8365mb: add SGMII support for RTL8367S
From: Stanislaw @ 2026-07-21 11:53 UTC (permalink / raw)
To: Johan Alvarado, Mieczyslaw Nalewaj
Cc: Linus Walleij, Alvin Sipraga, Andrew Lunn, Vladimir Oltean,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Russell King, Maxime Chevallier, Luiz Angelo Daros de Luca,
netdev, linux-kernel
In-Reply-To: <CAJq09z4TX=LFOX7iq2g_JwkjtLM1U_Q=aYvAkd123LgOwZNyUw@mail.gmail.com>
Hi Luiz, Johan, Mieczyslaw,
Resolved, and it was not the driver: the cold-start trunk failure on my
Archer AX55 v1 was a failing power supply. Apologies for the noise, and
thanks for the time you all put into it.
The A/B/A that settles it, same image throughout (v6 series, no
busy-wait, no 0x060C writes, no pre-init delay), same ~10 h power-off:
old PSU -> bad on every cold morning (4 documented occurrences)
new PSU -> clean, twice (including a 10 h soak)
old PSU again -> bad again, last night
The last line is the one that matters: putting the old supply back
reproduced the exact same signature - link up at 2.5G/Full, no CRC or
symbol errors on the link, but 326 FCS errors and 326 drop events on
the switch's CPU-facing port, nothing reaching the WAN wire, and the
switch->CPU direction byte-exact clean. Only the switch's SerDes
receiver is affected, and only until the chip is fully re-initialised.
In hindsight the earlier evidence fits: the 180 s pre-init delay
"fixed" it because it gave the supply three minutes to come up, short
power-cycles never reproduced it because the capacitors had no time to
discharge, and a driver re-probe cured it because... well, see below.
> Another test would be to dump all switch regs before the first reset
> and compare what is different from the state after the reset.
Done, via the regmap debugfs. The SerDes-related configuration is
byte-identical between the bad state and the healthy one afterwards:
SDS_MISC (0x1d11) bad 0x1f00 good 0x1f00
SDS_OPTION (0x13c0/c1) bad 0x0000 good 0x0000
ext-if mode (0x1311) bad 0x1016 good 0x1016
MISC_CFG0 (0x130c) bad 0x0043 good 0x0043
So the driver programs the chip identically in both cases; the failure
is not visible in the register state at all. (The rest of the dump does
differ, but that is counters and statistics, and the "good" dump was
taken after the reset experiments below, so I would not read anything
into it.)
> I would expect the CHIP_RST (bit 0) to clear everything, but you
> never know...
Also done, on the bad state, in the order SDS -> DW8051 -> NIC -> GPH
-> CFG -> SW -> CHIP:
SDS_RST, DW8051_RST, NIC_RST, GPH_RST: no change at all, the FCS
error count stays exactly where it was and the trunk stays dead.
CFG_RST, SW_RST, CHIP_RST: inconclusive. The counters go to zero, but
so does the switch configuration, so the trunk cannot pass traffic
afterwards for reasons that have nothing to do with the fault. I
cannot tell from this whether the datapath was repaired.
Full driver re-probe (reset + complete re-init): cures it, as always.
The useful half is the first line: none of the resets that leave the
configuration intact repairs the datapath. Whatever the marginal supply
does to that receiver, only a complete re-initialisation clears it -
which is consistent with the register dump showing no difference to
repair in the first place.
I will run one more cold soak tomorrow morning, back on the new supply,
to confirm the A/B/A closes cleanly rather than resting on a single
good/bad pair. I will only write again if that result contradicts the
above.
Nothing here asks for a change to your series. If the maintainers want
a Tested-by for the RTL8367S HSGMII path on this board, it has been
carrying traffic reliably for days now on a healthy supply.
Best regards,
Stanislaw
^ permalink raw reply
* [PATCH wireless v2] wifi: mac80211_hwsim: reject undersized HWSIM_ATTR_TX_INFO
From: Ibrahim Hashimov @ 2026-07-21 11:53 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev, linux-kernel, stable
hwsim_tx_info_frame_received_nl() casts the HWSIM_ATTR_TX_INFO payload
to a struct hwsim_tx_rate * and unconditionally reads
IEEE80211_TX_MAX_RATES entries (8 bytes) from it. The policy only bounds
the attribute from above (NLA_BINARY .len is a maximum) and the op sets
GENL_DONT_VALIDATE_STRICT, so a short or zero-length attribute is
accepted and the loop reads past the payload.
Require the exact length in the policy, so a malformed attribute is
rejected before the handler runs.
Fixes: 7882513bacb1 ("mac80211_hwsim driver support userspace frame tx/rx")
Cc: stable@vger.kernel.org
Signed-off-by: Ibrahim Hashimov <security@auditcode.ai>
Assisted-by: AuditCode-AI:2026.07
---
v2: enforce the length via NLA_POLICY_EXACT_LEN in the policy instead of
a manual nla_len() check in the handler, and trim the changelog, per
Johannes Berg's review.
drivers/net/wireless/virtual/mac80211_hwsim_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/virtual/mac80211_hwsim_main.c b/drivers/net/wireless/virtual/mac80211_hwsim_main.c
index 0dd8a6c85953..836dd25e5c61 100644
--- a/drivers/net/wireless/virtual/mac80211_hwsim_main.c
+++ b/drivers/net/wireless/virtual/mac80211_hwsim_main.c
@@ -870,9 +870,9 @@ static const struct nla_policy hwsim_genl_policy[HWSIM_ATTR_MAX + 1] = {
[HWSIM_ATTR_FLAGS] = { .type = NLA_U32 },
[HWSIM_ATTR_RX_RATE] = { .type = NLA_U32 },
[HWSIM_ATTR_SIGNAL] = { .type = NLA_U32 },
- [HWSIM_ATTR_TX_INFO] = { .type = NLA_BINARY,
- .len = IEEE80211_TX_MAX_RATES *
- sizeof(struct hwsim_tx_rate)},
+ [HWSIM_ATTR_TX_INFO] =
+ NLA_POLICY_EXACT_LEN(IEEE80211_TX_MAX_RATES *
+ sizeof(struct hwsim_tx_rate)),
[HWSIM_ATTR_COOKIE] = { .type = NLA_U64 },
[HWSIM_ATTR_CHANNELS] = { .type = NLA_U32 },
[HWSIM_ATTR_RADIO_ID] = { .type = NLA_U32 },
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH] ovpn: prevent UAF re-add to by_transp_addr on float-vs-delete race
From: Ibrahim Hashimov @ 2026-07-21 11:54 UTC (permalink / raw)
To: antonio; +Cc: openvpn-devel, netdev, linux-kernel
In-Reply-To: <524c6b9d-352c-4f84-bc8a-802dad97d909@openvpn.net>
Thanks for the pointer, and no worries about the delay. That commit is
the same fix -- please drop mine, I'll drop it on my side. Thanks for
handling it.
Ibrahim
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: net: qcom,bam-dmux: Add qcom,shikra-bam-dmux compatible
From: Konrad Dybcio @ 2026-07-21 11:57 UTC (permalink / raw)
To: Vishnu Santhosh, Stephan Gerhold
Cc: Stephan Gerhold, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Loic Poulain, Sergey Ryazanov, Johannes Berg,
linux-arm-msm, netdev, devicetree, linux-kernel, chris.lew,
Deepak Kumar Singh
In-Reply-To: <3a32a44d-4044-4270-beec-565171ad4bff@oss.qualcomm.com>
On 7/14/26 4:03 PM, Vishnu Santhosh wrote:
>
> On 14-07-2026 12:41 pm, Stephan Gerhold wrote:
>> On Tue, Jul 14, 2026 at 11:02:31AM +0530, Vishnu Santhosh wrote:
>>> On platforms where the modem DMAs into the BAM-DMUX RX data buffers and
>>> the XPU enforces per-region access control, each individually
>>> DMA-mapped RX buffer consumes an XPU resource group. With only ~16
>>> groups available, the per-buffer mappings exhaust the table and inbound
>>> transfers fault.
>>>
>>> Add qcom,shikra-bam-dmux as an additional compatible for the Shikra SoC,
>>> paired with the generic qcom,bam-dmux fallback, so the driver can match
>>> on it via its of_device_id table.
>>>
>>> Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
>>> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
>>> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
>> IMHO (the DT maintainers might disagree) this is not a different
>> BAM DMUX hardware block on Shikra, just a different firmware
>> configuration. I'm sure the existing SoCs also have those XPU blocks,
>> they just don't make use of it.
>>
>> Personally, I would rather describe this with an optional "qcom,vmid"
>> property similar to your bam-dma patch, allowed for all SoCs.
>>
>> Thanks,
>> Stephan
>
> Thanks Stephan. Adding Konrad (Cc), since this compatible-string /
> match-data approach was his suggestion on an earlier revision of this
> series send for internal review, specifically because BAM-DMUX is a
> singleton per SoC.
>
> Konrad, given Stephan's point, would you still prefer the
> compatible-string / match-data approach, or does the optional
> qcom,vmid property (matching the bam-dma series) make more sense here?
>
> Happy to go either way once you've both aligned.
This all depends on whether the DT maintainers grant you the right to
introduce a new property and in this case I very much doubt that
Konrad
^ permalink raw reply
* Re: [PATCH net-next v9 00/12] net: pcs: Introduce support for fwnode PCS
From: Maxime Chevallier @ 2026-07-21 11:58 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260717065448.1498335-1-ansuelsmth@gmail.com>
Hi Christian,
On 7/17/26 08:54, Christian Marangi wrote:
> This series introduce a most awaited feature that is correctly
> provide PCS with fwnode without having to use specific export symbol
> and additional handling of PCS in phylink.
I was finally able to spend a bit of time digging deeper, I ported the
mvpp2 driver to your new API to test that dynamic PCS selection for
internal PCSs still works, and it's all good :)
Congrats on that work !
This didn't exercise all code paths, especially with the fwnode API but
you've tested that enough on your side :)
Maxime
The patch I used for testing if you're curious :
(I'll send that once this series land, or you can include it but I don't
want to delay your work in case the patch goes through rounds of reviews...)
--- 8>< -----------------------------------------------------------------
From 38ad94b1e62bf3523097983dfb515f59b1634477 Mon Sep 17 00:00:00 2001
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date: Tue, 21 Jul 2026 13:52:57 +0200
Subject: [PATCH] net: marvell: mvpp2: Convert to the new PCS API
Following the introduction of the PCS framework, port mvpp2 to the new
PCS API.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
.../net/ethernet/marvell/mvpp2/mvpp2_main.c | 161 +++++++++++-------
1 file changed, 95 insertions(+), 66 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index ccc24a1301f2..8d9663c7a023 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -6499,21 +6499,6 @@ static void mvpp2_gmac_config(struct mvpp2_port *port, unsigned int mode,
writel(ctrl4, port->base + MVPP22_GMAC_CTRL_4_REG);
}
-static struct phylink_pcs *mvpp2_select_pcs(struct phylink_config *config,
- phy_interface_t interface)
-{
- struct mvpp2_port *port = mvpp2_phylink_to_port(config);
-
- /* Select the appropriate PCS operations depending on the
- * configured interface mode. We will only switch to a mode
- * that the validate() checks have already passed.
- */
- if (mvpp2_is_xlg(interface))
- return &port->pcs_xlg;
- else
- return &port->pcs_gmac;
-}
-
static int mvpp2_mac_prepare(struct phylink_config *config, unsigned int mode,
phy_interface_t interface)
{
@@ -6786,7 +6771,6 @@ static int mvpp2_mac_enable_tx_lpi(struct phylink_config *config, u32 timer,
}
static const struct phylink_mac_ops mvpp2_phylink_ops = {
- .mac_select_pcs = mvpp2_select_pcs,
.mac_prepare = mvpp2_mac_prepare,
.mac_config = mvpp2_mac_config,
.mac_finish = mvpp2_mac_finish,
@@ -6808,7 +6792,10 @@ static void mvpp2_acpi_start(struct mvpp2_port *port)
};
struct phylink_pcs *pcs;
- pcs = mvpp2_select_pcs(&port->phylink_config, port->phy_interface);
+ if (mvpp2_is_xlg(port->phy_interface))
+ pcs = &port->pcs_xlg;
+ else
+ pcs = &port->pcs_gmac;
mvpp2_mac_prepare(&port->phylink_config, MLO_AN_INBAND,
port->phy_interface);
@@ -6823,6 +6810,78 @@ static void mvpp2_acpi_start(struct mvpp2_port *port)
SPEED_UNKNOWN, DUPLEX_UNKNOWN, false, false);
}
+static int mvpp2_port_fill_pcs(struct phylink_config *config,
+ struct phylink_pcs **available_pcs,
+ unsigned int num_possible_pcs)
+{
+ struct mvpp2_port *port = mvpp2_phylink_to_port(config);
+
+ available_pcs[0] = &port->pcs_gmac;
+
+ if (mvpp2_port_supports_xlg(port)) {
+ if (num_possible_pcs < 2)
+ return -EINVAL;
+
+ available_pcs[1] = &port->pcs_xlg;
+ }
+
+ return 0;
+}
+
+static void mvpp2_port_init_pcs_xlg(struct phylink_pcs *pcs, bool has_comphy,
+ phy_interface_t phy_mode)
+{
+ if (has_comphy) {
+ __set_bit(PHY_INTERFACE_MODE_5GBASER,
+ pcs->supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_10GBASER,
+ pcs->supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_XAUI,
+ pcs->supported_interfaces);
+ } else if (phy_mode == PHY_INTERFACE_MODE_5GBASER) {
+ __set_bit(PHY_INTERFACE_MODE_5GBASER,
+ pcs->supported_interfaces);
+ } else if (phy_mode == PHY_INTERFACE_MODE_10GBASER) {
+ __set_bit(PHY_INTERFACE_MODE_10GBASER,
+ pcs->supported_interfaces);
+ } else if (phy_mode == PHY_INTERFACE_MODE_XAUI) {
+ __set_bit(PHY_INTERFACE_MODE_XAUI,
+ pcs->supported_interfaces);
+ }
+}
+
+static void mvpp2_port_init_pcs_gmac(struct phylink_pcs *pcs, bool has_comphy,
+ phy_interface_t phy_mode)
+{
+ if (has_comphy) {
+ /* If a COMPHY is present, we can support any of the
+ * serdes modes and switch between them.
+ */
+ __set_bit(PHY_INTERFACE_MODE_SGMII,
+ pcs->supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_1000BASEX,
+ pcs->supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_2500BASEX,
+ pcs->supported_interfaces);
+ } else if (phy_mode == PHY_INTERFACE_MODE_2500BASEX) {
+ /* No COMPHY, with only 2500BASE-X mode supported */
+ __set_bit(PHY_INTERFACE_MODE_2500BASEX,
+ pcs->supported_interfaces);
+ } else if (phy_mode == PHY_INTERFACE_MODE_1000BASEX ||
+ phy_mode == PHY_INTERFACE_MODE_SGMII) {
+ /* No COMPHY, we can switch between 1000BASE-X and SGMII
+ */
+ __set_bit(PHY_INTERFACE_MODE_1000BASEX,
+ pcs->supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_SGMII,
+ pcs->supported_interfaces);
+ }
+
+ /* RGMII and MII are still routed through the gmac PCS */
+ phy_interface_set_rgmii(pcs->supported_interfaces);
+ __set_bit(PHY_INTERFACE_MODE_MII, pcs->supported_interfaces);
+}
+
/* In order to ensure backward compatibility for ACPI, check if the port
* firmware node comprises the necessary description allowing to use phylink.
*/
@@ -7082,28 +7141,17 @@ static int mvpp2_port_probe(struct platform_device *pdev,
port->phylink_config.mac_capabilities |=
MAC_SYM_PAUSE | MAC_ASYM_PAUSE;
- if (mvpp2_port_supports_xlg(port)) {
- /* If a COMPHY is present, we can support any of
- * the serdes modes and switch between them.
- */
- if (comphy) {
- __set_bit(PHY_INTERFACE_MODE_5GBASER,
- port->phylink_config.supported_interfaces);
- __set_bit(PHY_INTERFACE_MODE_10GBASER,
- port->phylink_config.supported_interfaces);
- __set_bit(PHY_INTERFACE_MODE_XAUI,
- port->phylink_config.supported_interfaces);
- } else if (phy_mode == PHY_INTERFACE_MODE_5GBASER) {
- __set_bit(PHY_INTERFACE_MODE_5GBASER,
- port->phylink_config.supported_interfaces);
- } else if (phy_mode == PHY_INTERFACE_MODE_10GBASER) {
- __set_bit(PHY_INTERFACE_MODE_10GBASER,
- port->phylink_config.supported_interfaces);
- } else if (phy_mode == PHY_INTERFACE_MODE_XAUI) {
- __set_bit(PHY_INTERFACE_MODE_XAUI,
- port->phylink_config.supported_interfaces);
- }
+ if (!mvpp2_port_supports_xlg(port))
+ port->phylink_config.num_possible_pcs = 1;
+ else
+ port->phylink_config.num_possible_pcs = 2;
+
+ port->phylink_config.fill_available_pcs = mvpp2_port_fill_pcs;
+ mvpp2_port_init_pcs_xlg(&port->pcs_xlg, comphy, phy_mode);
+ mvpp2_port_init_pcs_gmac(&port->pcs_gmac, comphy, phy_mode);
+
+ if (mvpp2_port_supports_xlg(port)) {
if (comphy)
port->phylink_config.mac_capabilities |=
MAC_10000FD | MAC_5000FD;
@@ -7115,35 +7163,16 @@ static int mvpp2_port_probe(struct platform_device *pdev,
MAC_10000FD;
}
- if (mvpp2_port_supports_rgmii(port)) {
- phy_interface_set_rgmii(port->phylink_config.supported_interfaces);
- __set_bit(PHY_INTERFACE_MODE_MII,
- port->phylink_config.supported_interfaces);
- }
+ phy_interface_copy(port->phylink_config.pcs_interfaces,
+ port->pcs_gmac.supported_interfaces);
- if (comphy) {
- /* If a COMPHY is present, we can support any of the
- * serdes modes and switch between them.
- */
- __set_bit(PHY_INTERFACE_MODE_SGMII,
- port->phylink_config.supported_interfaces);
- __set_bit(PHY_INTERFACE_MODE_1000BASEX,
- port->phylink_config.supported_interfaces);
- __set_bit(PHY_INTERFACE_MODE_2500BASEX,
- port->phylink_config.supported_interfaces);
- } else if (phy_mode == PHY_INTERFACE_MODE_2500BASEX) {
- /* No COMPHY, with only 2500BASE-X mode supported */
- __set_bit(PHY_INTERFACE_MODE_2500BASEX,
- port->phylink_config.supported_interfaces);
- } else if (phy_mode == PHY_INTERFACE_MODE_1000BASEX ||
- phy_mode == PHY_INTERFACE_MODE_SGMII) {
- /* No COMPHY, we can switch between 1000BASE-X and SGMII
- */
- __set_bit(PHY_INTERFACE_MODE_1000BASEX,
- port->phylink_config.supported_interfaces);
- __set_bit(PHY_INTERFACE_MODE_SGMII,
- port->phylink_config.supported_interfaces);
- }
+ if (mvpp2_port_supports_xlg(port))
+ phy_interface_or(port->phylink_config.pcs_interfaces,
+ port->phylink_config.pcs_interfaces,
+ port->pcs_xlg.supported_interfaces);
+
+ phy_interface_copy(port->phylink_config.supported_interfaces,
+ port->phylink_config.pcs_interfaces);
phylink = phylink_create(&port->phylink_config, port_fwnode,
phy_mode, &mvpp2_phylink_ops);
--
2.55.0
^ permalink raw reply related
* Re: [PATCH net-next v9 01/12] net: phylink: keep and use MAC supported_interfaces in phylink struct
From: Maxime Chevallier @ 2026-07-21 11:59 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260717065448.1498335-2-ansuelsmth@gmail.com>
Hi,
On 7/17/26 08:54, Christian Marangi wrote:
> Add in phylink struct a copy of supported_interfaces from phylink_config
> and make use of that instead of relying on phylink_config value.
>
> This in preparation for support of PCS handling internally to phylink
> where a PCS can be removed or added after the phylink is created and we
> need both a reference of the supported_interfaces value from
> phylink_config and an internal value that can be updated with the new
> PCS info.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* Re: [PATCH net-next v9 02/12] net: phylink: introduce internal phylink PCS handling
From: Maxime Chevallier @ 2026-07-21 11:59 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260717065448.1498335-3-ansuelsmth@gmail.com>
Hi,
On 7/17/26 08:54, Christian Marangi wrote:
> Introduce internal handling of PCS for phylink. This is an alternative
> way to .mac_select_pcs that moves the selection logic of the PCS entirely
> to phylink with the usage of the supported_interface value in the PCS
> struct.
>
> MAC should now provide a callback to fill the available PCS in
> phylink_config in .fill_available_pcs and fill the .num_possible_pcs with
> the number of elements in the array. MAC should also define a new bitmap,
> pcs_interfaces, in phylink_config to define for what interface mode a
> dedicated PCS is required.
>
> On phylink_create(), an array of PCS pointer is allocated of size
> .num_possible_pcs from phylink_config and .fill_available_pcs from
> phylink_config is called passing as args the just allocated array and
> the number of possible element in it.
>
> MAC will fill this passed array with all the available PCS.
>
> This array is then parsed and a linked list of PCS is created based on
> the allocated PCS array filled by MAC via .fill_available_pcs().
>
> Every PCS in phylink PCS list gets then linked to the phylink instance
> by setting the phylink value in phylink_pcs struct to the phylink instance.
> Also the supported_interface value in phylink struct is updated with
> the new supported_interface from the provided PCS.
>
> On phylink_destroy(), every PCS in phylink PCS list is unlinked from the
> phylink instance by setting the phylink value in phylink_pcs struct to NULL
> and removed from the PCS list.
>
> phylink_validate_mac_and_pcs(), phylink_major_config() and
> phylink_inband_caps() are updated to support this new implementation
> with the PCS list stored in phylink.
>
> They will make use of phylink_validate_pcs_interface() that will loop
> for every PCS in the phylink PCS available list and find one that supports
> the passed interface.
>
> phylink_validate_pcs_interface() applies the same logic of .mac_select_pcs
> where if a supported_interface value is not set for the PCS struct, then
> it's assumed every interface is supported.
>
> A MAC is required to implement either a .mac_select_pcs or make use of
> the PCS list implementation. Implementing both will result in a fail
> on phylink_create().
>
> A MAC defining .num_possible_pcs in phylink_config MUST also define a
> .fill_available_pcs or phylink_create() will fail with an negative error.
>
> phylink value in phylink_pcs struct with this implementation is used to
> track from PCS side when it's attached to a phylink instance. PCS driver
> will make use of this information to correctly detach from a phylink
> instance if needed.
>
> phylink_pcs_change() is also changed to verify that the PCS that triggered
> a link change is the one that is currently used by the phylink instance.
>
> The .mac_select_pcs implementation is not changed but it's expected that
> every MAC driver migrates to the new implementation to later deprecate
> and remove .mac_select_pcs.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* Re: [PATCH net-next v9 03/12] net: phylink: add phylink_release_pcs() to externally release a PCS
From: Maxime Chevallier @ 2026-07-21 12:01 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260717065448.1498335-4-ansuelsmth@gmail.com>
Hi,
On 7/17/26 08:54, Christian Marangi wrote:
> Add phylink_release_pcs() to externally release a PCS from a phylink
> instance. This can be used to handle case when a single PCS needs to be
> removed and the phylink instance needs to be refreshed.
>
> On calling phylink_release_pcs(), the PCS will be removed from the
> phylink internal PCS list and the phylink supported_interfaces value is
> reparsed with the remaining PCS interfaces.
>
> Also a phylink resolve is triggered to handle the PCS removal.
>
> The flag force_major_config is set to make phylink resolve reconfigure
> the interface (even if it didn't change).
> This is needed to handle the special case when the current PCS used
> by phylink is removed and a major_config is needed to propagae the
> configuration change. With this option enabled we also force mac_config
> even if the PHY link is not up for the in-band case.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: net: qcom,bam-dmux: Add qcom,shikra-bam-dmux compatible
From: Stephan Gerhold @ 2026-07-21 12:05 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Vishnu Santhosh, Stephan Gerhold, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Loic Poulain, Sergey Ryazanov,
Johannes Berg, linux-arm-msm, netdev, devicetree, linux-kernel,
chris.lew, Deepak Kumar Singh
In-Reply-To: <4fc9743d-3d9e-4130-9ffb-b64318a8373a@oss.qualcomm.com>
On Tue, Jul 21, 2026 at 01:57:16PM +0200, Konrad Dybcio wrote:
> On 7/14/26 4:03 PM, Vishnu Santhosh wrote:
> >
> > On 14-07-2026 12:41 pm, Stephan Gerhold wrote:
> >> On Tue, Jul 14, 2026 at 11:02:31AM +0530, Vishnu Santhosh wrote:
> >>> On platforms where the modem DMAs into the BAM-DMUX RX data buffers and
> >>> the XPU enforces per-region access control, each individually
> >>> DMA-mapped RX buffer consumes an XPU resource group. With only ~16
> >>> groups available, the per-buffer mappings exhaust the table and inbound
> >>> transfers fault.
> >>>
> >>> Add qcom,shikra-bam-dmux as an additional compatible for the Shikra SoC,
> >>> paired with the generic qcom,bam-dmux fallback, so the driver can match
> >>> on it via its of_device_id table.
> >>>
> >>> Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
> >>> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
> >>> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
> >> IMHO (the DT maintainers might disagree) this is not a different
> >> BAM DMUX hardware block on Shikra, just a different firmware
> >> configuration. I'm sure the existing SoCs also have those XPU blocks,
> >> they just don't make use of it.
> >>
> >> Personally, I would rather describe this with an optional "qcom,vmid"
> >> property similar to your bam-dma patch, allowed for all SoCs.
> >>
> >> Thanks,
> >> Stephan
> >
> > Thanks Stephan. Adding Konrad (Cc), since this compatible-string /
> > match-data approach was his suggestion on an earlier revision of this
> > series send for internal review, specifically because BAM-DMUX is a
> > singleton per SoC.
> >
> > Konrad, given Stephan's point, would you still prefer the
> > compatible-string / match-data approach, or does the optional
> > qcom,vmid property (matching the bam-dma series) make more sense here?
> >
> > Happy to go either way once you've both aligned.
>
> This all depends on whether the DT maintainers grant you the right to
> introduce a new property and in this case I very much doubt that
>
We have the qcom,vmid(s) property in multiple other bindings (rmtfs,
fastrpc, ...), so I don't see an issue with that, personally...
IMHO I don't think a new compatible is warranted, because the BAM DMUX
protocol still works exactly the same (at least as described so far).
It's just the firmware security configuration around it that enforces
additional constraints. You could have this on any other SoC as well if
you configure the xPU stuff like that. It's not really specific to
Shikra.
Thanks,
Stephan
^ permalink raw reply
* [for-next v4 0/2] Add Reorder Completion Queue (RCQ) support
From: Abhijit Gangurde @ 2026-07-21 12:10 UTC (permalink / raw)
To: jgg, leon, brett.creeley, andrew+netdev, davem, edumazet, kuba,
pabeni
Cc: allen.hubbe, nikhil.agarwal, linux-rdma, netdev, linux-kernel,
Abhijit Gangurde
This series adds userspace support for the Reorder Completion Queue (RCQ)
feature in the ionic RDMA driver.
Patch 1 extends the net/ionic firmware identity structure to expose the
rcq_sign_bit field from the RDMA LIF identity.
Patch 2 plumbs the RCQ sign bit through the RDMA driver's LIF configuration,
exposes it to userspace via the ucontext response, and allows userspace to
specify ionic specific QP flags during QP creation. This enables rdma-core to
discover RCQ capability at context allocation time and configure QPs with
RCQ support.
PR: https://github.com/linux-rdma/rdma-core/pull/1733
v4:
- Dropped robust udata from this series and sent as a seperate patch
https://lore.kernel.org/linux-rdma/20260717092345.2533564-1-abhijit.gangurde@amd.com/
- Addressed sashiko review comments
v3:
- Added robust udata compatibility checks
- https://lore.kernel.org/linux-rdma/20260617132605.1888205-1-abhijit.gangurde@amd.com/
v2:
- Dropped QP transport mode selection
- https://lore.kernel.org/linux-rdma/20260611092544.783731-1-abhijit.gangurde@amd.com/
v1:
- https://lore.kernel.org/linux-rdma/20260430123931.3256130-1-abhijit.gangurde@amd.com/
Abhijit Gangurde (2):
net: ionic: Fetch RCQ sign bit from firmware
RDMA/ionic: Add RCQ userspace support
.../infiniband/hw/ionic/ionic_controlpath.c | 19 ++++++++++++++++---
drivers/infiniband/hw/ionic/ionic_fw.h | 2 ++
drivers/infiniband/hw/ionic/ionic_lif_cfg.c | 1 +
drivers/infiniband/hw/ionic/ionic_lif_cfg.h | 1 +
.../net/ethernet/pensando/ionic/ionic_if.h | 6 +++++-
include/uapi/rdma/ionic-abi.h | 5 ++++-
6 files changed, 29 insertions(+), 5 deletions(-)
--
2.43.0
^ permalink raw reply
* [for-next v4 1/2] net: ionic: Fetch RCQ sign bit from firmware
From: Abhijit Gangurde @ 2026-07-21 12:10 UTC (permalink / raw)
To: jgg, leon, brett.creeley, andrew+netdev, davem, edumazet, kuba,
pabeni
Cc: allen.hubbe, nikhil.agarwal, linux-rdma, netdev, linux-kernel,
Abhijit Gangurde
In-Reply-To: <20260721121034.1616562-1-abhijit.gangurde@amd.com>
Read the rcq_sign_bit from the RDMA LIF identity reported by firmware.
Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com>
---
drivers/net/ethernet/pensando/ionic/ionic_if.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/pensando/ionic/ionic_if.h b/drivers/net/ethernet/pensando/ionic/ionic_if.h
index 23d6e2b4791e..b97de96f78c4 100644
--- a/drivers/net/ethernet/pensando/ionic/ionic_if.h
+++ b/drivers/net/ethernet/pensando/ionic/ionic_if.h
@@ -553,6 +553,8 @@ enum ionic_lif_rdma_cap_stats {
* @rdma.eq_qtype: RDMA Event Qtype
* @rdma.stats_type: Supported statistics type
* (enum ionic_lif_rdma_cap_stats)
+ * @rdma.rsvd: Reserved byte
+ * @rdma.rcq_sign_bit: RCQ sign bit
* @rdma.rsvd1: Reserved byte(s)
* @words: word access to struct contents
*/
@@ -598,7 +600,9 @@ union ionic_lif_identity {
struct ionic_lif_logical_qtype cq_qtype;
struct ionic_lif_logical_qtype eq_qtype;
__le16 stats_type;
- u8 rsvd1[162];
+ u8 rsvd;
+ u8 rcq_sign_bit;
+ u8 rsvd1[160];
} __packed rdma;
} __packed;
__le32 words[478];
--
2.43.0
^ permalink raw reply related
* [for-next v4 2/2] RDMA/ionic: Add RCQ userspace support
From: Abhijit Gangurde @ 2026-07-21 12:10 UTC (permalink / raw)
To: jgg, leon, brett.creeley, andrew+netdev, davem, edumazet, kuba,
pabeni
Cc: allen.hubbe, nikhil.agarwal, linux-rdma, netdev, linux-kernel,
Abhijit Gangurde
In-Reply-To: <20260721121034.1616562-1-abhijit.gangurde@amd.com>
Expose the Reorder Completion Queue (RCQ) capability to userspace via
ucontext response and allow userspace to specify ionic specific QP
flags during QP creation.
Co-developed-by: Allen Hubbe <allen.hubbe@amd.com>
Signed-off-by: Allen Hubbe <allen.hubbe@amd.com>
Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com>
---
.../infiniband/hw/ionic/ionic_controlpath.c | 19 ++++++++++++++++---
drivers/infiniband/hw/ionic/ionic_fw.h | 2 ++
drivers/infiniband/hw/ionic/ionic_lif_cfg.c | 1 +
drivers/infiniband/hw/ionic/ionic_lif_cfg.h | 1 +
include/uapi/rdma/ionic-abi.h | 5 ++++-
5 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/ionic/ionic_controlpath.c b/drivers/infiniband/hw/ionic/ionic_controlpath.c
index 9d91f7667d4f..d28f26c58927 100644
--- a/drivers/infiniband/hw/ionic/ionic_controlpath.c
+++ b/drivers/infiniband/hw/ionic/ionic_controlpath.c
@@ -408,6 +408,7 @@ int ionic_alloc_ucontext(struct ib_ucontext *ibctx, struct ib_udata *udata)
resp.udma_count = dev->lif_cfg.udma_count;
resp.expdb_mask = dev->lif_cfg.expdb_mask;
+ resp.rcq_sign_bit = dev->lif_cfg.rcq_sign_bit;
if (dev->lif_cfg.sq_expdb)
resp.expdb_qtypes |= IONIC_EXPDB_SQ;
@@ -1324,7 +1325,8 @@ static int ionic_create_qp_cmd(struct ionic_ibdev *dev,
struct ionic_qp *qp,
struct ionic_tbl_buf *sq_buf,
struct ionic_tbl_buf *rq_buf,
- struct ib_qp_init_attr *attr)
+ struct ib_qp_init_attr *attr,
+ u32 ionic_flags)
{
const u16 dbid = ionic_obj_dbid(dev, pd->ibpd.uobject);
const u32 flags = to_ionic_qp_flags(0, 0,
@@ -1340,7 +1342,12 @@ static int ionic_create_qp_cmd(struct ionic_ibdev *dev,
.len = cpu_to_le16(IONIC_ADMIN_CREATE_QP_IN_V1_LEN),
.cmd.create_qp = {
.pd_id = cpu_to_le32(pd->pdid),
- .priv_flags = cpu_to_be32(flags),
+ /* User-supplied ionic_flags are passed through to
+ * firmware, which validates and rejects any
+ * unsupported or unauthorized bits.
+ */
+ .priv_flags = cpu_to_be32(flags |
+ (ionic_flags & IONIC_QP_USER_FLAGS_MASK)),
.type_state = to_ionic_qp_type(attr->qp_type),
.dbid_flags = cpu_to_le16(dbid),
.id_ver = cpu_to_le32(qp->qpid),
@@ -2157,6 +2164,12 @@ int ionic_create_qp(struct ib_qp *ibqp, struct ib_qp_init_attr *attr,
rc = ib_copy_validate_udata_in(udata, req, rsvd);
if (rc)
return rc;
+
+ if (req.ionic_flags & ~IONIC_QP_USER_FLAGS_MASK)
+ return -EINVAL;
+
+ if (req.rsvd_pad)
+ return -EINVAL;
} else {
req.sq_spec = IONIC_SPEC_HIGH;
req.rq_spec = IONIC_SPEC_HIGH;
@@ -2237,7 +2250,7 @@ int ionic_create_qp(struct ib_qp *ibqp, struct ib_qp_init_attr *attr,
rc = ionic_create_qp_cmd(dev, pd,
to_ionic_vcq_cq(attr->send_cq, qp->udma_idx),
to_ionic_vcq_cq(attr->recv_cq, qp->udma_idx),
- qp, &sq_buf, &rq_buf, attr);
+ qp, &sq_buf, &rq_buf, attr, req.ionic_flags);
if (rc)
goto err_cmd;
diff --git a/drivers/infiniband/hw/ionic/ionic_fw.h b/drivers/infiniband/hw/ionic/ionic_fw.h
index adfbb89d856c..4c6752bfb1de 100644
--- a/drivers/infiniband/hw/ionic/ionic_fw.h
+++ b/drivers/infiniband/hw/ionic/ionic_fw.h
@@ -105,6 +105,8 @@ enum ionic_qp_flags {
IONIC_QPF_SQ_CMB = BIT(13),
IONIC_QPF_RQ_CMB = BIT(14),
IONIC_QPF_PRIVILEGED = BIT(15),
+
+ IONIC_QP_USER_FLAGS_MASK = GENMASK(31, 16),
};
static inline int from_ionic_qp_flags(int flags)
diff --git a/drivers/infiniband/hw/ionic/ionic_lif_cfg.c b/drivers/infiniband/hw/ionic/ionic_lif_cfg.c
index f3cd281c3a2f..a9044f47c913 100644
--- a/drivers/infiniband/hw/ionic/ionic_lif_cfg.c
+++ b/drivers/infiniband/hw/ionic/ionic_lif_cfg.c
@@ -84,6 +84,7 @@ void ionic_fill_lif_cfg(struct ionic_lif *lif, struct ionic_lif_cfg *cfg)
cfg->udma_count = 2;
cfg->max_stride = ident->rdma.max_stride;
+ cfg->rcq_sign_bit = ident->rdma.rcq_sign_bit;
cfg->expdb_mask = ionic_get_expdb(lif);
cfg->sq_expdb =
diff --git a/drivers/infiniband/hw/ionic/ionic_lif_cfg.h b/drivers/infiniband/hw/ionic/ionic_lif_cfg.h
index 20853429f623..e6b17055147f 100644
--- a/drivers/infiniband/hw/ionic/ionic_lif_cfg.h
+++ b/drivers/infiniband/hw/ionic/ionic_lif_cfg.h
@@ -56,6 +56,7 @@ struct ionic_lif_cfg {
bool sq_expdb;
bool rq_expdb;
u8 expdb_mask;
+ u8 rcq_sign_bit;
};
void ionic_fill_lif_cfg(struct ionic_lif *lif, struct ionic_lif_cfg *cfg);
diff --git a/include/uapi/rdma/ionic-abi.h b/include/uapi/rdma/ionic-abi.h
index 7b589d3e9728..b1ec59efb49c 100644
--- a/include/uapi/rdma/ionic-abi.h
+++ b/include/uapi/rdma/ionic-abi.h
@@ -46,8 +46,9 @@ struct ionic_ctx_resp {
__u8 udma_count;
__u8 expdb_mask;
__u8 expdb_qtypes;
+ __u8 rcq_sign_bit;
- __u8 rsvd2[3];
+ __u8 rsvd2[2];
};
struct ionic_qdesc {
@@ -84,6 +85,8 @@ struct ionic_qp_req {
__u8 rq_cmb;
__u8 udma_mask;
__u8 rsvd[3];
+ __u32 ionic_flags;
+ __u32 rsvd_pad;
};
struct ionic_qp_resp {
--
2.43.0
^ permalink raw reply related
* RE: [PATCH net 1/1] tipc: avoid use-after-free in trace queue dumps
From: Tung Quang Nguyen @ 2026-07-21 12:11 UTC (permalink / raw)
To: Ren Wei
Cc: jmaloy@redhat.com, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, horms@kernel.org, ying.xue@windriver.com,
vega@nebusec.ai, xizh2024@lzu.edu.cn, netdev@vger.kernel.org,
tipc-discussion@lists.sourceforge.net
In-Reply-To: <b261f5acabf7c07c971e024d0d78aa9ea34f2be6.1784443039.git.xizh2024@lzu.edu.cn>
>Subject: [PATCH net 1/1] tipc: avoid use-after-free in trace queue dumps
>
>From: Zihan Xi <xizh2024@lzu.edu.cn>
>
>TIPC trace helpers can dump live socket queues from contexts such as poll().
>tipc_list_dump() walks the write and receive skb queues and dumps the head,
>tail or selected skb entries, while tipc_sk_dump() also dumps the socket
>backlog head and tail directly.
>
>Those trace paths do not have a reliable skb lifetime guarantee for every queue
>they inspect. TIPC socket queues are serialized by socket or other outer locks,
>and not all skb lists use the embedded sk_buff_head lock as the mutator lock.
>A concurrent dequeue/free can therefore leave the trace helper dereferencing
>a stale skb pointer.
>
>Avoid dereferencing queue members from the socket trace dump path. Keep
>the trace ABI and buffer sizing unchanged, but report only queue lengths for
>the write queue, receive queue, and backlog. This preserves useful queue state
>in trace output without pretending that the trace helper can safely pin or walk
>all caller-provided lists.
>
>Fixes: b4b9771bcbbd ("tipc: enable tracepoints in tipc")
>Cc: stable@vger.kernel.org
>Reported-by: Vega <vega@nebusec.ai>
>Assisted-by: Codex:gpt-5.4
>Signed-off-by: Zihan Xi <xizh2024@lzu.edu.cn>
>Reviewed-by: Ren Wei <enjou1224z@gmail.com>
>---
> net/tipc/socket.c | 12 +++---------
> net/tipc/trace.c | 44 +++++---------------------------------------
> 2 files changed, 8 insertions(+), 48 deletions(-)
>
>diff --git a/net/tipc/socket.c b/net/tipc/socket.c index
>e564341e0216..4b9eb0b401fe 100644
>--- a/net/tipc/socket.c
>+++ b/net/tipc/socket.c
>@@ -4000,15 +4000,9 @@ int tipc_sk_dump(struct sock *sk, u16 dqueues,
>char *buf)
> i += tipc_list_dump(&sk->sk_receive_queue, false, buf + i);
> }
>
>- if (dqueues & TIPC_DUMP_SK_BKLGQ) {
>- i += scnprintf(buf + i, sz - i, "sk_backlog:\n head ");
>- i += tipc_skb_dump(sk->sk_backlog.head, false, buf + i);
>- if (sk->sk_backlog.tail != sk->sk_backlog.head) {
>- i += scnprintf(buf + i, sz - i, " tail ");
>- i += tipc_skb_dump(sk->sk_backlog.tail, false,
>- buf + i);
>- }
>- }
>+ if (dqueues & TIPC_DUMP_SK_BKLGQ)
>+ i += scnprintf(buf + i, sz - i, "sk_backlog: len = %d\n",
>+ READ_ONCE(sk->sk_backlog.len));
>
> return i;
> }
>diff --git a/net/tipc/trace.c b/net/tipc/trace.c index
>7d2931521e0e..399538d0a369 100644
>--- a/net/tipc/trace.c
>+++ b/net/tipc/trace.c
>@@ -158,49 +158,15 @@ int tipc_skb_dump(struct sk_buff *skb, bool more,
>char *buf)
> /**
> * tipc_list_dump - dump TIPC skb list/queue
> * @list: list of skbs to be dumped
>- * @more: dump more?
>- * - false: dump only the head & tail skbs
>- * - true: dump the first & last 5 skbs
>+ * @more: unused; kept for tracepoint ABI compatibility
> * @buf: returned buffer of dump data in format
> */
> int tipc_list_dump(struct sk_buff_head *list, bool more, char *buf) {
>- int i = 0;
>- size_t sz = (more) ? LIST_LMAX : LIST_LMIN;
>- u32 count, len;
>- struct sk_buff *hskb, *tskb, *skb, *tmp;
>-
>- if (!list) {
>- i += scnprintf(buf, sz, "(null)\n");
>- return i;
>- }
>+ size_t sz = more ? LIST_LMAX : LIST_LMIN;
>
>- len = skb_queue_len(list);
>- i += scnprintf(buf, sz, "len = %d\n", len);
>+ if (!list)
>+ return scnprintf(buf, sz, "(null)\n");
>
>- if (!len)
>- return i;
>-
>- if (!more) {
>- hskb = skb_peek(list);
>- i += scnprintf(buf + i, sz - i, " head ");
>- i += tipc_skb_dump(hskb, false, buf + i);
>- if (len > 1) {
>- tskb = skb_peek_tail(list);
>- i += scnprintf(buf + i, sz - i, " tail ");
>- i += tipc_skb_dump(tskb, false, buf + i);
>- }
>- } else {
>- count = 0;
>- skb_queue_walk_safe(list, skb, tmp) {
>- count++;
>- if (count == 6)
>- i += scnprintf(buf + i, sz - i, " .\n .\n");
>- if (count > 5 && count <= len - 5)
>- continue;
>- i += scnprintf(buf + i, sz - i, " #%d ", count);
>- i += tipc_skb_dump(skb, false, buf + i);
>- }
>- }
>- return i;
>+ return scnprintf(buf, sz, "len = %u\n", skb_queue_len_lockless(list));
This patch is wrong because it removes information that we need for tracing.
Could you please test below patch to see if it fixes the issue you reported ?
---
net/tipc/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index e564341e0216..a006fc98a9b8 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -795,7 +795,7 @@ static __poll_t tipc_poll(struct file *file, struct socket *sock,
__poll_t revents = 0;
sock_poll_wait(file, sock, wait);
- trace_tipc_sk_poll(sk, NULL, TIPC_DUMP_ALL, " ");
+ trace_tipc_sk_poll(sk, NULL, TIPC_DUMP_NONE, " ");
if (sk->sk_shutdown & RCV_SHUTDOWN)
revents |= EPOLLRDHUP | EPOLLIN | EPOLLRDNORM;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next v9 06/12] net: Document PCS subsystem
From: Maxime Chevallier @ 2026-07-21 12:11 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260717065448.1498335-7-ansuelsmth@gmail.com>
On 7/17/26 08:54, Christian Marangi wrote:
> Add extensive documentation of the new PCS subsystem and the fwnode
> implementation with producer/consumer API.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> Documentation/networking/index.rst | 1 +
> Documentation/networking/pcs.rst | 229 +++++++++++++++++++++++++++++
> 2 files changed, 230 insertions(+)
> create mode 100644 Documentation/networking/pcs.rst
>
> diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
> index 44a422ad3b05..3fce8f6ac089 100644
> --- a/Documentation/networking/index.rst
> +++ b/Documentation/networking/index.rst
> @@ -28,6 +28,7 @@ Contents:
> net_failover
> page_pool
> phy
> + pcs
> sfp-phylink
> alias
> bridge
> diff --git a/Documentation/networking/pcs.rst b/Documentation/networking/pcs.rst
> new file mode 100644
> index 000000000000..98592cdee3ef
> --- /dev/null
> +++ b/Documentation/networking/pcs.rst
> @@ -0,0 +1,229 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +=============
> +PCS Subsystem
> +=============
> +
> +The PCS (Physical Coding Sublayer) subsystem handles the registration and lookup
> +of PCS devices. These devices contain the upper sublayers of the Ethernet
> +physical layer, generally handling framing, scrambling, and encoding tasks. PCS
> +devices may also include PMA (Physical Medium Attachment) components. PCS
> +devices transfer data between the Link-layer MAC device, and the rest of the
> +physical layer, typically via a serdes. The output of the serdes may be
> +connected more-or-less directly to the medium when using fiber-optic or
> +backplane connections (1000BASE-SX, 1000BASE-KX, etc). It may also communicate
> +with a separate PHY (such as over SGMII) which handles the connection to the
> +medium (such as 1000BASE-T).
> +
> +Remark on usage of .mac_select_pcs and fw_node PCS
> +--------------------------------------------------
> +
> +There are generally two ways to look up a PCS device.
> +
> +1. MAC OP struct .mac_select_pcs (considered legacy)
> +2. firmware node (fwnode) PCS entirely handled by phylink
> +
> +Implementation 1 leaves the entire handling of the PCS to the MAC
> +driver with the selection of the PCS driven by .mac_select_pcs.
> +Custom implementations are required if the PCS is external to the MAC
> +and needs to be handled by a separate driver.
> +
> +This implementation is considered legacy and it's suggested to
> +switch to the new fwnode PCS.
The .mac_select_pcs can be deprecated, with the .fill_available_pcs()
mecanism available, we can keep PCS implems inside the MAC driver when
it makes sense, no ?
If PCSs aren't described in firmware (i.e. DT), we have to use .fill_available_pcs()
without using the fwnode API if I get your code right.
The 'legacy' part is the only remark I have, the rest is all good :)
Maxime
> +
> +Looking up PCS Devices (fwnode implementation)
> +-----------------------------------------------
> +
> +The lookup of a PCS device follows the common producer/consumer implementation
> +used by similar subsystems with a ``#pcs-cells`` on the producer and a
> +``pcs-handle`` property on the consumer::
> +
> + pcs: pcs {
> + // ...
> + #pcs-cells = <0>;
> + };
> +
> + ethernet-controller {
> + // ...
> + pcs-handle = <&pcs>;
> + };
> +
> +On :c:func:`phylink_create`, phylink will use the ``num_possible_pcs``
> +value and ``fill_available_pcs`` helper function in
> +:c:struct:`phylink_config` to compose the list of available PCS that can be
> +used for the phylink instance.
> +
> +Phylink will then internally handle the selection of the correct PCS for
> +the requested interface mode based on the interface modes configured in
> +``pcs_interfaces`` in :c:struct:`phylink_config` struct and
> +``supported_interfaces`` in :c:struct:`phylink_pcs` struct.
> +
> +A PCS is considered eligible when the requested interface mode is present
> +in both ``pcs_interfaces`` in :c:struct:`phylink_config` struct and
> +``supported_interfaces`` in :c:struct:`phylink_pcs` struct.
> +
> +``supported_interfaces`` describes all interface modes supported by the MAC,
> +whereas ``pcs_interfaces`` identifies the subset that require PCS selection.
> +
> +For the special implementation where the PCS is internal or part of the MAC
> +and a dedicated driver is not needed, it's possible to leave the implementation
> +of the PCS to the MAC driver and just implement the ``num_possible_pcs``
> +value and ``fill_available_pcs`` helper function in
> +:c:struct:`phylink_config` referencing the local :c:struct:`phylink_pcs`
> +struct allocated from the MAC driver.
> +
> +Using PCS Devices
> +-----------------
> +
> +It's mandatory to either implement the ``mac_select_pcs`` callback
> +of :c:struct:`phylink_mac_ops` or ``num_possible_pcs`` and ``fill_available_pcs``
> +of :c:struct:`phylink_config` to use a PCS for a MAC.
> +
> +The fwnode implementation exposes simple helpers to parse the PCS from
> +the fwnode :c:func:`fwnode_phylink_pcs_count` and
> +:c:func:`fwnode_phylink_pcs_parse`. The :c:func:`fwnode_phylink_pcs_count` helper
> +takes the fwnode where the ``pcs-handle`` should be parsed and return the
> +number of PCS entries described in the fwnode.
> +The :c:func:`fwnode_phylink_pcs_parse` helper takes three arguments,
> +the fwnode where the ``pcs-handle`` should be parsed, an allocated array
> +of :c:struct:`phylink_pcs` pointer where to put the parsed PCS from the fwnode
> +and the maximum number of PCS to parse.
> +Contrary to :c:func:`fwnode_phylink_pcs_count`, :c:func:`fwnode_phylink_pcs_parse`
> +helper fills the allocated array with ONLY the available PCS and return the
> +number of available PCS found. PCS that returns -ENODEV will be skipped and
> +won't be inserted in the allocated array.
> +
> +A phylink instance may use multiple PCS devices. The maximum number is reported
> +through ``num_possible_pcs``.
> +
> +It's mandatory to specify for what interface a PCS is needed. This can be done
> +by filling the ``pcs_interfaces`` in :c:struct:`phylink_config` struct.
> +If the requested interface mode is not present in this bitmask, phylink does
> +not search for a PCS for that specific mode. (example MAC doesn't need a PCS
> +for SGMII but require one for USXGMII)
> +
> +With the use of the :c:func:`fwnode_phylink_pcs_parse` a common implementation
> +is the following::
> +
> + static int mac_fill_available_pcs(struct phylink_config *config,
> + struct phylink_pcs **available_pcs,
> + unsigned int num_possible_pcs)
> + {
> + struct device *dev = config->dev;
> +
> + return fwnode_phylink_pcs_parse(dev_fwnode(dev), available_pcs,
> + num_possible_pcs);
> + }
> +
> + static int mac_setup_phylink(struct net_device *netdev)
> + {
> + struct phylink_config *config;
> +
> + // ...
> +
> + config->dev = &netdev->dev;
> +
> + // ...
> +
> + // Parse possible PCS and fill num_possible_pcs.
> + config->num_possible_pcs = fwnode_phylink_pcs_count(dev_fwnode(&netdev->dev));
> + config->fill_available_pcs = mac_fill_available_pcs;
> +
> + __set_bit(PHY_INTERFACE_MODE_INTERNAL, config->supported_interfaces);
> + __set_bit(PHY_INTERFACE_MODE_SGMII, config->supported_interfaces);
> + __set_bit(PHY_INTERFACE_MODE_1000BASEX, config->supported_interfaces);
> + __set_bit(PHY_INTERFACE_MODE_USXGMII, config->supported_interfaces);
> +
> + // PCS required only for USXGMII
> + __set_bit(PHY_INTERFACE_MODE_USXGMII, config->pcs_interfaces);
> +
> + phylink = phylink_create(config, //...
> +
> +It's worth to mention that it's phylink code that takes care of allocating
> +the array of :c:struct:`phylink_pcs` pointer for ``fill_available_pcs``
> +callback based on the value set in ``num_possible_pcs`` for
> +:c:struct:`phylink_config` struct.
> +
> +The ``fill_available_pcs`` callback must not write more than
> +``num_possible_pcs`` entries. The third argument may be used to validate
> +that there is enough space to fill all the available PCS in the passed array
> +of :c:struct:`phylink_pcs` pointer.
> +
> +The ``fill_available_pcs`` callback is called only on :c:func:`phylink_create`
> +and is used only to compose the initial available PCS list. Ownership of PCS
> +is held by phylink and :c:func:`phylink_release_pcs` should be used to release
> +them.
> +
> +Writing PCS Drivers
> +-------------------
> +
> +To write a PCS driver, first implement :c:struct:`phylink_pcs_ops`. Then,
> +register your PCS in your probe function using :c:func:`fwnode_pcs_add_provider`.
> +The :c:func:`fwnode_pcs_add_provider` takes three arguments, the fwnode where
> +the PCS provider should be registered to, a get function to return the requested
> +PCS based on ``#pcs-cells`` and a pointer to reference private data for the get
> +function.
> +
> +The PCS will then be registered to a global list of PCS provider that the
> +PCS fwnode implementation will use to parse it.
> +
> +For the simple case where the PCS driver expose a single PCS,
> +:c:func:`fwnode_pcs_simple_get` can be used as the get function.
> +
> +You must call :c:func:`fwnode_pcs_del_provider` from your remove function and
> +release the PCS from any phylink instance under RTNL lock with
> +:c:func:`phylink_release_pcs`::
> +
> + fwnode_pcs_del_provider(dev_fwnode(&pdev->dev));
> +
> + rtnl_lock();
> +
> + for (i = 0; i < data->num_port; i++) {
> + struct pcs_port *port = &priv->ports[i];
> +
> + phylink_release_pcs(&port->pcs);
> + }
> +
> + rtnl_unlock();
> +
> +Late PCS registration handling
> +------------------------------
> +
> +It's possible that a PCS becomes available after the MAC finished probing.
> +Contrary to the usual producer/consumer implementation, when a PCS is not
> +registered and can't be found, the fwnode parser helper returns ``-ENODEV``
> +instead of ``-EPROBE_DEFER``.
> +
> +This is to prevent race condition with particular devices that register
> +MAC and PCS with USB or PCIe and require the MAC to be registered before
> +the PCS.
> +
> +The phylink logic correctly handle this special case and keep the phylink
> +instance in a fail condition.
> +
> +The PCS fwnode implementation provides a notifier to which each phylink
> +instance with a non-empty ``pcs_interfaces`` in :c:type:`phylink_config`
> +registers. When a new PCS provider is registered, the notifier is called
> +triggering the :c:func:`pcs_provider_notify` function.
> +
> +Function :c:func:`pcs_provider_notify` will check if the just added PCS
> +should be used by the phylink instance. If it should be used then,
> +it's added to the internal list of available PCS and a phylink major
> +config is forced.
> +
> +If a phylink instance was in a failure state, with the just added PCS
> +now part of the available PCS internal phylink list, provided all other
> +conditions are satisfied, the configuration is retried and the failure
> +condition is cleared.
> +
> +API Reference
> +-------------
> +
> +.. kernel-doc:: include/linux/phylink.h
> + :identifiers: phylink_pcs
> +
> +.. kernel-doc:: include/linux/pcs/pcs.h
> + :internal:
> +
> +.. kernel-doc:: include/linux/pcs/pcs-provider.h
> + :internal:
^ permalink raw reply
* Re: [PATCH net-next v9 09/12] net: phylink: add .pcs_link_down PCS OP
From: Maxime Chevallier @ 2026-07-21 12:13 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260717065448.1498335-10-ansuelsmth@gmail.com>
Hi,
On 7/17/26 08:54, Christian Marangi wrote:
> Permit for PCS driver to define specific operation to tear down the link
> between the MAC and the PCS.
>
> This might be needed for some PCS that reset counter or require special
> reset to correctly work if the link needs to be restored later.
>
> On phylink_link_down() call, the additional phylink_pcs_link_down() will
> be called after .mac_link_down to tear down the link.
>
> PCS driver will need to define .pcs_link_down to make use of this.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
[...]
>
> +/**
> + * pcs_link_up() - tear down link between MAC and PCS
^^^^^^^^^^^
should be pcs_link_down() :)
With this fixed,
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
^ permalink raw reply
* Re: [PATCH 3/3 net-next] ipv6: add CAP_NET_ADMIN check for forwarding and force_forwarding sysctl
From: Ido Schimmel @ 2026-07-21 12:24 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: netdev, horms, pabeni, kuba, edumazet, davem, dsahern
In-Reply-To: <20260716203713.17392-4-fmancera@suse.de>
On Thu, Jul 16, 2026 at 10:37:13PM +0200, Fernando Fernandez Mancera wrote:
> As commit 8292d7f6e871 ("net: ipv4: add capability check for net
> administration") did for IPv4, make sure that CAP_NET_ADMIN is required
> to modify IPv6 forwarding and force_forwarding sysctl. This keep the
> consistency of permission check logic between both protocols.
What's the value beyond protocol consistency given that it creates
intra-protocol inconsistency (none of the other IPv6 sysctl handlers
have this check)? 8292d7f6e871 does not explain why only forwarding was
changed. As-is, I don't see much value in this change. Tested using
[1].
Before:
uid=0(root) gid=0(root) groups=0(root)
v4 fwd: 1
v4 rp_filter: 0
v6 fwd: 0
v6 accept_ra: 0
After:
uid=0(root) gid=0(root) groups=0(root)
v4 fwd: 1
v4 rp_filter: 0
v6 fwd: 1
v6 accept_ra: 0
[1]
#!/bin/bash
id
capsh --drop=cap_net_admin -- -c '
sysctl -wq net.ipv4.conf.all.forwarding=1 &> /dev/null
echo "v4 fwd: $?"
sysctl -wq net.ipv4.conf.all.rp_filter=2 &> /dev/null
echo "v4 rp_filter: $?"
sysctl -wq net.ipv6.conf.all.forwarding=1 &> /dev/null
echo "v6 fwd: $?"
sysctl -wq net.ipv6.conf.all.accept_ra=2 &> /dev/null
echo "v6 accept_ra: $?"
'
^ permalink raw reply
* Re: [PATCH iwl-next v2 1/2] i40e: move ATR sample rate from ring to PF level
From: Simon Horman @ 2026-07-21 12:44 UTC (permalink / raw)
To: mohammad heib
Cc: intel-wired-lan, netdev, jiri, davem, edumazet, kuba, pabeni,
corbet, anthony.l.nguyen, przemyslaw.kitszel, andrew+netdev
In-Reply-To: <acb60edf-0be5-4719-8f13-00cdbd1bb491@redhat.com>
Hi Mohammad,
Likewise, thanks for your response.
On Mon, Jul 20, 2026 at 02:36:52PM +0300, mohammad heib wrote:
> Hi Simon
> Thank you for the review.
>
> On 7/8/26 5:36 PM, Simon Horman wrote:
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> > Full review at: https://sashiko.dev
> > ---
> > i40e: move ATR sample rate from ring to PF level
> >
> > This commit moves the ATR sample rate configuration from the per-ring level
> > to the PF level. It initializes the sample rate globally during software init
> > and updates the fast path to reference the PF structure.
> >
> > > diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
> > > index a04683004a567..4d4d4b07a0f3a 100644
> > > --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> > > +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> > [ ... ]
> > > @@ -3454,12 +3454,7 @@ static int i40e_configure_tx_ring(struct i40e_ring *ring)
> > > ring->xsk_pool = i40e_xsk_pool(ring);
> > > /* some ATR related tx ring init */
> > > - if (test_bit(I40E_FLAG_FD_ATR_ENA, vsi->back->flags)) {
> > > - ring->atr_sample_rate = I40E_DEFAULT_ATR_SAMPLE_RATE;
> > > - ring->atr_count = 0;
> > > - } else {
> > > - ring->atr_sample_rate = 0;
> > > - }
> > > + ring->atr_count = 0;
> >
> > [Severity: High]
> > Does removing this per-ring initialization remove the protection against
> > dynamic ethtool flag toggles?
> >
> > Previously, if the ring was configured while Flow Director ATR was disabled,
> > the ring's sample rate was cached to 0 in i40e_configure_tx_ring(). This
> > prevented descriptor injection even if the PF flag was later toggled on
> > without a ring reset.
> >
>
> The per-ring zeroing of atr_sample_rate was redundant. i40e_atr() already
> checks I40E_FLAG_FD_ATR_ENA before it ever looks at atr_sample_rate:
>
> /* make sure ATR is enabled */
> if (!test_bit(I40E_FLAG_FD_ATR_ENA, pf->flags))
> return;
>
> if (test_bit(__I40E_FD_ATR_AUTO_DISABLED, pf->state))
> return;
>
> /* if sampling is disabled do nothing */
> if (!pf->atr_sample_rate)
> return;
>
>
> When ATR is disabled via ethtool private flags, the function bails out at
> the I40E_FLAG_FD_ATR_ENA check regardless of what atr_sample_rate is set to.
> The flag check is the real protection the per-ring sample rate cache was
> never the thing providing protection against dynamic toggling.
Thanks for the response and sorry for the false-positive.
I agree we can discard this concern.
> > [ ... ]
> > > diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> > > index 894f2d06d39d0..b36e0fc9b31d2 100644
> > > --- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> > > +++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> > [ ... ]
> > > @@ -2879,7 +2879,7 @@ static void i40e_atr(struct i40e_ring *tx_ring, struct sk_buff *skb,
> > > return;
> > > /* if sampling is disabled do nothing */
> > > - if (!tx_ring->atr_sample_rate)
> > > + if (!pf->atr_sample_rate)
> > > return;
> >
> > [Severity: High]
> > Can this global check lead to a hardware Malicious Driver Detection (MDD)
> > event if ethtool flags are modified dynamically?
> >
> > If an administrator performs the following sequence:
> >
> > 1. Disables flow-director-atr via ethtool.
> > 2. Disables ntuple (which resets the ring and sets tx_ctx.fd_ena = 0).
> > 3. Re-enables flow-director-atr.
> >
> > The final step does not trigger a ring reset, so fd_ena remains 0 in the
> > hardware queue context.
> >
> > However, I40E_FLAG_FD_ATR_ENA is now true, and pf->atr_sample_rate is
> > globally set to a non-zero value.
> >
> > Will i40e_atr() now proceed and inject FDIR descriptors into a TX queue
> > that is not configured for FDIR?
> >
> > If so, does this cause the hardware to trigger an MDD event and hang the
> > TX queue?
> >
> The scenario you described was already broken before this patch, walking
> through the old code with the same sequence:
>
> 1. Disable ATR — flag cleared, __I40E_FD_ATR_AUTO_DISABLED set
> 2. Disable ntuple — ring reset happens, i40e_configure_tx_ring() runs with
> ATR off, so ring->atr_sample_rate = 0 and fd_ena = 0
> 3. Re-enable ATR — flag set, no ring reset
>
> In the old code, ring->atr_sample_rate is stuck at 0 from step 2, so
> i40e_atr() bails out at the sample rate check. That avoids the fd_ena
> problem, but ATR is also silently non-functional
> — the user re-enabled it but it doesn't actually work until something
> triggers a ring reset.
>
> This patch changes how that failure looks, instead of silently doing
> nothing, pf->atr_sample_rate is non-zero so i40e_atr() would proceed but the
> root cause is the same:
> toggling ATR via ethtool private flags doesn't trigger a ring reset, so
> fd_ena can be stale.
>
> Properly fixing this would mean triggering a reset when ATR is re-enabled.
> The reset calls i40e_configure_tx_ring(), which re-evaluates fd_ena based on
> the current flag state so fd_ena would be set to 1 since
> I40E_FLAG_FD_ATR_ENA is now on.
>
> What do you think about addressing this as a follow-up patch on top of this
> series? Since it's a pre-existing issue, it feels like it belongs as a
> separate fix rather than being mixed into this refactor.
Thanks for the detailed analysis, much appreciated.
I agree we can leave this to be addressed by a follow-up.
^ permalink raw reply
* Re: [PATCH net] mlxsw: pci: Quiesce EQ tasklet and CQ NAPI before teardown
From: kernel test robot @ 2026-07-21 12:47 UTC (permalink / raw)
To: Myeonghun Pak, Ido Schimmel, Petr Machata
Cc: oe-kbuild-all, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel, Myeonghun Pak,
Ijae Kim
In-Reply-To: <20260721062105.55014-1-mhun512@gmail.com>
Hi Myeonghun,
kernel test robot noticed the following build errors:
[auto build test ERROR on net/main]
url: https://github.com/intel-lab-lkp/linux/commits/Myeonghun-Pak/mlxsw-pci-Quiesce-EQ-tasklet-and-CQ-NAPI-before-teardown/20260721-142527
base: net/main
patch link: https://lore.kernel.org/r/20260721062105.55014-1-mhun512%40gmail.com
patch subject: [PATCH net] mlxsw: pci: Quiesce EQ tasklet and CQ NAPI before teardown
config: x86_64-rhel-9.4-bpf (https://download.01.org/0day-ci/archive/20260721/202607211419.DxdkHKb7-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260721/202607211419.DxdkHKb7-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202607211419.DxdkHKb7-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/net/ethernet/mellanox/mlxsw/pci.c: In function 'mlxsw_pci_cq_init':
>> drivers/net/ethernet/mellanox/mlxsw/pci.c:1077:32: error: 'truea' undeclared (first use in this function); did you mean 'true'?
1077 | q->u.cq.napi_enabled = truea
| ^~~~~
| true
drivers/net/ethernet/mellanox/mlxsw/pci.c:1077:32: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/net/ethernet/mellanox/mlxsw/pci.c:1077:37: error: expected ';' before 'mlxsw_pci_queue_doorbell_consumer_ring'
1077 | q->u.cq.napi_enabled = truea
| ^
| ;
1078 | mlxsw_pci_queue_doorbell_consumer_ring(mlxsw_pci, q);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
vim +1077 drivers/net/ethernet/mellanox/mlxsw/pci.c
1036
1037 static int mlxsw_pci_cq_init(struct mlxsw_pci *mlxsw_pci, char *mbox,
1038 struct mlxsw_pci_queue *q)
1039 {
1040 enum mlxsw_pci_cq_type cq_type = mlxsw_pci_cq_type(mlxsw_pci, q);
1041 int i;
1042 int err;
1043
1044 q->consumer_counter = 0;
1045
1046 for (i = 0; i < q->count; i++) {
1047 char *elem = mlxsw_pci_queue_elem_get(q, i);
1048
1049 mlxsw_pci_cqe_owner_set(q->u.cq.v, elem, 1);
1050 }
1051
1052 if (q->u.cq.v == MLXSW_PCI_CQE_V1)
1053 mlxsw_cmd_mbox_sw2hw_cq_cqe_ver_set(mbox,
1054 MLXSW_CMD_MBOX_SW2HW_CQ_CQE_VER_1);
1055 else if (q->u.cq.v == MLXSW_PCI_CQE_V2)
1056 mlxsw_cmd_mbox_sw2hw_cq_cqe_ver_set(mbox,
1057 MLXSW_CMD_MBOX_SW2HW_CQ_CQE_VER_2);
1058
1059 mlxsw_cmd_mbox_sw2hw_cq_c_eqn_set(mbox, MLXSW_PCI_EQ_COMP_NUM);
1060 mlxsw_cmd_mbox_sw2hw_cq_st_set(mbox, 0);
1061 mlxsw_cmd_mbox_sw2hw_cq_log_cq_size_set(mbox, ilog2(q->count));
1062 for (i = 0; i < MLXSW_PCI_AQ_PAGES; i++) {
1063 dma_addr_t mapaddr = __mlxsw_pci_queue_page_get(q, i);
1064
1065 mlxsw_cmd_mbox_sw2hw_cq_pa_set(mbox, i, mapaddr);
1066 }
1067 err = mlxsw_cmd_sw2hw_cq(mlxsw_pci->core, mbox, q->num);
1068 if (err)
1069 return err;
1070 mlxsw_pci_cq_napi_setup(q, cq_type);
1071
1072 err = mlxsw_pci_cq_page_pool_init(q, cq_type);
1073 if (err)
1074 goto err_page_pool_init;
1075
1076 napi_enable(&q->u.cq.napi);
> 1077 q->u.cq.napi_enabled = truea
1078 mlxsw_pci_queue_doorbell_consumer_ring(mlxsw_pci, q);
1079 mlxsw_pci_queue_doorbell_arm_consumer_ring(mlxsw_pci, q);
1080 return 0;
1081
1082 err_page_pool_init:
1083 mlxsw_pci_cq_napi_teardown(q);
1084 return err;
1085 }
1086
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH net 1/1] openvswitch: Fix CT limit teardown use-after-free
From: Andrew Lunn @ 2026-07-21 12:57 UTC (permalink / raw)
To: Yuan Tan
Cc: Aaron Conole, Ren Wei, xuyuqiabc, netdev, dev, echaudro,
i.maximets, davem, edumazet, pabeni, horms, pshelar, yihung.wei,
tonanli66
In-Reply-To: <CAPuPA7KiuA9agAXbXFRA6-wRHe6=GPFu47wjc-MY-twHQXTF2w@mail.gmail.com>
On Mon, Jul 20, 2026 at 07:02:45PM -0700, Yuan Tan wrote:
> On Mon, Jul 20, 2026 at 12:30 PM Aaron Conole <aconole@redhat.com> wrote:
> >
> > Andrew Lunn <andrew@lunn.ch> writes:
> >
> > > On Sun, Jul 19, 2026 at 11:54:31PM -0700, Yuan Tan wrote:
> > > >
> > > > On 7/19/26 19:52, Andrew Lunn wrote:
> > > > > On Mon, Jul 20, 2026 at 10:14:16AM +0800, Ren Wei wrote:
> > > > >> From: Yuqi Xu <xuyuqiabc@gmail.com>
> > > >> Assisted-by: Codex:GPT-5.4
> > > >> Co-developed-by: Nan Li <tonanli66@gmail.com>
> > > >> Signed-off-by: Nan Li <tonanli66@gmail.com>
> > > >> Signed-off-by: Yuqi Xu <xuyuqiabc@gmail.com>
> > > >> Reviewed-by: Ren Wei <enjou1224z@gmail.com>
> > > > Please take a look at
> > > > https://docs.kernel.org/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
> > > > and the sections that follow. What is listed here does not follow the
> > > > rules.
> >
> > After reading this document, did you spot the second issues?
> >
> > Andrew
>
> Hi Andrew,
>
> I have read through the document several times, but I am still not
> sure what you mean by the second issue. Could you please clarify which
> specific issue you are referring to?
>
> At the moment, all of our patches are reviewed by Ren Wei before they
> are sent out. Are you referring to that Ren Wei is not included with a
> Signed-off-by tag? We did consider adding one, although I was
> concerned that including too many tags might make the commit message
> unnecessarily cluttered.
This patch has been submitted by you. There needs to be a
Signed-off-by from you last on the list.
Any further SoBs (Signed-off-by:’s) following the author’s SoB are
from people handling and transporting the patch, but were not
involved in its development. SoB chains should reflect the real
route a patch took as it was propagated to the maintainers and
ultimately to Linus, with the first SoB entry signalling primary
authorship of a single author.
Andrew
^ permalink raw reply
* [PATCH net v2] mlxsw: pci: Quiesce EQ tasklet and CQ NAPI before teardown
From: Myeonghun Pak @ 2026-07-21 12:57 UTC (permalink / raw)
To: Ido Schimmel, Petr Machata
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, kernel test robot, netdev, linux-kernel,
Myeonghun Pak, Ijae Kim
mlxsw_pci_eq_irq_handler() schedules the EQ tasklet. The tasklet reads
the EQ ring and schedules CQ NAPI instances. The CQ poll callbacks, in
turn, dereference the RDQ or SDQ associated with the CQ.
mlxsw_pci_fini() unregisters the IRQ and immediately tears down the
asynchronous queues in RDQ, SDQ, CQ, EQ order. free_irq() waits for IRQ
handlers, but not for a tasklet already scheduled by one. In addition,
mlxsw_pci_cq_fini() disables each CQ NAPI only after all RDQs and SDQs
have been freed. A pending tasklet or NAPI poll can therefore access
freed queue storage.
Kill the EQ tasklet after free_irq() so it cannot schedule any more CQ
NAPI instances. Disable all CQ NAPI instances before freeing the first
descriptor queue, ensuring their poll callbacks have completed. Track
the enabled state per CQ to avoid disabling a NAPI instance twice when
the CQ is later destroyed, while preserving the partial initialization
unwind.
Fixes: eda6500a987a ("mlxsw: Add PCI bus implementation")
Cc: stable@vger.kernel.org
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
---
v2:
- Fix typo in napi_enabled assignment reported by kernel test robot.
v1: https://lore.kernel.org/r/20260721062105.55014-1-mhun512@gmail.com/
Found by static analysis on v7.2-rc2; not tested on hardware.
drivers/net/ethernet/mellanox/mlxsw/pci.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci.c b/drivers/net/ethernet/mellanox/mlxsw/pci.c
index 0da85d36647d..feeb32134d2a 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci.c
@@ -86,6 +86,7 @@ struct mlxsw_pci_queue {
enum mlxsw_pci_cqe_v v;
struct mlxsw_pci_queue *dq;
struct napi_struct napi;
+ bool napi_enabled;
struct page_pool *page_pool;
} cq;
struct {
@@ -989,6 +990,15 @@ static void mlxsw_pci_cq_napi_teardown(struct mlxsw_pci_queue *q)
netif_napi_del(&q->u.cq.napi);
}
+static void mlxsw_pci_cq_napi_disable(struct mlxsw_pci_queue *q)
+{
+ if (!q->u.cq.napi_enabled)
+ return;
+
+ napi_disable(&q->u.cq.napi);
+ q->u.cq.napi_enabled = false;
+}
+
static int mlxsw_pci_cq_page_pool_init(struct mlxsw_pci_queue *q,
enum mlxsw_pci_cq_type cq_type)
{
@@ -1064,6 +1074,7 @@ static int mlxsw_pci_cq_init(struct mlxsw_pci *mlxsw_pci, char *mbox,
goto err_page_pool_init;
napi_enable(&q->u.cq.napi);
+ q->u.cq.napi_enabled = true;
mlxsw_pci_queue_doorbell_consumer_ring(mlxsw_pci, q);
mlxsw_pci_queue_doorbell_arm_consumer_ring(mlxsw_pci, q);
return 0;
@@ -1078,7 +1089,7 @@ static void mlxsw_pci_cq_fini(struct mlxsw_pci *mlxsw_pci,
{
enum mlxsw_pci_cq_type cq_type = mlxsw_pci_cq_type(mlxsw_pci, q);
- napi_disable(&q->u.cq.napi);
+ mlxsw_pci_cq_napi_disable(q);
mlxsw_pci_cq_page_pool_fini(q, cq_type);
mlxsw_pci_cq_napi_teardown(q);
mlxsw_cmd_hw2sw_cq(mlxsw_pci->core, q->num);
@@ -1439,6 +1450,14 @@ err_cqs_init:
static void mlxsw_pci_aqs_fini(struct mlxsw_pci *mlxsw_pci)
{
+ struct mlxsw_pci_queue_type_group *queue_group;
+ int i;
+
+ queue_group = mlxsw_pci_queue_type_group_get(mlxsw_pci,
+ MLXSW_PCI_QUEUE_TYPE_CQ);
+ for (i = 0; i < queue_group->count; i++)
+ mlxsw_pci_cq_napi_disable(&queue_group->q[i]);
+
mlxsw_pci_queue_group_fini(mlxsw_pci, &mlxsw_pci_rdq_ops);
mlxsw_pci_queue_group_fini(mlxsw_pci, &mlxsw_pci_sdq_ops);
mlxsw_pci_queue_group_fini(mlxsw_pci, &mlxsw_pci_cq_ops);
@@ -2089,6 +2108,7 @@ static void mlxsw_pci_fini(void *bus_priv)
struct mlxsw_pci *mlxsw_pci = bus_priv;
free_irq(pci_irq_vector(mlxsw_pci->pdev, 0), mlxsw_pci);
+ tasklet_kill(&mlxsw_pci_eq_get(mlxsw_pci)->u.eq.tasklet);
mlxsw_pci_aqs_fini(mlxsw_pci);
mlxsw_pci_napi_devs_fini(mlxsw_pci);
mlxsw_pci_fw_area_fini(mlxsw_pci);
--
2.47.1
^ permalink raw reply related
* Re: [PATCH v2 net] net: hsr: fix memory leak on slave unregistration by removing synced VLANs
From: Felix Maurer @ 2026-07-21 13:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
netdev, eric.dumazet, syzbot+456957213f32970c0762,
Fernando Fernandez Mancera
In-Reply-To: <20260721101240.995597-1-edumazet@google.com>
On Tue, Jul 21, 2026 at 10:12:40AM +0000, Eric Dumazet wrote:
> When an HSR master device is brought UP, it auto-adds VLAN 0 via
> vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B).
>
> If a slave device is later unregistered while HSR is active (e.g., during
> netns cleanup or interface destruction), hsr_del_port() is called to
> detach the slave port from the HSR master. However, hsr_del_port() currently
> does not delete the VLAN IDs that were synced to the slave device by HSR.
>
> As a result, the slave device retains a refcount on VID 0 (and any other
> synced VLANs). When the slave device is destroyed, its vlan_info /
> vlan_vid_info structure remains allocated, leading to a memory leak.
>
> Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in
> hsr_del_port() before unlinking slave A or slave B ports, matching the
> propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid()
> and the cleanup behavior in bonding and team drivers.
>
> Fixes: 1a8a63a5305e ("net: hsr: Add VLAN CTAG filter support")
> Reported-by: syzbot+456957213f32970c0762@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/netdev/6a4cb6ca.57639fcc.86d58.000b.GAE@google.com/T/#u
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Felix Maurer <fmaurer@redhat.com>
> Cc: Fernando Fernandez Mancera <fmancera@suse.de>
Looks good to me, thank you!
Reviewed-by: Felix Maurer <fmaurer@redhat.com>
^ permalink raw reply
* Re: [PATCH bpf] veth: convert frag_list skbs before running XDP
From: Matt Fleming @ 2026-07-21 13:02 UTC (permalink / raw)
To: Maciej Fijalkowski
Cc: Toke Høiland-Jørgensen, Alexei Starovoitov,
Daniel Borkmann, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Lorenzo Bianconi, bpf, netdev,
stable, kernel-team, Matt Fleming
In-Reply-To: <al9Q8yPOfQIVxvp1@boxer>
On Tue, Jul 21, 2026 at 12:58:59PM +0200, Maciej Fijalkowski wrote:
>
> Hi all,
>
> I had an RFC that made veth to reuse generic XDP code path [0]. Jakub
> commented we could have a common pp cow check on both sides. My plan is to
> revive this work as this still causes page_pool issues when AF_XDP is used
> on veth.
>
> [0]: https://lore.kernel.org/bpf/20260509084858.773921-1-maciej.fijalkowski@intel.com/
That sounds great. I'd be happy to test out the next version.
Thanks,
Matt
^ permalink raw reply
* [PATCH v2 0/3] Bring includes in linux/kmod.h up to date
From: Petr Pavlu @ 2026-07-21 13:11 UTC (permalink / raw)
To: Tony Luck, Borislav Petkov, Thomas Gleixner, Ingo Molnar,
Dave Hansen, x86, H. Peter Anvin, Philipp Reisner, Lars Ellenberg,
Christoph Böhmwalder, Jens Axboe, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Rafael J. Wysocki, Michal Januszewski,
Helge Deller, Alexander Viro, Christian Brauner, Jan Kara,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Mark Fasheh,
Joel Becker, Joseph Qi, Tejun Heo, Johannes Weiner,
Michal Koutný, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Pavel Machek, Len Brown,
Andrew Morton, Danilo Krummrich, Nikolay Aleksandrov,
Ido Schimmel, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, David Howells, Jarkko Sakkinen,
Paul Moore, James Morris, Serge E. Hallyn, Kentaro Takeda,
Tetsuo Handa
Cc: linux-edac, linux-kernel, drbd-dev, linux-block, greybus-dev,
linuxppc-dev, linux-acpi, linux-fbdev, dri-devel, linux-fsdevel,
linux-nfs, ocfs2-devel, cgroups, linux-modules, linux-pm,
driver-core, bridge, netdev, keyrings, linux-security-module
The usermode helper declarations were previously provided by linux/kmod.h
but commit c1f3fa2a4fde ("kmod: split off umh headers into its own file")
moved them to linux/umh.h in 2017. Add explicit includes of linux/umh.h to
files that use usermode helpers and remove linux/kmod.h where it is no
longer needed.
Also add a missing include of linux/sysctl.h to kernel/time/jiffies.c.
Finally, clean up linux/kmod.h so that it includes only the headers that it
actually requires, importantly removing the compat linux/umh.h include.
This cleanup is motivated by trying to reduce the preprocessed size of
linux/module.h, which includes linux/kmod.h. The linux/module.h header is
included by every *.mod.c file to provide `struct module` and other related
definitions, so it should avoid pulling in unnecessary dependencies. Note
that this series doesn't immediately improve the situation, since most of
the files included by linux/kmod.h are, for now, also included by
linux/module.h through other paths.
Apologies for the wide distribution. Acked-bys are appreciated.
Changes in v2:
- Remove the linux/kmod.h include from kernel/cgroup/cgroup-v1.c.
- Add a missing include of linux/sysctl.h to kernel/time/jiffies.c.
- Link to v1: https://lore.kernel.org/linux-modules/20260708154510.6794-1-petr.pavlu@suse.com/
Petr Pavlu (3):
umh, treewide: Explicitly include linux/umh.h where needed
time/jiffies: Include linux/sysctl.h for proc_int_u2k_conv_uop(), ...
module: Bring includes in linux/kmod.h up to date
arch/x86/kernel/cpu/mce/dev-mcelog.c | 2 +-
drivers/block/drbd/drbd_nl.c | 1 +
drivers/greybus/svc_watchdog.c | 1 +
drivers/macintosh/windfarm_core.c | 1 +
drivers/pnp/pnpbios/core.c | 2 +-
drivers/video/fbdev/uvesafb.c | 1 +
fs/coredump.c | 2 +-
fs/nfs/cache_lib.c | 2 +-
fs/nfsd/nfs4layouts.c | 2 +-
fs/nfsd/nfs4recover.c | 1 +
fs/ocfs2/stackglue.c | 1 +
include/linux/kmod.h | 12 ++----------
kernel/cgroup/cgroup-v1.c | 2 +-
kernel/module/kmod.c | 1 +
kernel/power/process.c | 2 +-
kernel/reboot.c | 2 +-
kernel/time/jiffies.c | 1 +
kernel/umh.c | 2 +-
lib/kobject_uevent.c | 2 +-
net/bridge/br_stp_if.c | 2 +-
security/keys/request_key.c | 2 +-
security/tomoyo/common.h | 2 +-
22 files changed, 23 insertions(+), 23 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH v2 1/3] umh, treewide: Explicitly include linux/umh.h where needed
From: Petr Pavlu @ 2026-07-21 13:11 UTC (permalink / raw)
To: Tony Luck, Borislav Petkov, Thomas Gleixner, Ingo Molnar,
Dave Hansen, x86, H. Peter Anvin, Philipp Reisner, Lars Ellenberg,
Christoph Böhmwalder, Jens Axboe, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Rafael J. Wysocki, Michal Januszewski,
Helge Deller, Alexander Viro, Christian Brauner, Jan Kara,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Mark Fasheh,
Joel Becker, Joseph Qi, Tejun Heo, Johannes Weiner,
Michal Koutný, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Pavel Machek, Len Brown,
Andrew Morton, Danilo Krummrich, Nikolay Aleksandrov,
Ido Schimmel, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, David Howells, Jarkko Sakkinen,
Paul Moore, James Morris, Serge E. Hallyn, Kentaro Takeda,
Tetsuo Handa
Cc: linux-edac, linux-kernel, drbd-dev, linux-block, greybus-dev,
linuxppc-dev, linux-acpi, linux-fbdev, dri-devel, linux-fsdevel,
linux-nfs, ocfs2-devel, cgroups, linux-modules, linux-pm,
driver-core, bridge, netdev, keyrings, linux-security-module
In-Reply-To: <20260721131207.803760-1-petr.pavlu@suse.com>
The usermode helper declarations were previously provided by linux/kmod.h
but commit c1f3fa2a4fde ("kmod: split off umh headers into its own file")
moved them to linux/umh.h in 2017. Add explicit includes of linux/umh.h to
files that use usermode helpers and remove linux/kmod.h where it is no
longer needed.
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
---
arch/x86/kernel/cpu/mce/dev-mcelog.c | 2 +-
drivers/block/drbd/drbd_nl.c | 1 +
drivers/greybus/svc_watchdog.c | 1 +
drivers/macintosh/windfarm_core.c | 1 +
drivers/pnp/pnpbios/core.c | 2 +-
drivers/video/fbdev/uvesafb.c | 1 +
fs/coredump.c | 2 +-
fs/nfs/cache_lib.c | 2 +-
fs/nfsd/nfs4layouts.c | 2 +-
fs/nfsd/nfs4recover.c | 1 +
fs/ocfs2/stackglue.c | 1 +
kernel/cgroup/cgroup-v1.c | 2 +-
kernel/module/kmod.c | 1 +
kernel/power/process.c | 2 +-
kernel/reboot.c | 2 +-
kernel/umh.c | 2 +-
lib/kobject_uevent.c | 2 +-
net/bridge/br_stp_if.c | 2 +-
security/keys/request_key.c | 2 +-
security/tomoyo/common.h | 2 +-
20 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/cpu/mce/dev-mcelog.c b/arch/x86/kernel/cpu/mce/dev-mcelog.c
index 053555206d81..af4e76babe7a 100644
--- a/arch/x86/kernel/cpu/mce/dev-mcelog.c
+++ b/arch/x86/kernel/cpu/mce/dev-mcelog.c
@@ -11,7 +11,7 @@
#include <linux/miscdevice.h>
#include <linux/slab.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/poll.h>
#include "internal.h"
diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
index f9ffcd67607b..de90cf4a0789 100644
--- a/drivers/block/drbd/drbd_nl.c
+++ b/drivers/block/drbd/drbd_nl.c
@@ -14,6 +14,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/module.h>
+#include <linux/umh.h>
#include <linux/drbd.h>
#include <linux/in.h>
#include <linux/fs.h>
diff --git a/drivers/greybus/svc_watchdog.c b/drivers/greybus/svc_watchdog.c
index 16e6de5e9eff..b318eb34bcca 100644
--- a/drivers/greybus/svc_watchdog.c
+++ b/drivers/greybus/svc_watchdog.c
@@ -7,6 +7,7 @@
#include <linux/delay.h>
#include <linux/suspend.h>
+#include <linux/umh.h>
#include <linux/workqueue.h>
#include <linux/greybus.h>
diff --git a/drivers/macintosh/windfarm_core.c b/drivers/macintosh/windfarm_core.c
index 5307b1e34261..e66de11c69a3 100644
--- a/drivers/macintosh/windfarm_core.c
+++ b/drivers/macintosh/windfarm_core.c
@@ -34,6 +34,7 @@
#include <linux/platform_device.h>
#include <linux/mutex.h>
#include <linux/freezer.h>
+#include <linux/umh.h>
#include "windfarm.h"
diff --git a/drivers/pnp/pnpbios/core.c b/drivers/pnp/pnpbios/core.c
index f7e86ae9f72f..46af1f549337 100644
--- a/drivers/pnp/pnpbios/core.c
+++ b/drivers/pnp/pnpbios/core.c
@@ -47,7 +47,7 @@
#include <linux/delay.h>
#include <linux/acpi.h>
#include <linux/freezer.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/kthread.h>
#include <asm/page.h>
diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
index 9d82326c744f..6c503e6914d6 100644
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -23,6 +23,7 @@
#include <linux/io.h>
#include <linux/mutex.h>
#include <linux/slab.h>
+#include <linux/umh.h>
#include <video/edid.h>
#include <video/uvesafb.h>
#ifdef CONFIG_X86
diff --git a/fs/coredump.c b/fs/coredump.c
index e68a76ff92a3..4908b44f6fdc 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -32,7 +32,7 @@
#include <linux/tsacct_kern.h>
#include <linux/cn_proc.h>
#include <linux/audit.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/fsnotify.h>
#include <linux/fs_struct.h>
#include <linux/pipe_fs_i.h>
diff --git a/fs/nfs/cache_lib.c b/fs/nfs/cache_lib.c
index 9738a1ae92ca..ca4e81d4e315 100644
--- a/fs/nfs/cache_lib.c
+++ b/fs/nfs/cache_lib.c
@@ -6,7 +6,7 @@
*
* Copyright (c) 2009 Trond Myklebust <Trond.Myklebust@netapp.com>
*/
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/mount.h>
diff --git a/fs/nfsd/nfs4layouts.c b/fs/nfsd/nfs4layouts.c
index f34320e4c2f4..008f0f088c3a 100644
--- a/fs/nfsd/nfs4layouts.c
+++ b/fs/nfsd/nfs4layouts.c
@@ -3,7 +3,7 @@
* Copyright (c) 2014 Christoph Hellwig.
*/
#include <linux/exportfs_block.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/file.h>
#include <linux/jhash.h>
#include <linux/sched.h>
diff --git a/fs/nfsd/nfs4recover.c b/fs/nfsd/nfs4recover.c
index 6ea25a52d2f4..20b98e43f668 100644
--- a/fs/nfsd/nfs4recover.c
+++ b/fs/nfsd/nfs4recover.c
@@ -41,6 +41,7 @@
#include <linux/fs.h>
#include <linux/hex.h>
#include <linux/module.h>
+#include <linux/umh.h>
#include <net/net_namespace.h>
#include <linux/sunrpc/rpc_pipe_fs.h>
#include <linux/sunrpc/clnt.h>
diff --git a/fs/ocfs2/stackglue.c b/fs/ocfs2/stackglue.c
index 741d6191d871..0ccaab29426d 100644
--- a/fs/ocfs2/stackglue.c
+++ b/fs/ocfs2/stackglue.c
@@ -18,6 +18,7 @@
#include <linux/kobject.h>
#include <linux/sysfs.h>
#include <linux/sysctl.h>
+#include <linux/umh.h>
#include "ocfs2_fs.h"
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index a4337c9b5287..cbcde5c28b18 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -2,7 +2,7 @@
#include "cgroup-internal.h"
#include <linux/ctype.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/sort.h>
#include <linux/delay.h>
#include <linux/mm.h>
diff --git a/kernel/module/kmod.c b/kernel/module/kmod.c
index a25dccdf7aa7..dcaad5d65275 100644
--- a/kernel/module/kmod.c
+++ b/kernel/module/kmod.c
@@ -28,6 +28,7 @@
#include <linux/ptrace.h>
#include <linux/async.h>
#include <linux/uaccess.h>
+#include <linux/umh.h>
#include <trace/events/module.h>
#include "internal.h"
diff --git a/kernel/power/process.c b/kernel/power/process.c
index dc0dfc349f22..295904ec9a82 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -16,7 +16,7 @@
#include <linux/freezer.h>
#include <linux/delay.h>
#include <linux/workqueue.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <trace/events/power.h>
#include <linux/cpuset.h>
diff --git a/kernel/reboot.c b/kernel/reboot.c
index 695c33e75efd..3d4a262973e7 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -11,13 +11,13 @@
#include <linux/ctype.h>
#include <linux/export.h>
#include <linux/kexec.h>
-#include <linux/kmod.h>
#include <linux/kmsg_dump.h>
#include <linux/reboot.h>
#include <linux/suspend.h>
#include <linux/syscalls.h>
#include <linux/syscore_ops.h>
#include <linux/uaccess.h>
+#include <linux/umh.h>
/*
* this indicates whether you can reboot with ctrl-alt-del: the default is yes
diff --git a/kernel/umh.c b/kernel/umh.c
index 48117c569e1a..72b2d9a878aa 100644
--- a/kernel/umh.c
+++ b/kernel/umh.c
@@ -8,7 +8,7 @@
#include <linux/binfmts.h>
#include <linux/syscalls.h>
#include <linux/unistd.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/slab.h>
#include <linux/completion.h>
#include <linux/cred.h>
diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
index ddbc4d7482d2..a67129e452a3 100644
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -17,7 +17,7 @@
#include <linux/string.h>
#include <linux/kobject.h>
#include <linux/export.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/slab.h>
#include <linux/socket.h>
#include <linux/skbuff.h>
diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index a7e5422eb5d1..89bc161a4b47 100644
--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
@@ -8,7 +8,7 @@
*/
#include <linux/kernel.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/etherdevice.h>
#include <linux/rtnetlink.h>
#include <net/switchdev.h>
diff --git a/security/keys/request_key.c b/security/keys/request_key.c
index fa2bb9f2f538..e6ba2d054399 100644
--- a/security/keys/request_key.c
+++ b/security/keys/request_key.c
@@ -9,7 +9,7 @@
#include <linux/export.h>
#include <linux/sched.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/err.h>
#include <linux/keyctl.h>
#include <linux/slab.h>
diff --git a/security/tomoyo/common.h b/security/tomoyo/common.h
index d098cf8aae61..d26034000913 100644
--- a/security/tomoyo/common.h
+++ b/security/tomoyo/common.h
@@ -16,7 +16,7 @@
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/file.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/fs.h>
#include <linux/sched.h>
#include <linux/namei.h>
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/3] time/jiffies: Include linux/sysctl.h for proc_int_u2k_conv_uop(), ...
From: Petr Pavlu @ 2026-07-21 13:11 UTC (permalink / raw)
To: Tony Luck, Borislav Petkov, Thomas Gleixner, Ingo Molnar,
Dave Hansen, x86, H. Peter Anvin, Philipp Reisner, Lars Ellenberg,
Christoph Böhmwalder, Jens Axboe, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Rafael J. Wysocki, Michal Januszewski,
Helge Deller, Alexander Viro, Christian Brauner, Jan Kara,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Mark Fasheh,
Joel Becker, Joseph Qi, Tejun Heo, Johannes Weiner,
Michal Koutný, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Pavel Machek, Len Brown,
Andrew Morton, Danilo Krummrich, Nikolay Aleksandrov,
Ido Schimmel, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, David Howells, Jarkko Sakkinen,
Paul Moore, James Morris, Serge E. Hallyn, Kentaro Takeda,
Tetsuo Handa
Cc: linux-edac, linux-kernel, drbd-dev, linux-block, greybus-dev,
linuxppc-dev, linux-acpi, linux-fbdev, dri-devel, linux-fsdevel,
linux-nfs, ocfs2-devel, cgroups, linux-modules, linux-pm,
driver-core, bridge, netdev, keyrings, linux-security-module
In-Reply-To: <20260721131207.803760-1-petr.pavlu@suse.com>
The kernel/time/jiffies.c file uses proc_int_u2k_conv_uop(),
proc_int_k2u_conv_kop(), proc_int_conv(), proc_dointvec_conv() and
proc_doulongvec_minmax_conv(), which are declared in linux/sysctl.h. It
currently relies on this header being included indirectly through
linux/module.h -> linux/kmod.h. Add the missing include in preparation for
removing the linux/sysctl.h include from linux/kmod.h.
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
---
kernel/time/jiffies.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/time/jiffies.c b/kernel/time/jiffies.c
index d51428867a33..17cdb5ef8893 100644
--- a/kernel/time/jiffies.c
+++ b/kernel/time/jiffies.c
@@ -8,6 +8,7 @@
#include <linux/jiffies.h>
#include <linux/module.h>
#include <linux/init.h>
+#include <linux/sysctl.h>
#include "timekeeping.h"
#include "tick-internal.h"
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox