* ax25: fix possible use-after-free
From: f6bvp @ 2019-02-16 22:33 UTC (permalink / raw)
To: netdev
Patch applied successfully on Linux draws-f6bvp 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux
However ax25_route_lock_use and ax25_route_lock_unuse() are not declared and compile failed.
make : on entre dans le répertoire « /usr/src/linux-headers-4.14.79-v7+ »
CC [M] /usr/src/linux-4.14.y/net/ax25/ax25_ip.o
/usr/src/linux-4.14.y/net/ax25/ax25_ip.c: In function ‘ax25_ip_xmit’:
/usr/src/linux-4.14.y/net/ax25/ax25_ip.c:117:2: error: implicit declaration of function ‘ax25_route_lock_use’ [-Werror=implicit-function-declaration]
ax25_route_lock_use();
^~~~~~~~~~~~~~~~~~~
/usr/src/linux-4.14.y/net/ax25/ax25_ip.c:211:2: error: implicit declaration of function ‘ax25_route_lock_unuse’ [-Werror=implicit-function-declaration]
ax25_route_lock_unuse();
^~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
scripts/Makefile.build:328 : la recette pour la cible « /usr/src/linux-4.14.y/net/ax25/ax25_ip.o » a echouee
make[1]: *** [/usr/src/linux-4.14.y/net/ax25/ax25_ip.o] Erreur 1
Makefile:1527 : la recette pour la cible « _module_/usr/src/linux-4.14.y/net/ax25 » a echouee
make: *** [_module_/usr/src/linux-4.14.y/net/ax25] Erreur 2
make : on quitte le repertoire « /usr/src/linux-headers-4.14.79-v7+ »
Bernard, f6bvp
^ permalink raw reply
* Re: [PATCH] net: Fix for_each_netdev_feature on Big endian
From: David Miller @ 2019-02-16 21:46 UTC (permalink / raw)
To: eric.dumazet; +Cc: hauke.mehrtens, netdev, jarod, hauke, stable
In-Reply-To: <8e03f4cb-11e2-9e85-ed5e-019da79b3806@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 16 Feb 2019 13:01:28 -0800
> This commit added a call to fls64(), but not the needed include.
>
> This might break some uses I think.
>
> I suggest the following fix :
>
> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
> index c50cedb65cf56fe7d722a5a321b714ed83f449a0..d3f61011f4346e4ea80b61f88bd24541dd006014 100644
> --- a/include/linux/netdev_features.h
> +++ b/include/linux/netdev_features.h
> @@ -11,6 +11,7 @@
> #define _LINUX_NETDEV_FEATURES_H
>
> #include <linux/types.h>
> +#include <linux/bitops.h>
> #include <asm/byteorder.h>
>
> typedef u64 netdev_features_t;
Ok I'm build testing that right now, thanks.
====================
From 8681ef1f3d295bd3600315325f3b3396d76d02f6 Mon Sep 17 00:00:00 2001
From: "David S. Miller" <davem@davemloft.net>
Date: Sat, 16 Feb 2019 13:44:39 -0800
Subject: [PATCH] net: Add header for usage of fls64()
Fixes: 3b89ea9c5902 ("net: Fix for_each_netdev_feature on Big endian")
Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/linux/netdev_features.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index fce28562bed2..4c76fe2c8488 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -11,6 +11,7 @@
#define _LINUX_NETDEV_FEATURES_H
#include <linux/types.h>
+#include <linux/bitops.h>
#include <asm/byteorder.h>
typedef u64 netdev_features_t;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] net: Fix for_each_netdev_feature on Big endian
From: Eric Dumazet @ 2019-02-16 21:01 UTC (permalink / raw)
To: David Miller, hauke.mehrtens; +Cc: netdev, jarod, hauke, stable
In-Reply-To: <20190215.202453.382883236911745765.davem@davemloft.net>
On 02/15/2019 08:24 PM, David Miller wrote:
> From: Hauke Mehrtens <hauke.mehrtens@intel.com>
> Date: Fri, 15 Feb 2019 17:58:54 +0100
>
>> The features attribute is of type u64 and stored in the native endianes on
>> the system. The for_each_set_bit() macro takes a pointer to a 32 bit array
>> and goes over the bits in this area. On little Endian systems this also
>> works with an u64 as the most significant bit is on the highest address,
>> but on big endian the words are swapped. When we expect bit 15 here we get
>> bit 47 (15 + 32).
>>
>> This patch converts it more or less to its own for_each_set_bit()
>> implementation which works on 64 bit integers directly. This is then
>> completely in host endianness and should work like expected.
>>
>> Fixes: fd867d51f ("net/core: generic support for disabling netdev features down stack")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Hauke Mehrtens <hauke.mehrtens@intel.com>
>
> Applied and queued up for -stable.
>
> Please do not CC: stable for networking fixes, I handle -stable submissions
> myself manually and this is documented in the netdev FAQ.
>
This commit added a call to fls64(), but not the needed include.
This might break some uses I think.
I suggest the following fix :
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index c50cedb65cf56fe7d722a5a321b714ed83f449a0..d3f61011f4346e4ea80b61f88bd24541dd006014 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -11,6 +11,7 @@
#define _LINUX_NETDEV_FEATURES_H
#include <linux/types.h>
+#include <linux/bitops.h>
#include <asm/byteorder.h>
typedef u64 netdev_features_t;
^ permalink raw reply related
* Re: [PATCH RFC] net: bridge: don't flood known multicast traffic when snooping is enabled
From: Linus Lüssing @ 2019-02-16 20:37 UTC (permalink / raw)
To: nikolay
Cc: Ido Schimmel, netdev, roopa, wkok, anuradhak, bridge, davem,
stephen
In-Reply-To: <E8A29F94-091F-44CA-9E33-481BF21C359D@cumulusnetworks.com>
On Sat, Feb 16, 2019 at 09:27:26PM +0200, nikolay@cumulusnetworks.com wrote:
> >>The no querier condition is not currently reflected via switchdev, so
> >>the behavior you're proposing in your patch is what actually happens
> >in
> >>the data plane.
> >>
> >>We already hit the problem Linus mentioned in commit b00589af3b04
> >>("bridge: disable snooping if there is no querier"). Namely, IPv6 ND
> >>broke because a port joined before the bridge was created.
> >>
> >>I introduced a workaround in commit 9d45deb04c59 ("mlxsw: spectrum:
> >>Treat IPv6 unregistered multicast as broadcast"). I'm interested to
> >>know
> >>what other vendors are doing. Can you elaborate?
> >>
> >
> >Exactly like your fix. :) Flood it, this patch unfortunately breaks it
> >because of mrouters flag, but we can retain the behaviour
> >by forwarding only known mdsts to their ports and flooding
> >unregistered mcast when there is no querier. I think that is
> >what others do by default too, actually I think they flood with querier
> >as well. Maybe unknown mcast flooding should be controlled by a flag
> >when a querier is present
> >because we've had this behaviour for a long time, personally I'd have
> >it on
> >by default.
>
> Ugh, mispoke please read the above statement to be only about no querier.
> I meant flooding v6 link-local always.
And for routable IPv6 multicast, how would you detect multicast
listeners on the local link in absence of a querier?
^ permalink raw reply
* Re: [pull request][net-next 00/13] Mellanox, BlueField SmartNIC
From: David Miller @ 2019-02-16 20:11 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20190216013452.21131-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Fri, 15 Feb 2019 17:34:39 -0800
> This series adds the support for Melanox BlueField SmartNIC.
> For more information please see tag log below.
>
> Please note the merge commit of mlx5-next at the base of the pull request:
> 259fae5a2cff ("Merge branch 'mlx5-next' of git://git.kernel.org/.../mellanox/linux")
>
> Please pull and let me know if there is any problem.
Pulled, thanks for all of the contextual info, it really helps.
I'll push this out after my build tests complete.
^ permalink raw reply
* Re: [PATCH RFC] net: bridge: don't flood known multicast traffic when snooping is enabled
From: Linus Lüssing @ 2019-02-16 20:04 UTC (permalink / raw)
To: Nikolay Aleksandrov, Ido Schimmel
Cc: netdev, roopa, wkok, anuradhak, bridge, davem, stephen
In-Reply-To: <733b151e-47dd-ad9a-b112-473cf551fbeb@cumulusnetworks.com>
Hi Nik, hi Ido,
By the way speaking about the IGMP/MLD querier mechanism. Not sure if
you are subscribed to the pim@ietf.org or mcast-wifi@ietf.org mailing lists.
There was a call for volunteers to progress IGMP/MLD to standards
track not that long ago:
"[pim] Volunteers needed for work on progressing IGMP/MLD on the standards track"
https://mailarchive.ietf.org/arch/msg/pim/F5y_w6jnrtzBpEiC7F_TxBv9PXI
I had voiced some concerns regarding the IGMPv2/MLDv1 report
suppression and the querier mechanism and their unfavourable
implications, as well as some issues (or ambiguities at least) with RFC4541:
https://mailarchive.ietf.org/arch/msg/pim/DWWYpnsZsbqHtafwYZ_swhDpbcQ
https://mailarchive.ietf.org/arch/msg/pim/omI4-pg-12vO88YuZcRP5TCz4wY
It seems that some bigger vendors had gathered for a phone call:
https://mailarchive.ietf.org/arch/msg/pim/jPAbf-PHgtgpwe8lgyjOzCHlhc0
But I haven't heard anything back from that meeting on those
lists.
Just wanted to forward this, in case you guys might maybe be
interested to participate there in some way. :-)
Cheers, Linus
^ permalink raw reply
* [PATCH net-next 4/4] net: phy: marvell10g: check for newly set aneg in mv3310_config_aneg
From: Heiner Kallweit @ 2019-02-16 19:53 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <0423e795-0215-053f-57ff-386242a6d7ce@gmail.com>
Even if the advertisement registers content didn't change, we may have
just switched to aneg, and therefore have to trigger an aneg restart.
This matches the behavior of genphy_config_aneg().
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/marvell10g.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 03fa50087..4d8a290eb 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -288,6 +288,16 @@ static int mv3310_config_aneg(struct phy_device *phydev)
if (ret > 0)
changed = true;
+ if (!changed) {
+ /* Configure and restart aneg if it wasn't set before */
+ ret = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_CTRL1);
+ if (ret < 0)
+ return ret;
+
+ if (!(ret & MDIO_AN_CTRL1_ENABLE))
+ changed = 1;
+ }
+
if (changed)
ret = genphy_c45_restart_aneg(phydev);
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 3/4] net: phy: marvell10g: use genphy_c45_an_config_an
From: Heiner Kallweit @ 2019-02-16 19:52 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <0423e795-0215-053f-57ff-386242a6d7ce@gmail.com>
From: Andrew Lunn <andrew@lunn.ch>
Use new function genphy_c45_config_aneg() in mv3310_config_aneg().
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
[hkallweit1@gmail.com: patch splitted]
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/marvell10g.c | 22 +---------------------
1 file changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 4a6ae63ab..03fa50087 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -274,13 +274,7 @@ static int mv3310_config_aneg(struct phy_device *phydev)
if (phydev->autoneg == AUTONEG_DISABLE)
return genphy_c45_pma_setup_forced(phydev);
- linkmode_and(phydev->advertising, phydev->advertising,
- phydev->supported);
-
- ret = phy_modify_mmd_changed(phydev, MDIO_MMD_AN, MDIO_AN_ADVERTISE,
- ADVERTISE_ALL | ADVERTISE_100BASE4 |
- ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM,
- linkmode_adv_to_mii_adv_t(phydev->advertising));
+ ret = genphy_c45_an_config_an(phydev);
if (ret < 0)
return ret;
if (ret > 0)
@@ -294,20 +288,6 @@ static int mv3310_config_aneg(struct phy_device *phydev)
if (ret > 0)
changed = true;
- /* 10G control register */
- if (linkmode_test_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
- phydev->advertising))
- reg = MDIO_AN_10GBT_CTRL_ADV10G;
- else
- reg = 0;
-
- ret = phy_modify_mmd_changed(phydev, MDIO_MMD_AN, MDIO_AN_10GBT_CTRL,
- MDIO_AN_10GBT_CTRL_ADV10G, reg);
- if (ret < 0)
- return ret;
- if (ret > 0)
- changed = true;
-
if (changed)
ret = genphy_c45_restart_aneg(phydev);
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 2/4] net: phy: add genphy_c45_an_config_an
From: Heiner Kallweit @ 2019-02-16 19:51 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <0423e795-0215-053f-57ff-386242a6d7ce@gmail.com>
From: Andrew Lunn <andrew@lunn.ch>
C45 configuration of 10/100 and multi-giga bit auto negotiation
advertisement is standardized. Configuration of 1000Base-T however
appears to be vendor specific. Move the generic code out of the
Marvell driver into the common phy-c45.c file.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
[hkallweit1@gmail.com: use new helper linkmode_adv_to_mii_10gbt_adv_t and split patch]
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy-c45.c | 44 +++++++++++++++++++++++++++++++++++++++
include/linux/phy.h | 1 +
2 files changed, 45 insertions(+)
diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
index 0374c50b1..bea1b0c6e 100644
--- a/drivers/net/phy/phy-c45.c
+++ b/drivers/net/phy/phy-c45.c
@@ -78,6 +78,50 @@ int genphy_c45_pma_setup_forced(struct phy_device *phydev)
}
EXPORT_SYMBOL_GPL(genphy_c45_pma_setup_forced);
+/**
+ * genphy_c45_an_config_an - configure advertisement registers
+ * @phydev: target phy_device struct
+ *
+ * Configure advertisement registers based on modes set in phydev->advertising
+ *
+ * Returns negative errno code on failure, 0 if advertisement didn't change,
+ * or 1 if advertised modes changed.
+ */
+int genphy_c45_an_config_an(struct phy_device *phydev)
+{
+ int changed = 0, ret;
+ u32 adv;
+
+ linkmode_and(phydev->advertising, phydev->advertising,
+ phydev->supported);
+
+ adv = linkmode_adv_to_mii_adv_t(phydev->advertising);
+
+ ret = phy_modify_mmd(phydev, MDIO_MMD_AN, MDIO_AN_ADVERTISE,
+ ADVERTISE_ALL | ADVERTISE_100BASE4 |
+ ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM,
+ adv);
+ if (ret < 0)
+ return ret;
+ if (ret > 0)
+ changed = 1;
+
+ adv = linkmode_adv_to_mii_10gbt_adv_t(phydev->advertising);
+
+ ret = phy_modify_mmd(phydev, MDIO_MMD_AN, MDIO_AN_10GBT_CTRL,
+ MDIO_AN_10GBT_CTRL_ADV10G |
+ MDIO_AN_10GBT_CTRL_ADV5G |
+ MDIO_AN_10GBT_CTRL_ADV2_5G,
+ adv);
+ if (ret < 0)
+ return ret;
+ if (ret > 0)
+ changed = 1;
+
+ return changed;
+}
+EXPORT_SYMBOL_GPL(genphy_c45_an_config_an);
+
/**
* genphy_c45_an_disable_aneg - disable auto-negotiation
* @phydev: target phy_device struct
diff --git a/include/linux/phy.h b/include/linux/phy.h
index bf1070c2a..dabcef5ba 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1101,6 +1101,7 @@ int genphy_c45_read_link(struct phy_device *phydev);
int genphy_c45_read_lpa(struct phy_device *phydev);
int genphy_c45_read_pma(struct phy_device *phydev);
int genphy_c45_pma_setup_forced(struct phy_device *phydev);
+int genphy_c45_an_config_an(struct phy_device *phydev);
int genphy_c45_an_disable_aneg(struct phy_device *phydev);
int genphy_c45_read_mdix(struct phy_device *phydev);
int genphy_c45_pma_read_abilities(struct phy_device *phydev);
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 1/4] net: phy: add helper linkmode_adv_to_mii_10gbt_adv_t
From: Heiner Kallweit @ 2019-02-16 19:50 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <0423e795-0215-053f-57ff-386242a6d7ce@gmail.com>
Add a helper linkmode_adv_to_mii_10gbt_adv_t(), similar to
linkmode_adv_to_mii_adv_t.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
include/linux/mdio.h | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/include/linux/mdio.h b/include/linux/mdio.h
index 5b872c45f..5a65f32d8 100644
--- a/include/linux/mdio.h
+++ b/include/linux/mdio.h
@@ -280,6 +280,31 @@ static inline void mii_10gbt_stat_mod_linkmode_lpa_t(unsigned long *advertising,
advertising, lpa & MDIO_AN_10GBT_STAT_LP10G);
}
+/**
+ * linkmode_adv_to_mii_10gbt_adv_t
+ * @advertising: the linkmode advertisement settings
+ *
+ * A small helper function that translates linkmode advertisement
+ * settings to phy autonegotiation advertisements for the C45
+ * 10GBASE-T AN CONTROL (7.32) register.
+ */
+static inline u32 linkmode_adv_to_mii_10gbt_adv_t(unsigned long *advertising)
+{
+ u32 result = 0;
+
+ if (linkmode_test_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
+ advertising))
+ result |= MDIO_AN_10GBT_CTRL_ADV2_5G;
+ if (linkmode_test_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+ advertising))
+ result |= MDIO_AN_10GBT_CTRL_ADV5G;
+ if (linkmode_test_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
+ advertising))
+ result |= MDIO_AN_10GBT_CTRL_ADV10G;
+
+ return result;
+}
+
int __mdiobus_read(struct mii_bus *bus, int addr, u32 regnum);
int __mdiobus_write(struct mii_bus *bus, int addr, u32 regnum, u16 val);
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 0/4] net: phy: add and use genphy_c45_an_config_an
From: Heiner Kallweit @ 2019-02-16 19:49 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
This series adds genphy_c45_an_config_an() and uses it in the
marvell10g diver. In addition patch 4 aligns the aneg configuration
with what is done in genphy_config_aneg().
Heiner Kallweit (4):
net: phy: add helper linkmode_adv_to_mii_10gbt_adv_t
net: phy: add genphy_c45_an_config_an
net: phy: marvell10g: use genphy_c45_an_config_an
net: phy: marvell10g: check for newly set aneg in mv3310_config_aneg
drivers/net/phy/marvell10g.c | 28 ++++++++---------------
drivers/net/phy/phy-c45.c | 44 ++++++++++++++++++++++++++++++++++++
include/linux/mdio.h | 25 ++++++++++++++++++++
include/linux/phy.h | 1 +
4 files changed, 79 insertions(+), 19 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH v2 net-next 2/2] net: phy: marvell10g: improve mv3310_config_aneg
From: Heiner Kallweit @ 2019-02-16 19:44 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <c029e3b6-5fbe-08fb-a012-90ceef3be100@gmail.com>
Now that genphy_c45_pma_setup_forced() makes sure the "aneg enabled"
bit is cleared, the call to genphy_c45_an_disable_aneg() isn't needed
any longer. And the code pattern is now the same as in
genphy_config_aneg().
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/marvell10g.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 496805c0d..4a6ae63ab 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -271,13 +271,8 @@ static int mv3310_config_aneg(struct phy_device *phydev)
/* We don't support manual MDI control */
phydev->mdix_ctrl = ETH_TP_MDI_AUTO;
- if (phydev->autoneg == AUTONEG_DISABLE) {
- ret = genphy_c45_pma_setup_forced(phydev);
- if (ret < 0)
- return ret;
-
- return genphy_c45_an_disable_aneg(phydev);
- }
+ if (phydev->autoneg == AUTONEG_DISABLE)
+ return genphy_c45_pma_setup_forced(phydev);
linkmode_and(phydev->advertising, phydev->advertising,
phydev->supported);
--
2.20.1
^ permalink raw reply related
* [PATCH v2 net-next 1/2] net: phy: disable aneg in genphy_c45_pma_setup_forced
From: Heiner Kallweit @ 2019-02-16 19:44 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <c029e3b6-5fbe-08fb-a012-90ceef3be100@gmail.com>
When genphy_c45_pma_setup_forced() is called the "aneg enabled" bit may
still be set, therefore clear it. This is also in line with what
genphy_setup_forced() does for Clause 22.
v2:
- fix typo
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy-c45.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
index bef126344..98a04d4cd 100644
--- a/drivers/net/phy/phy-c45.c
+++ b/drivers/net/phy/phy-c45.c
@@ -70,7 +70,11 @@ int genphy_c45_pma_setup_forced(struct phy_device *phydev)
if (ret < 0)
return ret;
- return phy_write_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_CTRL2, ctrl2);
+ ret = phy_write_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_CTRL2, ctrl2);
+ if (ret < 0)
+ return ret;
+
+ return genphy_c45_an_disable_aneg(phydev);
}
EXPORT_SYMBOL_GPL(genphy_c45_pma_setup_forced);
--
2.20.1
^ permalink raw reply related
* [PATCH v2 net-next 0/2] net: phy: disable aneg in genphy_c45_pma_setup_forced
From: Heiner Kallweit @ 2019-02-16 19:39 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
When genphy_c45_pma_setup_forced() is called the "aneg enabled" bit
may still be set, therefore clear it. This is also in line with what
genphy_setup_forced() does for Clause 22.
v2:
- fix a typo in patch 1
Heiner Kallweit (2):
net: phy: disable aneg in genphy_c45_pma_setup_forced
net: phy: marvell10g: improve mv3310_config_aneg
drivers/net/phy/marvell10g.c | 9 ++-------
drivers/net/phy/phy-c45.c | 4 ++++
2 files changed, 6 insertions(+), 7 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: phy: disable aneg in genphy_c45_pma_setup_forced
From: Heiner Kallweit @ 2019-02-16 19:39 UTC (permalink / raw)
To: Stefano Brivio
Cc: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux, netdev@vger.kernel.org
In-Reply-To: <20190216203120.06923d0c@redhat.com>
On 16.02.2019 20:31, Stefano Brivio wrote:
> Hi,
>
> On Sat, 16 Feb 2019 20:10:24 +0100
> Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
>> When genphy_c45_pma_setup_forced() is called the "aneg enabled" bit may
>> still be set, therefore clear it. This is also in line with what
>> genphy_setup_forced() does for Clause 22.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> ---
>> drivers/net/phy/phy-c45.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
>> index bef126344..0374c50b1 100644
>> --- a/drivers/net/phy/phy-c45.c
>> +++ b/drivers/net/phy/phy-c45.c
>> @@ -71,6 +71,10 @@ int genphy_c45_pma_setup_forced(struct phy_device *phydev)
>> return ret;
>>
>> return phy_write_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_CTRL2, ctrl2);
>> + if (ret < 0)
>
> Perhaps you meant ret = phy_write_mmd(...)?
>
Ups, for sure I meant this. Strange that the compiler doesn't complain.
>> + return ret;
>> +
>> + return genphy_c45_an_disable_aneg(phydev);
>> }
>> EXPORT_SYMBOL_GPL(genphy_c45_pma_setup_forced);
>>
>
Heiner
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: phy: disable aneg in genphy_c45_pma_setup_forced
From: Stefano Brivio @ 2019-02-16 19:31 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux, netdev@vger.kernel.org
In-Reply-To: <27bb134f-eb4e-e43a-5d9d-2c551a22428c@gmail.com>
Hi,
On Sat, 16 Feb 2019 20:10:24 +0100
Heiner Kallweit <hkallweit1@gmail.com> wrote:
> When genphy_c45_pma_setup_forced() is called the "aneg enabled" bit may
> still be set, therefore clear it. This is also in line with what
> genphy_setup_forced() does for Clause 22.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> drivers/net/phy/phy-c45.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
> index bef126344..0374c50b1 100644
> --- a/drivers/net/phy/phy-c45.c
> +++ b/drivers/net/phy/phy-c45.c
> @@ -71,6 +71,10 @@ int genphy_c45_pma_setup_forced(struct phy_device *phydev)
> return ret;
>
> return phy_write_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_CTRL2, ctrl2);
> + if (ret < 0)
Perhaps you meant ret = phy_write_mmd(...)?
> + return ret;
> +
> + return genphy_c45_an_disable_aneg(phydev);
> }
> EXPORT_SYMBOL_GPL(genphy_c45_pma_setup_forced);
>
--
Stefano
^ permalink raw reply
* Re: [PATCH RFC] net: bridge: don't flood known multicast traffic when snooping is enabled
From: nikolay @ 2019-02-16 19:27 UTC (permalink / raw)
To: Ido Schimmel
Cc: Linus Lüssing, netdev, roopa, wkok, anuradhak, bridge, davem,
stephen
In-Reply-To: <0FE44F84-AD68-4FC0-8FEB-D033CF6159D2@cumulusnetworks.com>
On 16 February 2019 21:15:21 EET, nikolay@cumulusnetworks.com wrote:
>On 16 February 2019 20:43:53 EET, Ido Schimmel <idosch@idosch.org>
>wrote:
>>On Sat, Feb 16, 2019 at 10:05:40AM +0200, Nikolay Aleksandrov wrote:
>>> On 15/02/2019 19:13, Linus Lüssing wrote:
>>> > On Fri, Feb 15, 2019 at 03:04:27PM +0200, Nikolay Aleksandrov
>>wrote:
>>> >> Every user would expect to have traffic forwarded only to the
>>configured
>>> >> mdb destination when snooping is enabled, instead now to get that
>>one
>>> >> needs to enable both snooping and querier. Enabling querier on
>all
>>> >> switches could be problematic and is not a good solution,
>>> >
>>> > There is no need to set the querier on all snooping switches.
>>> > br_multicast_querier_exists() checks if a querier exists on the
>>> > link in general, not if this particular host/bridge is a querier.
>>> >
>>>
>>> We need a generic solution for the case of existing mdst and no
>>querier.
>>> More below.
>>>
>>> >
>>> >> for example as summarized by our multicast experts:
>>> >> "every switch would send an IGMP query
>>> >
>>> > What? RFC3810, section 7.1 says:
>>> >
>>> > "If it is the case, a querier election mechanism (described in
>>> > section 7.6.2) is used to elect a single multicast router to be
>>> > in Querier state. [...] Nevertheless, it is only the [elected]
>>Querier
>>> > that sends periodical or triggered query messages on the subnet."
>>> > >> for any random multicast traffic it
>>> >> received across the entire domain and it would send it forever as
>>long as a
>>> >> host exists wanting that stream even if it has no
>>downstream/directly
>>> >> connected receivers"
>>> >
>>>
>>> This was taken out of context and it's my bad, I think everyone is
>>aware
>>> of the election process, please nevermind the above statement.
>>>
>>> [snip]>
>>> >
>>> > Have you done some tests with this change yet, Nikolay?
>>> >
>>>
>>> You've raised good questions, IPv6 indeed needs more work - we'll
>>have to flood
>>> link-local packets etc. but I wanted to have a discussion about no
>>querier/existing mdst.
>>> To simplify we can modify the patch and have traffic forwarded to
>the
>>proper ports when an
>>> mdst exists and there is no querier for both unsolicited report and
>>user-added entry.
>>> We can keep the current behaviour for unknown traffic with and
>>without querier.
>>> This would align it closer to what other vendors currently do as
>well
>>IIRC.
>>> What do you think ?
>>
>>The no querier condition is not currently reflected via switchdev, so
>>the behavior you're proposing in your patch is what actually happens
>in
>>the data plane.
>>
>>We already hit the problem Linus mentioned in commit b00589af3b04
>>("bridge: disable snooping if there is no querier"). Namely, IPv6 ND
>>broke because a port joined before the bridge was created.
>>
>>I introduced a workaround in commit 9d45deb04c59 ("mlxsw: spectrum:
>>Treat IPv6 unregistered multicast as broadcast"). I'm interested to
>>know
>>what other vendors are doing. Can you elaborate?
>>
>
>Exactly like your fix. :) Flood it, this patch unfortunately breaks it
>because of mrouters flag, but we can retain the behaviour
>by forwarding only known mdsts to their ports and flooding
>unregistered mcast when there is no querier. I think that is
>what others do by default too, actually I think they flood with querier
>as well. Maybe unknown mcast flooding should be controlled by a flag
>when a querier is present
>because we've had this behaviour for a long time, personally I'd have
>it on
>by default.
Ugh, mispoke please read the above statement to be only about no querier.
I meant flooding v6 link-local always.
>I am currently away and will be able to prepare a rfc patch after the
>weekend.
>
>
>>We can trap IPv6 ND packets at L2 (we'll eventually need to do for ND
>>suppression) and let the bridge take care of flooding them correctly.
>>I'm not sure it's good enough.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: [PATCH RFC] net: bridge: don't flood known multicast traffic when snooping is enabled
From: nikolay @ 2019-02-16 19:15 UTC (permalink / raw)
To: Ido Schimmel
Cc: Linus Lüssing, netdev, roopa, wkok, anuradhak, bridge, davem,
stephen
In-Reply-To: <20190216184353.GA10888@splinter>
On 16 February 2019 20:43:53 EET, Ido Schimmel <idosch@idosch.org> wrote:
>On Sat, Feb 16, 2019 at 10:05:40AM +0200, Nikolay Aleksandrov wrote:
>> On 15/02/2019 19:13, Linus Lüssing wrote:
>> > On Fri, Feb 15, 2019 at 03:04:27PM +0200, Nikolay Aleksandrov
>wrote:
>> >> Every user would expect to have traffic forwarded only to the
>configured
>> >> mdb destination when snooping is enabled, instead now to get that
>one
>> >> needs to enable both snooping and querier. Enabling querier on all
>> >> switches could be problematic and is not a good solution,
>> >
>> > There is no need to set the querier on all snooping switches.
>> > br_multicast_querier_exists() checks if a querier exists on the
>> > link in general, not if this particular host/bridge is a querier.
>> >
>>
>> We need a generic solution for the case of existing mdst and no
>querier.
>> More below.
>>
>> >
>> >> for example as summarized by our multicast experts:
>> >> "every switch would send an IGMP query
>> >
>> > What? RFC3810, section 7.1 says:
>> >
>> > "If it is the case, a querier election mechanism (described in
>> > section 7.6.2) is used to elect a single multicast router to be
>> > in Querier state. [...] Nevertheless, it is only the [elected]
>Querier
>> > that sends periodical or triggered query messages on the subnet."
>> > >> for any random multicast traffic it
>> >> received across the entire domain and it would send it forever as
>long as a
>> >> host exists wanting that stream even if it has no
>downstream/directly
>> >> connected receivers"
>> >
>>
>> This was taken out of context and it's my bad, I think everyone is
>aware
>> of the election process, please nevermind the above statement.
>>
>> [snip]>
>> >
>> > Have you done some tests with this change yet, Nikolay?
>> >
>>
>> You've raised good questions, IPv6 indeed needs more work - we'll
>have to flood
>> link-local packets etc. but I wanted to have a discussion about no
>querier/existing mdst.
>> To simplify we can modify the patch and have traffic forwarded to the
>proper ports when an
>> mdst exists and there is no querier for both unsolicited report and
>user-added entry.
>> We can keep the current behaviour for unknown traffic with and
>without querier.
>> This would align it closer to what other vendors currently do as well
>IIRC.
>> What do you think ?
>
>The no querier condition is not currently reflected via switchdev, so
>the behavior you're proposing in your patch is what actually happens in
>the data plane.
>
>We already hit the problem Linus mentioned in commit b00589af3b04
>("bridge: disable snooping if there is no querier"). Namely, IPv6 ND
>broke because a port joined before the bridge was created.
>
>I introduced a workaround in commit 9d45deb04c59 ("mlxsw: spectrum:
>Treat IPv6 unregistered multicast as broadcast"). I'm interested to
>know
>what other vendors are doing. Can you elaborate?
>
Exactly like your fix. :) Flood it, this patch unfortunately breaks it
because of mrouters flag, but we can retain the behaviour
by forwarding only known mdsts to their ports and flooding
unregistered mcast when there is no querier. I think that is
what others do by default too, actually I think they flood with querier as well. Maybe unknown mcast flooding should be controlled by a flag when a querier is present
because we've had this behaviour for a long time, personally I'd have it on
by default.
I am currently away and will be able to prepare a rfc patch after the weekend.
>We can trap IPv6 ND packets at L2 (we'll eventually need to do for ND
>suppression) and let the bridge take care of flooding them correctly.
>I'm not sure it's good enough.
^ permalink raw reply
* Re: [PATCH v2 1/2] Provide in-kernel headers for making it easy to extend the kernel
From: Manoj @ 2019-02-16 19:10 UTC (permalink / raw)
To: Joel Fernandes
Cc: Alexei Starovoitov, netdev, linux-kernel, Andrew Morton, ast,
atishp04, dancol, Dan Williams, gregkh, Jonathan Corbet,
karim.yaghmour, Kees Cook, kernel-team, linux-doc,
linux-kselftest, Manoj Rao, Masahiro Yamada, paulmck,
Peter Zijlstra (Intel), rdunlap, rostedt, Shuah Khan,
Thomas Gleixner, yhs
In-Reply-To: <20190215034720.GA230433@google.com>
Joel Fernandes writes:
> On Thu, Feb 14, 2019 at 07:19:29PM -0800, Alexei Starovoitov wrote:
>> On Mon, Feb 11, 2019 at 09:35:59AM -0500, Joel Fernandes (Google) wrote:
>> > Introduce in-kernel headers and other artifacts which are made available
>> > as an archive through proc (/proc/kheaders.txz file). This archive makes
>> > it possible to build kernel modules, run eBPF programs, and other
>> > tracing programs that need to extend the kernel for tracing purposes
>> > without any dependency on the file system having headers and build
>> > artifacts.
>> >
>> > On Android and embedded systems, it is common to switch kernels but not
>> > have kernel headers available on the file system. Raw kernel headers
>> > also cannot be copied into the filesystem like they can be on other
>> > distros, due to licensing and other issues. There's no linux-headers
>> > package on Android. Further once a different kernel is booted, any
>> > headers stored on the file system will no longer be useful. By storing
>> > the headers as a compressed archive within the kernel, we can avoid these
>> > issues that have been a hindrance for a long time.
>>
>> The set looks good to me and since the main use case is building bpf progs
>> I can route it via bpf-next tree if there are no objections.
>> Masahiro, could you please ack it?
>>
>
> Yes, eBPF is one of the usecases. After this, I am also planning to send
> patches to BCC so that it can use this feature when compiling C to eBPF.
>
Tested-by: Manoj Rao <linux@manojrajarao.com>
I think this can definitely make it easier to use eBPF on
Android. Thanks for initiating this.
> Thanks!
>
> - Joel
--
Manoj
http://www.mycpu.org
^ permalink raw reply
* [PATCH net-next 2/2] net: phy: marvell10g: improve mv3310_config_aneg
From: Heiner Kallweit @ 2019-02-16 19:11 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <8945c224-bfff-294d-f855-979016e077ec@gmail.com>
Now that genphy_c45_pma_setup_forced() makes sure the "aneg enabled"
bit is cleared, the call to genphy_c45_an_disable_aneg() isn't needed
any longer. And the code pattern is now the same as in
genphy_config_aneg().
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/marvell10g.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 496805c0d..4a6ae63ab 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -271,13 +271,8 @@ static int mv3310_config_aneg(struct phy_device *phydev)
/* We don't support manual MDI control */
phydev->mdix_ctrl = ETH_TP_MDI_AUTO;
- if (phydev->autoneg == AUTONEG_DISABLE) {
- ret = genphy_c45_pma_setup_forced(phydev);
- if (ret < 0)
- return ret;
-
- return genphy_c45_an_disable_aneg(phydev);
- }
+ if (phydev->autoneg == AUTONEG_DISABLE)
+ return genphy_c45_pma_setup_forced(phydev);
linkmode_and(phydev->advertising, phydev->advertising,
phydev->supported);
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 1/2] net: phy: disable aneg in genphy_c45_pma_setup_forced
From: Heiner Kallweit @ 2019-02-16 19:10 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <8945c224-bfff-294d-f855-979016e077ec@gmail.com>
When genphy_c45_pma_setup_forced() is called the "aneg enabled" bit may
still be set, therefore clear it. This is also in line with what
genphy_setup_forced() does for Clause 22.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy-c45.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
index bef126344..0374c50b1 100644
--- a/drivers/net/phy/phy-c45.c
+++ b/drivers/net/phy/phy-c45.c
@@ -71,6 +71,10 @@ int genphy_c45_pma_setup_forced(struct phy_device *phydev)
return ret;
return phy_write_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_CTRL2, ctrl2);
+ if (ret < 0)
+ return ret;
+
+ return genphy_c45_an_disable_aneg(phydev);
}
EXPORT_SYMBOL_GPL(genphy_c45_pma_setup_forced);
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 0/2] net: phy: disable aneg in genphy_c45_pma_setup_forced
From: Heiner Kallweit @ 2019-02-16 19:08 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
When genphy_c45_pma_setup_forced() is called the "aneg enabled" bit
may still be set, therefore clear it. This is also in line with what
genphy_setup_forced() does for Clause 22.
Heiner Kallweit (2):
net: phy: disable aneg in genphy_c45_pma_setup_forced
net: phy: marvell10g: improve mv3310_config_aneg
drivers/net/phy/marvell10g.c | 9 ++-------
drivers/net/phy/phy-c45.c | 4 ++++
2 files changed, 6 insertions(+), 7 deletions(-)
--
2.20.1
^ permalink raw reply
* [Patch net-next 2/2] net_sched: fix a memory leak in cls_tcindex
From: Cong Wang @ 2019-02-16 18:58 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, Jamal Hadi Salim, Jiri Pirko
In-Reply-To: <20190216185827.21535-1-xiyou.wangcong@gmail.com>
(cherry picked from commit 033b228e7f26b29ae37f8bfa1bc6b209a5365e9f)
When tcindex_destroy() destroys all the filter results in
the perfect hash table, it invokes the walker to delete
each of them. However, results with class==0 are skipped
in either tcindex_walk() or tcindex_delete(), which causes
a memory leak reported by kmemleak.
This patch fixes it by skipping the walker and directly
deleting these filter results so we don't miss any filter
result.
As a result of this change, we have to initialize exts->net
properly in tcindex_alloc_perfect_hash(). For net-next, we
need to consider whether we should initialize ->net in
tcf_exts_init() instead, before that just directly test
CONFIG_NET_CLS_ACT=y.
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/sched/cls_tcindex.c | 37 ++++++++++++++++++++++++-------------
1 file changed, 24 insertions(+), 13 deletions(-)
diff --git a/net/sched/cls_tcindex.c b/net/sched/cls_tcindex.c
index 81a433ae31b3..fbf3519a12d8 100644
--- a/net/sched/cls_tcindex.c
+++ b/net/sched/cls_tcindex.c
@@ -221,14 +221,6 @@ static int tcindex_delete(struct tcf_proto *tp, void *arg, bool *last,
return 0;
}
-static int tcindex_destroy_element(struct tcf_proto *tp,
- void *arg, struct tcf_walker *walker)
-{
- bool last;
-
- return tcindex_delete(tp, arg, &last, false, NULL);
-}
-
static void tcindex_destroy_work(struct work_struct *work)
{
struct tcindex_data *p = container_of(to_rcu_work(work),
@@ -568,13 +560,32 @@ static void tcindex_destroy(struct tcf_proto *tp, bool rtnl_held,
struct netlink_ext_ack *extack)
{
struct tcindex_data *p = rtnl_dereference(tp->root);
- struct tcf_walker walker;
+ int i;
pr_debug("tcindex_destroy(tp %p),p %p\n", tp, p);
- walker.count = 0;
- walker.skip = 0;
- walker.fn = tcindex_destroy_element;
- tcindex_walk(tp, &walker, true);
+
+ if (p->perfect) {
+ for (i = 0; i < p->hash; i++) {
+ struct tcindex_filter_result *r = p->perfect + i;
+
+ tcf_unbind_filter(tp, &r->res);
+ if (tcf_exts_get_net(&r->exts))
+ tcf_queue_work(&r->rwork,
+ tcindex_destroy_rexts_work);
+ else
+ __tcindex_destroy_rexts(r);
+ }
+ }
+
+ for (i = 0; p->h && i < p->hash; i++) {
+ struct tcindex_filter *f, *next;
+ bool last;
+
+ for (f = rtnl_dereference(p->h[i]); f; f = next) {
+ next = rtnl_dereference(f->next);
+ tcindex_delete(tp, &f->result, &last, rtnl_held, NULL);
+ }
+ }
tcf_queue_work(&p->rwork, tcindex_destroy_work);
}
--
2.20.1
^ permalink raw reply related
* [Patch net-next 1/2] net_sched: fix a race condition in tcindex_destroy()
From: Cong Wang @ 2019-02-16 18:58 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, Adrian, Ben Hutchings, Jamal Hadi Salim, Jiri Pirko
(cherry picked from commit 8015d93ebd27484418d4952284fd02172fa4b0b2)
tcindex_destroy() invokes tcindex_destroy_element() via
a walker to delete each filter result in its perfect hash
table, and tcindex_destroy_element() calls tcindex_delete()
which schedules tcf RCU works to do the final deletion work.
Unfortunately this races with the RCU callback
__tcindex_destroy(), which could lead to use-after-free as
reported by Adrian.
Fix this by migrating this RCU callback to tcf RCU work too,
as that workqueue is ordered, we will not have use-after-free.
Note, we don't need to hold netns refcnt because we don't call
tcf_exts_destroy() here.
Fixes: 27ce4f05e2ab ("net_sched: use tcf_queue_work() in tcindex filter")
Reported-by: Adrian <bugs@abtelecom.ro>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/sched/cls_tcindex.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/net/sched/cls_tcindex.c b/net/sched/cls_tcindex.c
index e1981628047b..81a433ae31b3 100644
--- a/net/sched/cls_tcindex.c
+++ b/net/sched/cls_tcindex.c
@@ -48,7 +48,7 @@ struct tcindex_data {
u32 hash; /* hash table size; 0 if undefined */
u32 alloc_hash; /* allocated size */
u32 fall_through; /* 0: only classify if explicit match */
- struct rcu_head rcu;
+ struct rcu_work rwork;
};
static inline int tcindex_filter_is_set(struct tcindex_filter_result *r)
@@ -229,9 +229,11 @@ static int tcindex_destroy_element(struct tcf_proto *tp,
return tcindex_delete(tp, arg, &last, false, NULL);
}
-static void __tcindex_destroy(struct rcu_head *head)
+static void tcindex_destroy_work(struct work_struct *work)
{
- struct tcindex_data *p = container_of(head, struct tcindex_data, rcu);
+ struct tcindex_data *p = container_of(to_rcu_work(work),
+ struct tcindex_data,
+ rwork);
kfree(p->perfect);
kfree(p->h);
@@ -258,9 +260,11 @@ static int tcindex_filter_result_init(struct tcindex_filter_result *r)
return tcf_exts_init(&r->exts, TCA_TCINDEX_ACT, TCA_TCINDEX_POLICE);
}
-static void __tcindex_partial_destroy(struct rcu_head *head)
+static void tcindex_partial_destroy_work(struct work_struct *work)
{
- struct tcindex_data *p = container_of(head, struct tcindex_data, rcu);
+ struct tcindex_data *p = container_of(to_rcu_work(work),
+ struct tcindex_data,
+ rwork);
kfree(p->perfect);
kfree(p);
@@ -480,7 +484,7 @@ tcindex_set_parms(struct net *net, struct tcf_proto *tp, unsigned long base,
}
if (oldp)
- call_rcu(&oldp->rcu, __tcindex_partial_destroy);
+ tcf_queue_work(&oldp->rwork, tcindex_partial_destroy_work);
return 0;
errout_alloc:
@@ -572,7 +576,7 @@ static void tcindex_destroy(struct tcf_proto *tp, bool rtnl_held,
walker.fn = tcindex_destroy_element;
tcindex_walk(tp, &walker, true);
- call_rcu(&p->rcu, __tcindex_destroy);
+ tcf_queue_work(&p->rwork, tcindex_destroy_work);
}
--
2.20.1
^ permalink raw reply related
* [ROSE] Bug : waiting for rose module to become free
From: f6bvp @ 2019-02-16 18:44 UTC (permalink / raw)
To: netdev, linux-hams; +Cc: dvyukov, richard, thomas, f6bvp
Hi,
A nastly bug is still pending in ROSE module that prevents it to be removed.
When trying to remove rose module we enter into an endless loop with displayed message :
"waiting for rose module to become free"
A patch from Richard Stern had been committed a while ago but it did not get a chance to be applied.
https://marc.info/?l=linux-hams&m=150870350516064&w=2
Since then, there have been some changes in af_rose.c and net code architecture that prevents simply adding missing dev_put(dev) in present kernel.
From time to time we can observe a negative count (-1 for integer value is displayed as 65535 in /proc/net/rose_neigh) that probably means there is a bug in rose module refcount (??).
/proc/net/rose_neigh
00015 SV1HCC-9 ax0 2 1 DCE yes 0 0
00013 PE1OWG-11 ax0 2 65535 DCE yes 0 0
00011 F5KTR-11 ax0 1 1 DCE yes 0 0
00007 F3KT-11 ax0 2 1 DCE yes 0 0
00003 SK7ES-9 ax0 2 1 DTE yes 0 0
00002 K4GBB-9 ax0 4 0 DCE yes 0 0
00001 RSLOOP-0 ??? 1 2 DCE yes 0 0
Help is kindly requested to get a valid patch.
Bernard,
f6bvp
^ permalink raw reply
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