* Re: [PATCH] net: add a synchronize_net() in netdev_rx_handler_unregister()
From: Jiri Pirko @ 2013-03-29 16:12 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ivan Vecera, Jiri Pirko, Steven Rostedt, Andy Gospodarek,
David S. Miller, LKML, netdev, Nicolas de Pesloüan,
Thomas Gleixner, Guy Streeter, Paul E. McKenney, stephen
In-Reply-To: <1364571495.5113.23.camel@edumazet-glaptop>
Fri, Mar 29, 2013 at 04:38:15PM CET, eric.dumazet@gmail.com wrote:
>On Fri, 2013-03-29 at 16:11 +0100, Ivan Vecera wrote:
>
>> Erik, why doesn't help the write barrier between the assignments. It
>> should guarantee their orders... or not?
>>
>
>Its not enough, I wont explain here why as RCU is quite well documented
>in Documentation/RCU
Can you point me exact paragraph? I'm unable to find that :(
>
>
>
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: add a synchronize_net() in netdev_rx_handler_unregister()
From: Eric Dumazet @ 2013-03-29 16:46 UTC (permalink / raw)
To: Jiri Pirko
Cc: Ivan Vecera, Jiri Pirko, Steven Rostedt, Andy Gospodarek,
David S. Miller, LKML, netdev, Nicolas de Pesloüan,
Thomas Gleixner, Guy Streeter, Paul E. McKenney, stephen
In-Reply-To: <20130329161219.GA1668@minipsycho.orion>
On Fri, 2013-03-29 at 17:12 +0100, Jiri Pirko wrote:
> Fri, Mar 29, 2013 at 04:38:15PM CET, eric.dumazet@gmail.com wrote:
> >On Fri, 2013-03-29 at 16:11 +0100, Ivan Vecera wrote:
> >
> >> Erik, why doesn't help the write barrier between the assignments. It
> >> should guarantee their orders... or not?
> >>
> >
> >Its not enough, I wont explain here why as RCU is quite well documented
> >in Documentation/RCU
>
> Can you point me exact paragraph? I'm unable to find that :(
>
You need a bit of RCU history to understand the issue
rcu_assign_pointer(dev->rx_handler, NULL) is certainly not needing a
barrier _before_ setting rx_handler to NULL.
Old kernels had this rcu_assign_pointer() implementation since
commit d99c4f6b13b3149bc83703ab1493beaeaaaf8a2d
(Remove rcu_assign_pointer() penalty for NULL pointers)
#define rcu_assign_pointer(p, v) \
({ \
if (!__builtin_constant_p(v) || \
((v) != NULL)) \
smp_wmb(); \
(p) = (v); \
})
Note that wmb() was _not_ done if v was NULL
Because of various sparse issues, commit
d322f45ceed525daa9401154590bbae3222cfefb
(rcu: Make rcu_assign_pointer() unconditionally insert a memory barrier)
removed the conditional, because RCU_INIT_POINTER() was available.
In the rx_handler/rx_handler_data, we use two pointers protected by RCU,
but we want to only test rx_hander being NULL, and avoid testing
rx_handler_data.
Nothing in RCU guarantees that two different pointers have any order.
Here is what could happen
CPU0 CPU1
handler = rcu_dereference(dev->rx_handler)
if (handler) {
handler(dev, ...);
dev->rx_handler = NULL;
smp_wmb(); // OR NOT
dev->rx_handler_data = NULL;
smp_wmb(); // OR NOT
handler(dev)
priv_data = rcu_dereference(dev->rx_handler_data);
x = priv_data->some_field; // CRASH because priv_data is NULL
^ permalink raw reply
* Re: [PATCH] of_mdio: Remove flags argument from of_phy_connect
From: Florian Fainelli @ 2013-03-29 17:45 UTC (permalink / raw)
To: Ben Collins
Cc: linux-kernel, Grant Likely, Rob Herring, devicetree-discuss,
netdev@vger.kernel.org
In-Reply-To: <E1UJ1fR-0004hv-8a@swissweb.swissdisk.com>
Le 03/19/13 00:49, Ben Collins a écrit :
> of_phy_connect() only required a flags argument in order to pass it down to
> to phy_connect(). Since that argument was removed, it is of no use in this
> function either (confirmed by checking all callers in kernel tree as well).
Looks good to me:
Reviewed-by: Florian Fainelli <florian@openwrt.org>
(you should have CC'd netdev@vger.kernel.org as it is probably going to
get merged via the net tree)
>
> Signed-off-by: Ben Collins <ben.c@servergy.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: devicetree-discuss@lists.ozlabs.org
> ---
> drivers/net/ethernet/freescale/fec_mpc52xx.c | 2 +-
> drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 2 +-
> drivers/net/ethernet/freescale/gianfar.c | 2 +-
> drivers/net/ethernet/freescale/ucc_geth.c | 2 +-
> drivers/net/ethernet/marvell/mvneta.c | 2 +-
> drivers/net/ethernet/octeon/octeon_mgmt.c | 2 +-
> drivers/net/ethernet/pasemi/pasemi_mac.c | 2 +-
> drivers/net/ethernet/xilinx/ll_temac_main.c | 2 +-
> drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +-
> drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 +-
> drivers/of/of_mdio.c | 2 +-
> drivers/staging/octeon/ethernet-mdio.c | 2 +-
> include/linux/of_mdio.h | 4 ++--
> 13 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_mpc52xx.c b/drivers/net/ethernet/freescale/fec_mpc52xx.c
> index 77943a6..ea01dcd 100644
> --- a/drivers/net/ethernet/freescale/fec_mpc52xx.c
> +++ b/drivers/net/ethernet/freescale/fec_mpc52xx.c
> @@ -217,7 +217,7 @@ static int mpc52xx_fec_open(struct net_device *dev)
>
> if (priv->phy_node) {
> priv->phydev = of_phy_connect(priv->ndev, priv->phy_node,
> - mpc52xx_fec_adjust_link, 0, 0);
> + mpc52xx_fec_adjust_link, 0);
> if (!priv->phydev) {
> dev_err(&dev->dev, "of_phy_connect failed\n");
> return -ENODEV;
> diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> index 46df288..5523fc0 100644
> --- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> +++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> @@ -799,7 +799,7 @@ static int fs_init_phy(struct net_device *dev)
> iface = fep->fpi->use_rmii ?
> PHY_INTERFACE_MODE_RMII : PHY_INTERFACE_MODE_MII;
>
> - phydev = of_phy_connect(dev, fep->fpi->phy_node, &fs_adjust_link, 0,
> + phydev = of_phy_connect(dev, fep->fpi->phy_node, &fs_adjust_link,
> iface);
> if (!phydev) {
> phydev = of_phy_connect_fixed_link(dev, &fs_adjust_link,
> diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
> index d2c5441..383d302 100644
> --- a/drivers/net/ethernet/freescale/gianfar.c
> +++ b/drivers/net/ethernet/freescale/gianfar.c
> @@ -1467,7 +1467,7 @@ static int init_phy(struct net_device *dev)
>
> interface = gfar_get_interface(dev);
>
> - priv->phydev = of_phy_connect(dev, priv->phy_node, &adjust_link, 0,
> + priv->phydev = of_phy_connect(dev, priv->phy_node, &adjust_link,
> interface);
> if (!priv->phydev)
> priv->phydev = of_phy_connect_fixed_link(dev, &adjust_link,
> diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
> index 0a70bb5..fb9a573 100644
> --- a/drivers/net/ethernet/freescale/ucc_geth.c
> +++ b/drivers/net/ethernet/freescale/ucc_geth.c
> @@ -1745,7 +1745,7 @@ static int init_phy(struct net_device *dev)
> priv->oldspeed = 0;
> priv->oldduplex = -1;
>
> - phydev = of_phy_connect(dev, ug_info->phy_node, &adjust_link, 0,
> + phydev = of_phy_connect(dev, ug_info->phy_node, &adjust_link,
> priv->phy_interface);
> if (!phydev)
> phydev = of_phy_connect_fixed_link(dev, &adjust_link,
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index cd345b8..dcb865e8 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -2344,7 +2344,7 @@ static int mvneta_mdio_probe(struct mvneta_port *pp)
> {
> struct phy_device *phy_dev;
>
> - phy_dev = of_phy_connect(pp->dev, pp->phy_node, mvneta_adjust_link, 0,
> + phy_dev = of_phy_connect(pp->dev, pp->phy_node, mvneta_adjust_link,
> pp->phy_interface);
> if (!phy_dev) {
> netdev_err(pp->dev, "could not find the PHY\n");
> diff --git a/drivers/net/ethernet/octeon/octeon_mgmt.c b/drivers/net/ethernet/octeon/octeon_mgmt.c
> index 921729f..c2d281e 100644
> --- a/drivers/net/ethernet/octeon/octeon_mgmt.c
> +++ b/drivers/net/ethernet/octeon/octeon_mgmt.c
> @@ -970,7 +970,7 @@ static int octeon_mgmt_init_phy(struct net_device *netdev)
> }
>
> p->phydev = of_phy_connect(netdev, p->phy_np,
> - octeon_mgmt_adjust_link, 0,
> + octeon_mgmt_adjust_link,
> PHY_INTERFACE_MODE_MII);
>
> if (!p->phydev)
> diff --git a/drivers/net/ethernet/pasemi/pasemi_mac.c b/drivers/net/ethernet/pasemi/pasemi_mac.c
> index b1cfbb7..aad29d1 100644
> --- a/drivers/net/ethernet/pasemi/pasemi_mac.c
> +++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
> @@ -1100,7 +1100,7 @@ static int pasemi_mac_phy_init(struct net_device *dev)
> mac->speed = 0;
> mac->duplex = -1;
>
> - phydev = of_phy_connect(dev, phy_dn, &pasemi_adjust_link, 0,
> + phydev = of_phy_connect(dev, phy_dn, &pasemi_adjust_link,
> PHY_INTERFACE_MODE_SGMII);
>
> if (!phydev) {
> diff --git a/drivers/net/ethernet/xilinx/ll_temac_main.c b/drivers/net/ethernet/xilinx/ll_temac_main.c
> index 9fc2ada..4c5e0a9 100644
> --- a/drivers/net/ethernet/xilinx/ll_temac_main.c
> +++ b/drivers/net/ethernet/xilinx/ll_temac_main.c
> @@ -857,7 +857,7 @@ static int temac_open(struct net_device *ndev)
>
> if (lp->phy_node) {
> lp->phy_dev = of_phy_connect(lp->ndev, lp->phy_node,
> - temac_adjust_link, 0, 0);
> + temac_adjust_link, 0);
> if (!lp->phy_dev) {
> dev_err(lp->dev, "of_phy_connect() failed\n");
> return -ENODEV;
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index 278c9db..7f2afdd 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -935,7 +935,7 @@ static int axienet_open(struct net_device *ndev)
>
> if (lp->phy_node) {
> lp->phy_dev = of_phy_connect(lp->ndev, lp->phy_node,
> - axienet_adjust_link, 0,
> + axienet_adjust_link,
> PHY_INTERFACE_MODE_GMII);
> if (!lp->phy_dev) {
> dev_err(lp->dev, "of_phy_connect() failed\n");
> diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> index 919b983..bccb064 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> @@ -931,7 +931,7 @@ static int xemaclite_open(struct net_device *dev)
> u32 bmcr;
>
> lp->phy_dev = of_phy_connect(lp->ndev, lp->phy_node,
> - xemaclite_adjust_link, 0,
> + xemaclite_adjust_link,
> PHY_INTERFACE_MODE_MII);
> if (!lp->phy_dev) {
> dev_err(&lp->ndev->dev, "of_phy_connect() failed\n");
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index e3a8b22..199b7f2 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -149,7 +149,7 @@ EXPORT_SYMBOL(of_phy_find_device);
> */
> struct phy_device *of_phy_connect(struct net_device *dev,
> struct device_node *phy_np,
> - void (*hndlr)(struct net_device *), u32 flags,
> + void (*hndlr)(struct net_device *),
> phy_interface_t iface)
> {
> struct phy_device *phy = of_phy_find_device(phy_np);
> diff --git a/drivers/staging/octeon/ethernet-mdio.c b/drivers/staging/octeon/ethernet-mdio.c
> index 83b1030..37897e3 100644
> --- a/drivers/staging/octeon/ethernet-mdio.c
> +++ b/drivers/staging/octeon/ethernet-mdio.c
> @@ -171,7 +171,7 @@ int cvm_oct_phy_setup_device(struct net_device *dev)
> if (!phy_node)
> return 0;
>
> - priv->phydev = of_phy_connect(dev, phy_node, cvm_oct_adjust_link, 0,
> + priv->phydev = of_phy_connect(dev, phy_node, cvm_oct_adjust_link,
> PHY_INTERFACE_MODE_GMII);
>
> if (priv->phydev == NULL)
> diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
> index 8163107..cdc62c9 100644
> --- a/include/linux/of_mdio.h
> +++ b/include/linux/of_mdio.h
> @@ -18,7 +18,7 @@ extern struct phy_device *of_phy_find_device(struct device_node *phy_np);
> extern struct phy_device *of_phy_connect(struct net_device *dev,
> struct device_node *phy_np,
> void (*hndlr)(struct net_device *),
> - u32 flags, phy_interface_t iface);
> + phy_interface_t iface);
> extern struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
> void (*hndlr)(struct net_device *),
> phy_interface_t iface);
> @@ -39,7 +39,7 @@ static inline struct phy_device *of_phy_find_device(struct device_node *phy_np)
> static inline struct phy_device *of_phy_connect(struct net_device *dev,
> struct device_node *phy_np,
> void (*hndlr)(struct net_device *),
> - u32 flags, phy_interface_t iface)
> + phy_interface_t iface)
> {
> return NULL;
> }
>
^ permalink raw reply
* [PATCH 0/4] mv643xx_eth device tree bindings
From: Florian Fainelli @ 2013-03-29 18:14 UTC (permalink / raw)
To: davem
Cc: netdev, linux-arm-kernel, devicetree-discuss, thomas.petazzoni,
jm, moinejf, sebastian.hesselbarth, buytenh, andrew, jason,
grant.likely, rob.herring, Florian Fainelli
Hi all,
This patch serie implements mv643xx_eth device tree bindings. I opted for
the reuse of the bindings already defined in
Documentation/devicetree/bindings/marvell.txt so that we do not create
any confusion.
For reference, I have included the mv643xx-eth related nodes in the
corresponding Kirkwood, Dove and Orion5x .dtsi files so you can more
easily test on your own platforms.
I tested these on a custom 88F6181-based boards, but I would appreciate
more testing.
Thanks!
Florian Fainelli (4):
mv643xx_eth: add Device Tree bindings
ARM: kirkwood: add device node entries for the gigabit interfaces
ARM: orion5x: add gigabit ethernet device tree node
ARM: dove: add gigabit device tree nodes to dove.dtsi
Documentation/devicetree/bindings/marvell.txt | 21 ++++-
arch/arm/boot/dts/dove.dtsi | 25 ++++++
arch/arm/boot/dts/kirkwood.dtsi | 46 ++++++++++
arch/arm/boot/dts/orion5x.dtsi | 23 +++++
arch/arm/mach-kirkwood/common.c | 4 +-
drivers/net/ethernet/marvell/mv643xx_eth.c | 114 ++++++++++++++++++++++++-
6 files changed, 226 insertions(+), 7 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH 4/4] ARM: dove: add gigabit device tree nodes to dove.dtsi
From: Florian Fainelli @ 2013-03-29 18:14 UTC (permalink / raw)
To: davem
Cc: netdev, linux-arm-kernel, devicetree-discuss, thomas.petazzoni,
jm, moinejf, sebastian.hesselbarth, buytenh, andrew, jason,
grant.likely, rob.herring, Florian Fainelli
In-Reply-To: <1364580879-4297-1-git-send-email-florian@openwrt.org>
This patch adds the gigabit ethernet device tree nodes to dove.dtsi in a
disabled state. The gigabit ethernet device tree node must be enabled on
a per-board basis. For completeness and easier testing the MDIO node is
also added in a disabled state.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
arch/arm/boot/dts/dove.dtsi | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index f7509ca..8a24d6b 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -253,5 +253,30 @@
dmacap,xor;
};
};
+
+ mdio@72004 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,orion-mdio";
+ reg = <0x72004 0x84>;
+ status = "disabled";
+ };
+
+ ethernet-group@70000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,mv643xx-eth-block";
+ reg = <0x70000 0x4000>;
+ tx-csum-limit = <1600>;
+ status = "disabled";
+
+ egiga0: ethernet@0 {
+ device_type = "network";
+ compatible = "marvell,mv643xx-eth";
+ reg = <0>;
+ interrupts = <29>;
+ clocks = <&gate_clk 2>;
+ };
+ };
};
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/4] ARM: kirkwood: add device node entries for the gigabit interfaces
From: Florian Fainelli @ 2013-03-29 18:14 UTC (permalink / raw)
To: davem
Cc: netdev, linux-arm-kernel, devicetree-discuss, thomas.petazzoni,
jm, moinejf, sebastian.hesselbarth, buytenh, andrew, jason,
grant.likely, rob.herring, Florian Fainelli
In-Reply-To: <1364580879-4297-1-git-send-email-florian@openwrt.org>
This patch modifies kirkwood.dtsi to specify the various gigabit
interfaces nodes available on kirkwood devices. They are disabled by
default and should be enabled on a per-board basis. egiga0 and egiga1
aliases are defined for convenience. The mdio node is also present and
should be enabled on a per-board basis as well.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
arch/arm/boot/dts/kirkwood.dtsi | 46 +++++++++++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/common.c | 4 ++--
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
index fada7e6..e0860f8 100644
--- a/arch/arm/boot/dts/kirkwood.dtsi
+++ b/arch/arm/boot/dts/kirkwood.dtsi
@@ -7,6 +7,8 @@
aliases {
gpio0 = &gpio0;
gpio1 = &gpio1;
+ egiga0 = &egiga0;
+ egiga1 = &egiga1;
};
intc: interrupt-controller {
compatible = "marvell,orion-intc", "marvell,intc";
@@ -202,5 +204,49 @@
clocks = <&gate_clk 4>;
status = "disabled";
};
+
+ mdio@72004 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,orion-mdio";
+ reg = <0x72004 0x84>;
+ status = "disabled";
+ };
+
+ ethernet-group@70000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,mv643xx-eth-block";
+ reg = <0x70000 0x4000>;
+ tx-csum-limit = <1600>;
+ status = "disabled";
+
+ egiga0: egiga0@0 {
+ device_type = "network";
+ compatible = "marvell,mv643xx-eth";
+ reg = <0>;
+ interrupts = <11>;
+ clocks = <&gate_clk 0>;
+ clock-names = "0";
+ };
+ };
+
+ ethernet-group@74000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,mv643xx-eth-block";
+ reg = <0x74000 0x4000>;
+ tx-csum-limit = <1600>;
+ status = "disabled";
+
+ egiga1: egiga1@0 {
+ device_type = "network";
+ compatible = "marvell,mv643xx-eth";
+ reg = <0>;
+ interrupts = <15>;
+ clocks = <&gate_clk 19>;
+ clock-names = "1";
+ };
+ };
};
};
diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index 49792a0..a606f9f 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -251,8 +251,8 @@ void __init kirkwood_clk_init(void)
/* clkdev entries, mapping clks to devices */
orion_clkdev_add(NULL, "orion_spi.0", runit);
orion_clkdev_add(NULL, "orion_spi.1", runit);
- orion_clkdev_add(NULL, MV643XX_ETH_NAME ".0", ge0);
- orion_clkdev_add(NULL, MV643XX_ETH_NAME ".1", ge1);
+ orion_clkdev_add("0", MV643XX_ETH_NAME ".0", ge0);
+ orion_clkdev_add("1", MV643XX_ETH_NAME ".1", ge1);
orion_clkdev_add(NULL, "orion_wdt", tclk);
orion_clkdev_add("0", "sata_mv.0", sata0);
orion_clkdev_add("1", "sata_mv.0", sata1);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/4] mv643xx_eth: add Device Tree bindings
From: Florian Fainelli @ 2013-03-29 18:14 UTC (permalink / raw)
To: davem
Cc: netdev, linux-arm-kernel, devicetree-discuss, thomas.petazzoni,
jm, moinejf, sebastian.hesselbarth, buytenh, andrew, jason,
grant.likely, rob.herring, Florian Fainelli
In-Reply-To: <1364580879-4297-1-git-send-email-florian@openwrt.org>
This patch adds Device Tree bindings following the already defined
bindings at Documentation/devicetree/bindings/marvell.txt. The binding
documentation is also enhanced with new optionnal properties required
for supporting certain devices (RX/TX queue and SRAM). Since we now have
proper support for the orion MDIO bus driver, there is no need to fiddle
around with device tree phandles.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
Documentation/devicetree/bindings/marvell.txt | 21 ++++-
drivers/net/ethernet/marvell/mv643xx_eth.c | 114 ++++++++++++++++++++++++-
2 files changed, 130 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/marvell.txt b/Documentation/devicetree/bindings/marvell.txt
index f1533d9..fd05016 100644
--- a/Documentation/devicetree/bindings/marvell.txt
+++ b/Documentation/devicetree/bindings/marvell.txt
@@ -112,9 +112,14 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
Required properties:
- #address-cells : <1>
- #size-cells : <0>
- - compatible : "marvell,mv64360-eth-block"
+ - compatible : "marvell,mv64360-eth-block", "marvell,mv64360-eth-group",
+ "marvell,mv643xx-eth-block"
- reg : Offset and length of the register set for this block
+ Optional properties:
+ - tx-csum-limit : Hardware limit above which transmit checksumming
+ is disabled.
+
Example Discovery Ethernet block node:
ethernet-block@2000 {
#address-cells = <1>;
@@ -130,7 +135,7 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
Required properties:
- device_type : Should be "network".
- - compatible : Should be "marvell,mv64360-eth".
+ - compatible : Should be "marvell,mv64360-eth", "marvell,mv643xx-eth".
- reg : Should be <0>, <1>, or <2>, according to which registers
within the silicon block the device uses.
- interrupts : <a> where a is the interrupt number for the port.
@@ -140,6 +145,18 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
controller.
- local-mac-address : 6 bytes, MAC address
+ Optional properties:
+ - clocks : Phandle to the clock control device and gate bit
+ - clock-names : String describing the clock gate bit
+ - rx-queue-count : number of RX queues to use
+ - tx-queue-count : number of TX queues to use
+ - rx-queue-size : size of the RX queue (in bytes)
+ - tx-queue-size : size of the TX queue (in bytes)
+ - rx-sram-addr : address of the SRAM for RX path (non 0 means used)
+ - rx-sram-size : size of the SRAM for RX path (non 0 means used)
+ - tx-sram-addr : address of the SRAM for TX path (non 0 means used)
+ - tx-sram-size : size of the SRAM for TX path (non 0 means used)
+
Example Discovery Ethernet port node:
ethernet@0 {
device_type = "network";
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index aedbd82..57164cb 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -60,6 +60,10 @@
#include <linux/inet_lro.h>
#include <linux/slab.h>
#include <linux/clk.h>
+#include <linux/stringify.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/of_net.h>
static char mv643xx_eth_driver_name[] = "mv643xx_eth";
static char mv643xx_eth_driver_version[] = "1.4";
@@ -2542,14 +2546,24 @@ static void infer_hw_params(struct mv643xx_eth_shared_private *msp)
}
}
+static const struct of_device_id mv643xx_eth_match[] = {
+ { .compatible = "marvell,mv64360-eth" },
+ { .compatible = "marvell,mv643xx-eth" },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mv643xx_eth_match);
+
static int mv643xx_eth_shared_probe(struct platform_device *pdev)
{
static int mv643xx_eth_version_printed;
+ struct device_node *np = pdev->dev.of_node;
struct mv643xx_eth_shared_platform_data *pd = pdev->dev.platform_data;
struct mv643xx_eth_shared_private *msp;
const struct mbus_dram_target_info *dram;
struct resource *res;
int ret;
+ const int *prop;
+ int tx_csum_limit = 0;
if (!mv643xx_eth_version_printed++)
pr_notice("MV-643xx 10/100/1000 ethernet driver version %s\n",
@@ -2576,13 +2590,19 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
if (dram)
mv643xx_eth_conf_mbus_windows(msp, dram);
- msp->tx_csum_limit = (pd != NULL && pd->tx_csum_limit) ?
- pd->tx_csum_limit : 9 * 1024;
+ if (np) {
+ prop = of_get_property(np, "tx-csum-limit", NULL);
+ if (prop)
+ tx_csum_limit = be32_to_cpup(prop);
+ } else
+ tx_csum_limit = pd->tx_csum_limit;
+
+ msp->tx_csum_limit = tx_csum_limit ? tx_csum_limit : 9 * 1024;
infer_hw_params(msp);
platform_set_drvdata(pdev, msp);
- return 0;
+ return of_platform_bus_probe(np, mv643xx_eth_match, &pdev->dev);
out_free:
kfree(msp);
@@ -2600,12 +2620,22 @@ static int mv643xx_eth_shared_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id mv643xx_eth_shared_match[] = {
+ { .compatible = "marvell,mv64360-eth-group" },
+ { .compatible = "marvell,mv64360-eth-block" },
+ { .compatible = "marvell,mv643xx-eth-group" },
+ { .compatible = "marvell,mv643xx-eth-block" },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mv643xx_eth_shared_match);
+
static struct platform_driver mv643xx_eth_shared_driver = {
.probe = mv643xx_eth_shared_probe,
.remove = mv643xx_eth_shared_remove,
.driver = {
.name = MV643XX_ETH_SHARED_NAME,
.owner = THIS_MODULE,
+ .of_match_table = mv643xx_eth_shared_match,
},
};
@@ -2764,6 +2794,71 @@ static const struct net_device_ops mv643xx_eth_netdev_ops = {
#endif
};
+#ifdef CONFIG_OF
+static int mv643xx_eth_of_probe(struct platform_device *pdev)
+{
+ struct mv643xx_eth_platform_data *pd;
+ struct device_node *np = pdev->dev.of_node;
+ struct device_node *shared = of_get_parent(np);
+ struct device_node *phy_node;
+ const int *prop;
+ const char *mac_addr;
+
+ if (!pdev->dev.of_node)
+ return 0;
+
+ pd = kzalloc(sizeof(*pd), GFP_KERNEL);
+ if (!pd)
+ return -ENOMEM;
+
+ pdev->dev.platform_data = pd;
+
+ pd->shared = of_find_device_by_node(shared);
+ if (!pd->shared)
+ return -ENODEV;
+
+ prop = of_get_property(np, "reg", NULL);
+ if (!prop)
+ return -EINVAL;
+
+ pd->port_number = be32_to_cpup(prop);
+
+ phy_node = of_parse_phandle(np, "phy", 0);
+ if (!phy_node)
+ pd->phy_addr = MV643XX_ETH_PHY_NONE;
+ else {
+ prop = of_get_property(phy_node, "reg", NULL);
+ if (prop)
+ pd->phy_addr = be32_to_cpup(prop);
+ }
+
+ mac_addr = of_get_mac_address(np);
+ if (mac_addr)
+ memcpy(pd->mac_addr, mac_addr, ETH_ALEN);
+
+#define rx_tx_queue_sram_property(_name) \
+ prop = of_get_property(np, __stringify(_name), NULL); \
+ if (prop) \
+ pd->_name = be32_to_cpup(prop);
+
+ rx_tx_queue_sram_property(rx_queue_count);
+ rx_tx_queue_sram_property(tx_queue_count);
+ rx_tx_queue_sram_property(rx_queue_size);
+ rx_tx_queue_sram_property(tx_queue_size);
+ rx_tx_queue_sram_property(rx_sram_addr);
+ rx_tx_queue_sram_property(rx_sram_size);
+ rx_tx_queue_sram_property(tx_sram_addr);
+ rx_tx_queue_sram_property(rx_sram_size);
+
+ return 0;
+}
+#else
+static inline int mv643xx_eth_of_probe(struct platform_device *dev)
+{
+ return 0;
+}
+#endif
+
static int mv643xx_eth_probe(struct platform_device *pdev)
{
struct mv643xx_eth_platform_data *pd;
@@ -2772,7 +2867,12 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
struct resource *res;
int err;
+ err = mv643xx_eth_of_probe(pdev);
+ if (err)
+ return err;
+
pd = pdev->dev.platform_data;
+
if (pd == NULL) {
dev_err(&pdev->dev, "no mv643xx_eth_platform_data\n");
return -ENODEV;
@@ -2896,6 +2996,8 @@ out:
}
#endif
free_netdev(dev);
+ if (pdev->dev.of_node)
+ kfree(pd);
return err;
}
@@ -2903,6 +3005,7 @@ out:
static int mv643xx_eth_remove(struct platform_device *pdev)
{
struct mv643xx_eth_private *mp = platform_get_drvdata(pdev);
+ struct mv643xx_eth_platform_data *pd = pdev->dev.platform_data;
unregister_netdev(mp->dev);
if (mp->phy != NULL)
@@ -2918,6 +3021,9 @@ static int mv643xx_eth_remove(struct platform_device *pdev)
free_netdev(mp->dev);
+ if (pdev->dev.of_node)
+ kfree(pd);
+
platform_set_drvdata(pdev, NULL);
return 0;
@@ -2935,6 +3041,7 @@ static void mv643xx_eth_shutdown(struct platform_device *pdev)
port_reset(mp);
}
+
static struct platform_driver mv643xx_eth_driver = {
.probe = mv643xx_eth_probe,
.remove = mv643xx_eth_remove,
@@ -2942,6 +3049,7 @@ static struct platform_driver mv643xx_eth_driver = {
.driver = {
.name = MV643XX_ETH_NAME,
.owner = THIS_MODULE,
+ .of_match_table = mv643xx_eth_match,
},
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/4] ARM: orion5x: add gigabit ethernet device tree node
From: Florian Fainelli @ 2013-03-29 18:14 UTC (permalink / raw)
To: davem
Cc: netdev, linux-arm-kernel, devicetree-discuss, thomas.petazzoni,
jm, moinejf, sebastian.hesselbarth, buytenh, andrew, jason,
grant.likely, rob.herring, Florian Fainelli
In-Reply-To: <1364580879-4297-1-git-send-email-florian@openwrt.org>
This patch adds the gigabit ethernet device tree node to orion5x.dtsi.
This node is disabled by default and must be enabled on a per-board
basis. For completeness and easier testing the MDIO node is also added
and disabled by default.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
arch/arm/boot/dts/orion5x.dtsi | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/orion5x.dtsi b/arch/arm/boot/dts/orion5x.dtsi
index 8aad00f..8d83220 100644
--- a/arch/arm/boot/dts/orion5x.dtsi
+++ b/arch/arm/boot/dts/orion5x.dtsi
@@ -94,5 +94,28 @@
interrupts = <22>;
status = "okay";
};
+
+ mdio@72004 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,orion-mdio";
+ reg = <0x72004 0x84>;
+ status = "disabled";
+ };
+
+ ethernet-group@70000 {
+ #address-cells = <1>.
+ #size-cells = <0>;
+ compatible = "marvell,mv643xx-eth-block";
+ reg = <0x70000 0x4000>;
+ status = "disabled";
+
+ egiga0: ethernet@0 {
+ device_type = "network";
+ compatible = "marvell,mv643xx-eth";
+ reg = <0>;
+ interrupts = <21>;
+ };
+ };
};
};
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 1/4] mv643xx_eth: add Device Tree bindings
From: Florian Fainelli @ 2013-03-29 18:25 UTC (permalink / raw)
To: Florian Fainelli
Cc: davem, netdev, linux-arm-kernel, devicetree-discuss,
thomas.petazzoni, jm, moinejf, sebastian.hesselbarth, buytenh,
andrew, jason, grant.likely, rob.herring
In-Reply-To: <1364580879-4297-2-git-send-email-florian@openwrt.org>
Le 03/29/13 19:14, Florian Fainelli a écrit :
> This patch adds Device Tree bindings following the already defined
> bindings at Documentation/devicetree/bindings/marvell.txt. The binding
> documentation is also enhanced with new optionnal properties required
> for supporting certain devices (RX/TX queue and SRAM). Since we now have
> proper support for the orion MDIO bus driver, there is no need to fiddle
> around with device tree phandles.
>
> Signed-off-by: Florian Fainelli <florian@openwrt.org>
> ---
[snip]
>
> - return 0;
> + return of_platform_bus_probe(np, mv643xx_eth_match, &pdev->dev);
This breaks on non-OF builds, I will wait for more comments to show up
and fix this in the next round.
--
Florian
^ permalink raw reply
* Re: [BUG] Crash with NULL pointer dereference in bond_handle_frame in -rt (possibly mainline)
From: Steven Rostedt @ 2013-03-29 18:36 UTC (permalink / raw)
To: Jiri Pirko
Cc: Eric Dumazet, Andy Gospodarek, David S. Miller, LKML, netdev,
Nicolas de Pesloüan, Thomas Gleixner, Guy Streeter,
Paul E. McKenney, stephen
In-Reply-To: <20130329094856.GB1677@minipsycho.orion>
On Fri, 2013-03-29 at 10:48 +0100, Jiri Pirko wrote:
> Because, if rcu_dereference(dev->rx_handler) is null,
> rcu_dereference(dev->rx_handler_data) is never done. Therefore I believe
> we are hitting following scenario:
>
>
> CPU0 CPU1
> ---- ----
> dev->rx_handler_data = NULL
> rcu_read_lock()
> dev->rx_handler = NULL
>
>
That is not what is happening and that is not how RCU works. That is,
rcu_read_lock() does not block nor does it really do much with ordering
at all.
The problem is totally contained within the rcu_read_lock() as well:
If you have:
rcu_read_lock();
rx_handler = dev->rx_handler;
rx_handler();
rcu_read_unlock();
where rx_handler references rx->rx_handler_data you need much more than
making sure that rx->handler is set to null before rx_handler_data.
The way RCU works is it lets things exist in a "dual state". Kind of
like a Schödinger's cat. The solution Eric posted is a classic RCU
example of how this works.
When you set dev->rx_handler to NULL, there's two states that currently
exist in the system. Those that still see dev->rx_handler set to
something and those that see it set to NULL. You could put in memory
barriers to your hearts content, but you will still have a system that
sees things in a dual state. If you set dev->rx_handler_data to NULL,
you risk those that see rx_handler as a function can still reference the
rx_handler_data when it is NULL.
Think of it this way:
dev->rx_handler() {
Once the function has been called, even if you set rx_handler() to NULL
at this point, it makes no difference, even with memory barriers. This
CPU is about to execute the previous value of rx_handler and there's
nothing you can do to stop it. Setting rx_handler_data to NULL now can
cause that CPU to reference the NULL pointer. There isn't a ordering
problem where rx_handler_data got set to NULL first.
But the beauty about RCU is the synchronize_*() functions, because that
puts the system back into a single state. After the synchronization is
complete, the entire system sees rx_handler() as NULL. There is no worry
about setting rx_handler_data to NULL now because nothing will be
referencing the previous value of rx_handler because that value no
longer exists in the system.
That means Eric's solution fits perfectly well here.
< system in single state : everyone sees rx_handler = function() >
rx_handler = NULL;
< system in dual state : new calls see rx_handler = NULL, but
current calls see rx_handler = function >
synchronize_net();
< system is back to single state: everyone sees rx_handler = NULL >
rx_handler_data = NULL;
no problem ;-)
-- Steve
^ permalink raw reply
* Re: [PATCH] phy: Elimination the forced speed reduction algorithm.
From: David Miller @ 2013-03-29 18:38 UTC (permalink / raw)
To: kapranoff
Cc: netdev, bhutchings, peppe.cavallaro, joe, bruce.w.allan,
linux-kernel
In-Reply-To: <1364304872-6408-1-git-send-email-kapranoff@inbox.ru>
From: Kirill Kapranov <kapranoff@inbox.ru>
Date: Tue, 26 Mar 2013 17:34:32 +0400
> In case of fixed speed set up for a NIC (e.g. ethtool -s eth0 autoneg off speed
> 100 duplex full) with an ethernet cable plugged off, the mentioned algorithm
> slows down a NIC speed, so further cable hook-up leads to nonoperable link state.
>
> Signed-off-by: Kirill Kapranov <kapranoff@inbox.ru>
Why are you posting this again? I've applied your patch 3 days
ago.
^ permalink raw reply
* oops in udpv6_sendmsg
From: Dave Jones @ 2013-03-29 18:40 UTC (permalink / raw)
To: netdev
Just hit this on Linus' current tree.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000031
IP: [<ffffffff8166ca6b>] udpv6_sendmsg+0x34b/0xa90
PGD 67f4e067 PUD 60281067 PMD 0
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in: dlci 8021q garp mrp fuse vmw_vsock_vmci_transport vmw_vmci vsock bnep hidp bridge stp rfcomm l2tp_ppp l2tp_netlink l2tp_core phonet af_key af_rxrpc caif_socket caif rose llc2 netrom can_raw cmtp kernelcapi nfnetlink ipt_ULOG can_bcm can af_802154 scsi_transport_iscsi pppoe ipx atm ax25 p8023 p8022 nfc pppox decnet irda ppp_generic x25 slhc rds crc_ccitt appletalk psnap llc lockd sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek raid0 snd_hda_intel snd_hda_codec snd_pcm btusb microcode snd_page_alloc serio_raw snd_timer bluetooth pcspkr snd edac_core rfkill soundcore r8169 mii vhost_net tun macvtap macvlan kvm_amd kvm radeon backlight drm_kms_helper ttm
CPU 0
Pid: 22781, comm: trinity-child33 Not tainted 3.9.0-rc4+ #7 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
RIP: 0010:[<ffffffff8166ca6b>] [<ffffffff8166ca6b>] udpv6_sendmsg+0x34b/0xa90
RSP: 0018:ffff880011811a70 EFLAGS: 00010206
RAX: 0000000000000005 RBX: ffff8800167a7000 RCX: ffff8800167a7618
RDX: ffff8800167a7248 RSI: ffff88011959d680 RDI: ffff88011959d680
RBP: ffff880011811ba0 R08: ffff8800167a75f8 R09: 0000000000000001
R10: ffff8800603f2490 R11: 0000000000000002 R12: 00000000ffffffe0
R13: ffff8800167a75f8 R14: ffff88011959d680 R15: ffff8800167a75f8
FS: 00007f655b275740(0000) GS:ffff88012a600000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000031 CR3: 000000008e94a000 CR4: 00000000000007f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process trinity-child33 (pid: 22781, threadinfo ffff880011810000, task ffff8800603f2490)
Stack:
ffff880000000000 0000000000000000 ffff880011811b28 ffff88011959d680
00000000200065c0 ffffffff00000000 ffff8800167a7600 ffff8800167a75f8
0000000011811ac0 0000000000000000 ffff8800167a7618 ffff8800167a7248
Call Trace:
[<ffffffff8100a144>] ? native_sched_clock+0x24/0x80
[<ffffffff810b3348>] ? trace_hardirqs_off_caller+0x28/0xc0
[<ffffffff816076ac>] inet_sendmsg+0x10c/0x220
[<ffffffff816075a5>] ? inet_sendmsg+0x5/0x220
[<ffffffff81567b37>] sock_sendmsg+0xb7/0xe0
[<ffffffff8100a144>] ? native_sched_clock+0x24/0x80
[<ffffffff810b3462>] ? get_lock_stats+0x22/0x70
[<ffffffff810b3b8e>] ? put_lock_stats.isra.27+0xe/0x40
[<ffffffff810b418c>] ? lock_release_holdtime.part.28+0x9c/0x150
[<ffffffff81578286>] ? verify_iovec+0x56/0xd0
[<ffffffff8156884e>] __sys_sendmsg+0x3ae/0x3c0
[<ffffffff8100a144>] ? native_sched_clock+0x24/0x80
[<ffffffff810b3462>] ? get_lock_stats+0x22/0x70
[<ffffffff810b3b8e>] ? put_lock_stats.isra.27+0xe/0x40
[<ffffffff810b41d5>] ? lock_release_holdtime.part.28+0xe5/0x150
[<ffffffff8100a144>] ? native_sched_clock+0x24/0x80
[<ffffffff810b3348>] ? trace_hardirqs_off_caller+0x28/0xc0
[<ffffffff810b3b8e>] ? put_lock_stats.isra.27+0xe/0x40
[<ffffffff816c512c>] ? _raw_spin_unlock_irq+0x2c/0x60
[<ffffffff811dbe5c>] ? fget_light+0x38c/0x500
[<ffffffff8156a989>] sys_sendmsg+0x49/0x90
[<ffffffff816cd942>] system_call_fastpath+0x16/0x1b
Code: dc 03 f0 ff 48 8b 4c 24 50 4c 8b 44 24 38 48 8b 54 24 58 49 89 4d 48 4d 89 45 50 49 8b 86 a0 00 00 00 48 85 c0 0f 84 6c 06 00 00 <8b> 40 2c 41 89 45 74 48 89 d7 e8 66 85 05 00 45 85 e4 7e 1e 41
RIP [<ffffffff8166ca6b>] udpv6_sendmsg+0x34b/0xa90
RSP <ffff880011811a70>
CR2: 0000000000000031
---[ end trace aafad9c3e4a4dfb2 ]---
All code
========
0: dc 03 faddl (%rbx)
2: f0 ff 48 8b lock decl -0x75(%rax)
6: 4c 24 50 rex.WR and $0x50,%al
9: 4c 8b 44 24 38 mov 0x38(%rsp),%r8
e: 48 8b 54 24 58 mov 0x58(%rsp),%rdx
13: 49 89 4d 48 mov %rcx,0x48(%r13)
17: 4d 89 45 50 mov %r8,0x50(%r13)
1b: 49 8b 86 a0 00 00 00 mov 0xa0(%r14),%rax
22: 48 85 c0 test %rax,%rax
25: 0f 84 6c 06 00 00 je 0x697
2b:* 8b 40 2c mov 0x2c(%rax),%eax <-- trapping instruction
2e: 41 89 45 74 mov %eax,0x74(%r13)
32: 48 89 d7 mov %rdx,%rdi
35: e8 66 85 05 00 callq 0x585a0
3a: 45 85 e4 test %r12d,%r12d
3d: 7e 1e jle 0x5d
3f: 41 rex.B
which looks like this in udpv6_sendmsg ..
np->daddr_cache = daddr;
ca3: 49 89 4d 48 mov %rcx,0x48(%r13)
#ifdef CONFIG_IPV6_SUBTREES
np->saddr_cache = saddr;
ca7: 4d 89 45 50 mov %r8,0x50(%r13)
#endif
np->dst_cookie = rt->rt6i_node ? rt->rt6i_node->fn_sernum : 0;
cab: 49 8b 86 a0 00 00 00 mov 0xa0(%r14),%rax
cb2: 48 85 c0 test %rax,%rax
cb5: 0f 84 6c 06 00 00 je 1327 <udpv6_sendmsg+0x9b7>
cbb: 8b 40 2c mov 0x2c(%rax),%eax
cbe: 41 89 45 74 mov %eax,0x74(%r13)
raw_spin_lock_irqsave_nested(spinlock_check(lock), flags, subclass); \
} while (0)
Looks like the last line of an inlined __ip6_dst_store() call. So line 1243 of net/ipv6/udp.c
Dave
^ permalink raw reply
* Re: [PATCH v2 net-next] netlink: fix the warning introduced by netlink API replacement
From: David Miller @ 2013-03-29 18:45 UTC (permalink / raw)
To: honkiko; +Cc: netdev, stephen, brian.haley, tgraf
In-Reply-To: <1364569775-4419-1-git-send-email-honkiko@gmail.com>
From: Hong Zhiguo <honkiko@gmail.com>
Date: Fri, 29 Mar 2013 23:09:35 +0800
> Signed-off-by: Hong Zhiguo <honkiko@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/4] ARM: kirkwood: add device node entries for the gigabit interfaces
From: Jason Cooper @ 2013-03-29 18:48 UTC (permalink / raw)
To: Florian Fainelli
Cc: moinejf-GANU6spQydw, andrew-g2DYL2Zd6BY,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ,
buytenh-OLH4Qvv75CYX/NnBR394Jw, jm-Pj/HzkgeCk7QXOPxS62xeg,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1364580879-4297-3-git-send-email-florian-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
On Fri, Mar 29, 2013 at 07:14:37PM +0100, Florian Fainelli wrote:
> This patch modifies kirkwood.dtsi to specify the various gigabit
> interfaces nodes available on kirkwood devices. They are disabled by
> default and should be enabled on a per-board basis. egiga0 and egiga1
> aliases are defined for convenience. The mdio node is also present and
> should be enabled on a per-board basis as well.
>
> Signed-off-by: Florian Fainelli <florian-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
> ---
> arch/arm/boot/dts/kirkwood.dtsi | 46 +++++++++++++++++++++++++++++++++++++++
> arch/arm/mach-kirkwood/common.c | 4 ++--
> 2 files changed, 48 insertions(+), 2 deletions(-)
>
...
> diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
> index 49792a0..a606f9f 100644
> --- a/arch/arm/mach-kirkwood/common.c
> +++ b/arch/arm/mach-kirkwood/common.c
> @@ -251,8 +251,8 @@ void __init kirkwood_clk_init(void)
> /* clkdev entries, mapping clks to devices */
> orion_clkdev_add(NULL, "orion_spi.0", runit);
> orion_clkdev_add(NULL, "orion_spi.1", runit);
> - orion_clkdev_add(NULL, MV643XX_ETH_NAME ".0", ge0);
> - orion_clkdev_add(NULL, MV643XX_ETH_NAME ".1", ge1);
> + orion_clkdev_add("0", MV643XX_ETH_NAME ".0", ge0);
> + orion_clkdev_add("1", MV643XX_ETH_NAME ".1", ge1);
Your first patch is going to go through David's tree, and I'd like to
prevent any hard dependency between his tree and arm-soc. Can this
change be pulled out and applied separately? At first glance, it looks
like a fix to match sata and pcie.
thx,
Jason.
^ permalink raw reply
* Re: oops in udpv6_sendmsg
From: Eric Dumazet @ 2013-03-29 18:49 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev
In-Reply-To: <20130329184006.GA23893@redhat.com>
On Fri, 2013-03-29 at 14:40 -0400, Dave Jones wrote:
> Just hit this on Linus' current tree.
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000031
> IP: [<ffffffff8166ca6b>] udpv6_sendmsg+0x34b/0xa90
> PGD 67f4e067 PUD 60281067 PMD 0
> Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> Modules linked in: dlci 8021q garp mrp fuse vmw_vsock_vmci_transport vmw_vmci vsock bnep hidp bridge stp rfcomm l2tp_ppp l2tp_netlink l2tp_core phonet af_key af_rxrpc caif_socket caif rose llc2 netrom can_raw cmtp kernelcapi nfnetlink ipt_ULOG can_bcm can af_802154 scsi_transport_iscsi pppoe ipx atm ax25 p8023 p8022 nfc pppox decnet irda ppp_generic x25 slhc rds crc_ccitt appletalk psnap llc lockd sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek raid0 snd_hda_intel snd_hda_codec snd_pcm btusb microcode snd_page_alloc serio_raw snd_timer bluetooth pcspkr snd edac_core rfkill soundcore r8169 mii vhost_net tun macvtap macvlan kvm_amd kvm radeon backlight drm_kms_helper ttm
> CPU 0
> Pid: 22781, comm: trinity-child33 Not tainted 3.9.0-rc4+ #7 Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
> RIP: 0010:[<ffffffff8166ca6b>] [<ffffffff8166ca6b>] udpv6_sendmsg+0x34b/0xa90
> RSP: 0018:ffff880011811a70 EFLAGS: 00010206
> RAX: 0000000000000005 RBX: ffff8800167a7000 RCX: ffff8800167a7618
> RDX: ffff8800167a7248 RSI: ffff88011959d680 RDI: ffff88011959d680
> RBP: ffff880011811ba0 R08: ffff8800167a75f8 R09: 0000000000000001
> R10: ffff8800603f2490 R11: 0000000000000002 R12: 00000000ffffffe0
> R13: ffff8800167a75f8 R14: ffff88011959d680 R15: ffff8800167a75f8
> FS: 00007f655b275740(0000) GS:ffff88012a600000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000031 CR3: 000000008e94a000 CR4: 00000000000007f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process trinity-child33 (pid: 22781, threadinfo ffff880011810000, task ffff8800603f2490)
> Stack:
> ffff880000000000 0000000000000000 ffff880011811b28 ffff88011959d680
> 00000000200065c0 ffffffff00000000 ffff8800167a7600 ffff8800167a75f8
> 0000000011811ac0 0000000000000000 ffff8800167a7618 ffff8800167a7248
> Call Trace:
> [<ffffffff8100a144>] ? native_sched_clock+0x24/0x80
> [<ffffffff810b3348>] ? trace_hardirqs_off_caller+0x28/0xc0
> [<ffffffff816076ac>] inet_sendmsg+0x10c/0x220
> [<ffffffff816075a5>] ? inet_sendmsg+0x5/0x220
> [<ffffffff81567b37>] sock_sendmsg+0xb7/0xe0
> [<ffffffff8100a144>] ? native_sched_clock+0x24/0x80
> [<ffffffff810b3462>] ? get_lock_stats+0x22/0x70
> [<ffffffff810b3b8e>] ? put_lock_stats.isra.27+0xe/0x40
> [<ffffffff810b418c>] ? lock_release_holdtime.part.28+0x9c/0x150
> [<ffffffff81578286>] ? verify_iovec+0x56/0xd0
> [<ffffffff8156884e>] __sys_sendmsg+0x3ae/0x3c0
> [<ffffffff8100a144>] ? native_sched_clock+0x24/0x80
> [<ffffffff810b3462>] ? get_lock_stats+0x22/0x70
> [<ffffffff810b3b8e>] ? put_lock_stats.isra.27+0xe/0x40
> [<ffffffff810b41d5>] ? lock_release_holdtime.part.28+0xe5/0x150
> [<ffffffff8100a144>] ? native_sched_clock+0x24/0x80
> [<ffffffff810b3348>] ? trace_hardirqs_off_caller+0x28/0xc0
> [<ffffffff810b3b8e>] ? put_lock_stats.isra.27+0xe/0x40
> [<ffffffff816c512c>] ? _raw_spin_unlock_irq+0x2c/0x60
> [<ffffffff811dbe5c>] ? fget_light+0x38c/0x500
> [<ffffffff8156a989>] sys_sendmsg+0x49/0x90
> [<ffffffff816cd942>] system_call_fastpath+0x16/0x1b
> Code: dc 03 f0 ff 48 8b 4c 24 50 4c 8b 44 24 38 48 8b 54 24 58 49 89 4d 48 4d 89 45 50 49 8b 86 a0 00 00 00 48 85 c0 0f 84 6c 06 00 00 <8b> 40 2c 41 89 45 74 48 89 d7 e8 66 85 05 00 45 85 e4 7e 1e 41
> RIP [<ffffffff8166ca6b>] udpv6_sendmsg+0x34b/0xa90
> RSP <ffff880011811a70>
> CR2: 0000000000000031
> ---[ end trace aafad9c3e4a4dfb2 ]---
>
> All code
> ========
> 0: dc 03 faddl (%rbx)
> 2: f0 ff 48 8b lock decl -0x75(%rax)
> 6: 4c 24 50 rex.WR and $0x50,%al
> 9: 4c 8b 44 24 38 mov 0x38(%rsp),%r8
> e: 48 8b 54 24 58 mov 0x58(%rsp),%rdx
> 13: 49 89 4d 48 mov %rcx,0x48(%r13)
> 17: 4d 89 45 50 mov %r8,0x50(%r13)
> 1b: 49 8b 86 a0 00 00 00 mov 0xa0(%r14),%rax
> 22: 48 85 c0 test %rax,%rax
> 25: 0f 84 6c 06 00 00 je 0x697
> 2b:* 8b 40 2c mov 0x2c(%rax),%eax <-- trapping instruction
> 2e: 41 89 45 74 mov %eax,0x74(%r13)
> 32: 48 89 d7 mov %rdx,%rdi
> 35: e8 66 85 05 00 callq 0x585a0
> 3a: 45 85 e4 test %r12d,%r12d
> 3d: 7e 1e jle 0x5d
> 3f: 41 rex.B
>
> which looks like this in udpv6_sendmsg ..
>
>
> np->daddr_cache = daddr;
> ca3: 49 89 4d 48 mov %rcx,0x48(%r13)
> #ifdef CONFIG_IPV6_SUBTREES
> np->saddr_cache = saddr;
> ca7: 4d 89 45 50 mov %r8,0x50(%r13)
> #endif
> np->dst_cookie = rt->rt6i_node ? rt->rt6i_node->fn_sernum : 0;
> cab: 49 8b 86 a0 00 00 00 mov 0xa0(%r14),%rax
> cb2: 48 85 c0 test %rax,%rax
> cb5: 0f 84 6c 06 00 00 je 1327 <udpv6_sendmsg+0x9b7>
> cbb: 8b 40 2c mov 0x2c(%rax),%eax
> cbe: 41 89 45 74 mov %eax,0x74(%r13)
> raw_spin_lock_irqsave_nested(spinlock_check(lock), flags, subclass); \
> } while (0)
>
> Looks like the last line of an inlined __ip6_dst_store() call. So line 1243 of net/ipv6/udp.c
>
> Dave
Yes, I had the same problem on my lab machine yesterday and was working
on it (Using a linux-3.3.8 code base)
In my case, the invalid rt6i_node value was 0x66b579de
<1>[ 1307.437873] BUG: unable to handle kernel paging request at 0000000066b57a02
<1>[ 1307.444845] IP: [<ffffffffa001997b>] udpv6_sendmsg+0x28b/0xb20 [ipv6]
<4>[ 1307.451290] PGD 6f218f067 PUD 0
<4>[ 1307.454550] Oops: 0000 [#1] SMP
<0>[ 1307.458062] gsmi: Log Shutdown Reason 0x04
<4>[ 1307.462147] CPU 3
<4>[ 1307.463987] Modules linked in: nvram tun 8021q bridge stp llc ipt_ULOG ip_queue nfnetlink act_mirred cls_tcindex sch_dsmark ipt_USE_CACHED_DSCP ipt_UPDATE_CACHED_DSCP xt_DSCP xt_dscp xt_multiport iptable_mangle pca954x i2c_mux cdc_acm uhci_hcd ehci_hcd i2c_dev i2c_i801 i2c_core i2c_debug msr cpuid genrtc mlx4_en ib_uverbs mlx4_ib ib_mad ib_core mlx4_core e1000e bnx2x libcrc32c mdio ipv6
<4>[ 1307.499017]
<4>[ 1307.500515] Pid: 4135, comm: trinity-child23 Tainted: G W 3.3.8-smp-DEV #293
<4>[ 1307.510969] RIP: 0010:[<ffffffffa001997b>] [<ffffffffa001997b>] udpv6_sendmsg+0x28b/0xb20 [ipv6]
<4>[ 1307.519839] RSP: 0018:ffff8806cd393a68 EFLAGS: 00010206
<4>[ 1307.525141] RAX: 0000000000000000 RBX: ffff88011a350580 RCX: 00000000ffffffa6
<4>[ 1307.532257] RDX: 0000000066b579de RSI: ffff880132298c80 RDI: ffff880132298c80
<4>[ 1307.539367] RBP: ffff8806cd393ba8 R08: 00000000ffff8008 R09: 0000000000000040
<4>[ 1307.546484] R10: ffff88011a350990 R11: 0000000000000001 R12: ffff88011a350990
<4>[ 1307.553604] R13: ffff88011a350970 R14: ffff88011a350970 R15: ffff880132298c80
<4>[ 1307.560721] FS: 0000000000b04880(0063) GS:ffff88067fc60000(0000) knlGS:0000000000000000
<4>[ 1307.568790] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[ 1307.574523] CR2: 0000000066b57a02 CR3: 00000006ebe90000 CR4: 00000000000006e0
<4>[ 1307.581640] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>[ 1307.588757] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>[ 1307.595867] Process trinity-child23 (pid: 4135, threadinfo ffff8806cd392000, task ffff8806f4b8d340)
<4>[ 1307.604889] Stack:
<4>[ 1307.606903] 0000000000000000 0000000000000000 ffff8806cd393b38 ffff880132298c80
<4>[ 1307.614386] 0000000000005a8a ffff880100000000 ffff8806cd393b28 ffffffff8045f149
<4>[ 1307.621859] ffff8801ffffffa6 0000000000000000 0000000000000000 ffff8806cd393b38
<4>[ 1307.629333] Call Trace:
<4>[ 1307.631781] [<ffffffff8045f149>] ? ext4_da_write_end+0x99/0x370
<4>[ 1307.637771] [<ffffffff80348e3c>] ? generic_file_buffered_write+0x1ac/0x280
<4>[ 1307.644717] [<ffffffff80776a64>] inet_sendmsg+0x64/0xb0
<4>[ 1307.650017] [<ffffffff806e9327>] sock_sendmsg+0x117/0x130
<4>[ 1307.655494] [<ffffffff8034a459>] ? __generic_file_aio_write+0x229/0x440
<4>[ 1307.662178] [<ffffffff806ebfed>] ? move_addr_to_kernel+0x4d/0x90
<4>[ 1307.668260] [<ffffffff806f8faa>] ? verify_iovec+0x4a/0xd0
<4>[ 1307.673734] [<ffffffff806ea6ec>] __sys_sendmsg+0x38c/0x3a0
<4>[ 1307.679299] [<ffffffff802ab439>] ? enqueue_hrtimer+0x39/0xc0
<4>[ 1307.685034] [<ffffffff802ac318>] ? hrtimer_start+0x18/0x20
<4>[ 1307.690592] [<ffffffff802876e4>] ? do_setitimer+0x234/0x2a0
<4>[ 1307.696242] [<ffffffff806ed155>] sys_sendmsg+0x75/0xf0
<4>[ 1307.701458] [<ffffffff807c8172>] system_call_fastpath+0x16/0x1b
^ permalink raw reply
* Re: [PATCH 2/4] ARM: kirkwood: add device node entries for the gigabit interfaces
From: Florian Fainelli @ 2013-03-29 18:51 UTC (permalink / raw)
To: Jason Cooper
Cc: davem, netdev, linux-arm-kernel, devicetree-discuss,
thomas.petazzoni, jm, moinejf, sebastian.hesselbarth, buytenh,
andrew, grant.likely, rob.herring
In-Reply-To: <20130329184852.GM13280@titan.lakedaemon.net>
Le 03/29/13 19:48, Jason Cooper a écrit :
> On Fri, Mar 29, 2013 at 07:14:37PM +0100, Florian Fainelli wrote:
>> This patch modifies kirkwood.dtsi to specify the various gigabit
>> interfaces nodes available on kirkwood devices. They are disabled by
>> default and should be enabled on a per-board basis. egiga0 and egiga1
>> aliases are defined for convenience. The mdio node is also present and
>> should be enabled on a per-board basis as well.
>>
>> Signed-off-by: Florian Fainelli <florian@openwrt.org>
>> ---
>> arch/arm/boot/dts/kirkwood.dtsi | 46 +++++++++++++++++++++++++++++++++++++++
>> arch/arm/mach-kirkwood/common.c | 4 ++--
>> 2 files changed, 48 insertions(+), 2 deletions(-)
>>
> ...
>> diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
>> index 49792a0..a606f9f 100644
>> --- a/arch/arm/mach-kirkwood/common.c
>> +++ b/arch/arm/mach-kirkwood/common.c
>> @@ -251,8 +251,8 @@ void __init kirkwood_clk_init(void)
>> /* clkdev entries, mapping clks to devices */
>> orion_clkdev_add(NULL, "orion_spi.0", runit);
>> orion_clkdev_add(NULL, "orion_spi.1", runit);
>> - orion_clkdev_add(NULL, MV643XX_ETH_NAME ".0", ge0);
>> - orion_clkdev_add(NULL, MV643XX_ETH_NAME ".1", ge1);
>> + orion_clkdev_add("0", MV643XX_ETH_NAME ".0", ge0);
>> + orion_clkdev_add("1", MV643XX_ETH_NAME ".1", ge1);
>
> Your first patch is going to go through David's tree, and I'd like to
> prevent any hard dependency between his tree and arm-soc. Can this
> change be pulled out and applied separately? At first glance, it looks
> like a fix to match sata and pcie.
I just actually did the same thing as what SATA has (two clocks with
names), define a clock name "0" and "1" (is not that too generic BTW?)
for ge0 and ge1. But I don't think this change is required.
--
Florian
^ permalink raw reply
* Re: [PATCH 1/2] sky2: Receive Overflows not counted
From: David Miller @ 2013-03-29 18:52 UTC (permalink / raw)
To: stephen; +Cc: mlindner, netdev
In-Reply-To: <20130328144020.138cdc71@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 28 Mar 2013 14:40:20 -0700
>> The sky2 driver doesn't count the Receive Overflows because the MAC
>> interrupt for this event is not set in the MAC's interrupt mask.
>> The MAC's interrupt mask is set only for Transmit FIFO Underruns.
>>
>> Fix: The correct setting should be (GM_IS_TX_FF_UR | GM_IS_RX_FF_OR)
>> Otherwise the Receive Overflow event will not generate any interrupt.
>> The Receive Overflow interrupt is handled correctly
>>
>> Signed-off-by: Mirko Lindner <mlindner@marvell.com>
>
> Both these patches are fine, but the patch format seems corrupted since
> they won't directly apply with quilt.
>
> Acked-by: Stephen Hemminger <stephen@networkplumber.org>
They apply cleanly to the 'net' tree just fine, I don't know why
it didn't work for you.
^ permalink raw reply
* Re: [PATCH net] ipv6: don't accept node local multicast traffic from the wire
From: David Miller @ 2013-03-29 18:57 UTC (permalink / raw)
To: hannes; +Cc: netdev, erik.hugne, yoshfuji
In-Reply-To: <20130326181334.GH29705@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Tue, 26 Mar 2013 19:13:34 +0100
> Erik Hugne's errata proposal (Errata ID: 3480) to RFC4291 has been
> verified: http://www.rfc-editor.org/errata_search.php?eid=3480
>
> We have to check for pkt_type and loopback flag because either the
> packets are allowed to travel over the loopback interface (in which case
> pkt_type is PACKET_HOST and IFF_LOOPBACK flag is set) or they travel
> over a non-loopback interface back to us (in which case PACKET_TYPE is
> PACKET_LOOPBACK and IFF_LOOPBACK flag is not set).
>
> Cc: Erik Hugne <erik.hugne@ericsson.com>
> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] core: should call pskb_expand_head if skb header is cloned in skb_gso_segment in rx path
From: David Miller @ 2013-03-29 18:59 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1364376845-5000-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Wed, 27 Mar 2013 17:34:05 +0800
> From: Li RongQing <roy.qing.li@gmail.com>
>
> 12b0004d1d1 (adjust skb_gso_segment() for calling in rx path) tries to kill warnings
> by checking if ip_summed is CHECK_NONE or not in rx path, since if skb_gso_segment()
> is called on rx path, and ->ip_summed has different meaning.
>
> but this maybe break skb if skb header is cloned, and not expand the header, since when
> step into skb_mac_gso_segment(), which will still check ip_summed with CHECKSUM_PARTIAL,
> then do gso_send_check(). and after __skb_gso_segment() in queue_gso_packets() of
> openvswitch, queue_userspace_packet() still checks ip_summed with CHECKSUM_PARTIAL,
> and do checksum.
>
> so I think it is enough to ignore the warning in rx path.
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
I'm not going back-and-forth on this issue yet another time.
I want to see discussion amongst people involved in this area
before applying a patch like this, and I'm therefore not applying
this patch for now (you'll have to submit it again after the
discussions take place).
^ permalink raw reply
* Re: [net-next PATCH 3/3] net: frag queue per hash bucket locking
From: Jesper Dangaard Brouer @ 2013-03-29 19:01 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Eric Dumazet, David S. Miller, netdev, Florian Westphal,
Daniel Borkmann
In-Reply-To: <20130329003308.GD20223@order.stressinduktion.org>
On Fri, 2013-03-29 at 01:33 +0100, Hannes Frederic Sowa wrote:
> On Thu, Mar 28, 2013 at 04:39:42PM -0700, Eric Dumazet wrote:
> > On Fri, 2013-03-29 at 00:30 +0100, Hannes Frederic Sowa wrote:
> > > On Thu, Mar 28, 2013 at 01:22:44PM -0700, Eric Dumazet wrote:
> > > > On Thu, 2013-03-28 at 19:57 +0100, Hannes Frederic Sowa wrote:
> > > >
> > > > > I assume that it has to do with the usage of this code in
> > > > > ipv6/netfilter/nf_conntrack_reasm.c, which could be invoked from process
> > > > > context, if I read it correctly.
> > > >
> > > > Then there would be a possible deadlock in current code.
> > >
> > > Netfilter currently does a local_bh_disable() before entering inet_fragment
> > > (and later enables it, again).
> > >
> >
> > Good, so no need for the _bh() as I suspected.
>
> Ack.
>
> I replaced the _bh spin_locks with plain spinlocks and tested the code
> with sending fragments and receiving fragments (netfilter and reassmbly
> logic) with lockdep and didn't get any splats. Looks good so far.
Well, it's great to see, that you are working on solving my patch
proposal. While I'm on Easter vacation ;-) Much appreciated.
I'm officially back from vacation Tuesday, and I'll repost then (after
testing it on my 10G testlab).
--Jesper
^ permalink raw reply
* Re: [PATCH] bonding: fix disabling of arp_interval and miimon
From: David Miller @ 2013-03-29 19:03 UTC (permalink / raw)
To: nikolay; +Cc: netdev, andy, fubar
In-Reply-To: <1364391161-26605-1-git-send-email-nikolay@redhat.com>
From: Nikolay Aleksandrov <nikolay@redhat.com>
Date: Wed, 27 Mar 2013 14:32:41 +0100
> Currently if either arp_interval or miimon is disabled, they both get
> disabled, and upon disabling they get executed once more which is not
> the proper behaviour. Also when doing a no-op and disabling an already
> disabled one, the other again gets disabled.
> Also fix the error messages with the proper valid ranges, and a small
> typo fix in the up delay error message (outputting "down delay", instead
> of "up delay").
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
Indeed the existing code looks completely wrong.
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [net-next PATCH 3/3] net: frag queue per hash bucket locking
From: Eric Dumazet @ 2013-03-29 19:05 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Hannes Frederic Sowa, David S. Miller, netdev, Florian Westphal,
Daniel Borkmann
In-Reply-To: <1364583693.3232.257.camel@localhost>
On Fri, 2013-03-29 at 20:01 +0100, Jesper Dangaard Brouer wrote:
> Well, it's great to see, that you are working on solving my patch
> proposal. While I'm on Easter vacation ;-) Much appreciated.
> I'm officially back from vacation Tuesday, and I'll repost then (after
> testing it on my 10G testlab).
Have a nice Easter break !
^ permalink raw reply
* Re: [PATCH] net: core: Remove redundant call to 'nf_reset' in 'dev_forward_skb'
From: David Miller @ 2013-03-29 19:11 UTC (permalink / raw)
To: shmulik.ladkani; +Cc: greearb, netdev, rgohita
In-Reply-To: <1364462006-5814-1-git-send-email-shmulik.ladkani@gmail.com>
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Date: Thu, 28 Mar 2013 11:13:26 +0200
> 'nf_reset' is called just prior calling 'netif_rx'.
> No need to call it twice.
>
> Reported-by: Igor Michailov <rgohita@gmail.com>
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
I do not see this happening in the:
macvlan_start_xmit()
--> macvlan_queue_xmit()
code path.
I'm not applying this patch. There seems to be no real agreement
that the caller of dev_forward_skb() takes care of the nf_reset().
And wouldn't it be better to consolidate the nf_reset() calls
into one place instead of several, increasing the audit burdon.
^ permalink raw reply
* Re: [PATCH] core: fix the use of this_cpu_ptr
From: David Miller @ 2013-03-29 19:13 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1364463761-32510-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Thu, 28 Mar 2013 17:42:41 +0800
> From: Li RongQing <roy.qing.li@gmail.com>
>
> flush_tasklet is not percpu var, and percpu is percpu var, and
> this_cpu_ptr(&info->cache->percpu->flush_tasklet)
> is not equal to
> &this_cpu_ptr(info->cache->percpu)->flush_tasklet
>
> 1f743b076(use this_cpu_ptr per-cpu helper) introduced this bug.
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] core: simplify the getting percpu of flow_cache
From: David Miller @ 2013-03-29 19:15 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1364473451-3640-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Thu, 28 Mar 2013 20:24:11 +0800
> From: Li RongQing <roy.qing.li@gmail.com>
>
> replace per_cpu with per_cpu_ptr to save conversion between address and pointer
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Applied.
^ 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