* [PATCH V2] net/dt: Add support for overriding phy configuration from device tree
From: Matthew Garrett @ 2014-01-16 14:47 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, kishon-l0cyMroinI0,
Matthew Garrett
In-Reply-To: <20140116135905.GV20094-kDjWylLy9wD0K7fsECOQyeGNnDKD8DIp@public.gmane.org>
Some hardware may be broken in interesting and board-specific ways, such
that various bits of functionality don't work. This patch provides a
mechanism for overriding mii registers during init based on the contents of
the device tree data, allowing board-specific fixups without having to
pollute generic code.
Signed-off-by: Matthew Garrett <matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
---
Documentation/devicetree/bindings/net/phy.txt | 21 +++++
drivers/net/phy/phy_device.c | 29 +++++-
drivers/of/of_net.c | 124 ++++++++++++++++++++++++++
include/linux/of_net.h | 12 +++
4 files changed, 185 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index 7cd18fb..fc50f02 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -23,6 +23,21 @@ Optional Properties:
assume clause 22. The compatible list may also contain other
elements.
+The following properties may be added to either the phy node or the parent
+ethernet device. If not present, the hardware defaults will be used.
+
+- phy-mii-advertise-10half: 1 to advertise half-duplex 10MBit, 0 to disable
+- phy-mii-advertise-10full: 1 to advertise full-duplex 10MBit, 0 to disable
+- phy-mii-advertise-100half: 1 to advertise half-duplex 100MBit, 0 to disable
+- phy-mii-advertise-100full: 1 to advertise full-duplex 100MBit, 0 to disable
+- phy-mii-advertise-100base4: 1 to advertise 100base4, 0 to disable
+- phy-mii-advertise-1000half: 1 to advertise half-duplex 1000MBit, 0 to disable
+- phy-mii-advertise-1000full: 1 to advertise full-duplex 1000MBit, 0 to disable
+- phy-mii-manual-master: 1 to enable manual master/slave configuration, 0
+ to disable manual master/slave configuration
+- phy-mii-as-master: 1 to configure phy to act as master, 0 to configure phy
+ to act as slave. Ignored if manual master/slave configuration is not enabled.
+
Example:
ethernet-phy@0 {
@@ -32,4 +47,10 @@ ethernet-phy@0 {
interrupts = <35 1>;
reg = <0>;
device_type = "ethernet-phy";
+ // Disable advertising of full duplex 1000MBit
+ phy-mii-advertise-1000full = <0>;
+ // Force manual phy master/slave configuration
+ phy-mii-manual-master = <1>;
+ // Forcibly configure phy as slave
+ phy-mii-as-master = <0>;
};
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index d6447b3..91793bc 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -33,6 +33,7 @@
#include <linux/mii.h>
#include <linux/ethtool.h>
#include <linux/phy.h>
+#include <linux/of_net.h>
#include <asm/io.h>
#include <asm/irq.h>
@@ -497,6 +498,28 @@ void phy_disconnect(struct phy_device *phydev)
}
EXPORT_SYMBOL(phy_disconnect);
+int phy_override_from_of(struct phy_device *phydev)
+{
+ int reg, regval;
+ u16 val, mask;
+
+ /* Check for phy register overrides from OF */
+ for (reg = 0; reg < 16; reg++) {
+ if (!of_get_mii_register(phydev, reg, &val, &mask)) {
+ if (!mask)
+ continue;
+ regval = phy_read(phydev, reg);
+ if (regval < 0)
+ continue;
+ regval &= ~mask;
+ regval |= val;
+ phy_write(phydev, reg, regval);
+ }
+ }
+
+ return 0;
+}
+
int phy_init_hw(struct phy_device *phydev)
{
int ret;
@@ -508,7 +531,11 @@ int phy_init_hw(struct phy_device *phydev)
if (ret < 0)
return ret;
- return phydev->drv->config_init(phydev);
+ ret = phydev->drv->config_init(phydev);
+ if (ret < 0)
+ return ret;
+
+ return phy_override_from_of(phydev);
}
/**
diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
index 8f9be2e..4545608 100644
--- a/drivers/of/of_net.c
+++ b/drivers/of/of_net.c
@@ -93,3 +93,127 @@ const void *of_get_mac_address(struct device_node *np)
return NULL;
}
EXPORT_SYMBOL(of_get_mac_address);
+
+/**
+ * Provide phy register overrides from the device tree. Some hardware may
+ * be broken in interesting and board-specific ways, so we want a mechanism
+ * for the board data to provide overrides for default values. This should be
+ * called during phy init.
+ */
+int of_get_mii_register(struct phy_device *phydev, int reg, u16 *val,
+ u16 *mask)
+{
+ u32 tmp;
+ struct device *dev = &phydev->dev;
+ struct device_node *np = dev->of_node;
+
+ *val = 0;
+ *mask = 0;
+
+ if (!np && dev->parent->of_node)
+ np = dev->parent->of_node;
+
+ if (!np)
+ return 0;
+
+ switch (reg) {
+ case MII_ADVERTISE:
+ if (!of_property_read_u32(np, "phy-mii-advertise-10half",
+ &tmp)) {
+ if (tmp) {
+ *val |= ADVERTISE_10HALF;
+ phydev->advertising |= SUPPORTED_10baseT_Half;
+ } else {
+ phydev->advertising &=
+ ~(SUPPORTED_10baseT_Half);
+ }
+
+ *mask |= ADVERTISE_10HALF;
+ }
+ if (!of_property_read_u32(np, "phy-mii-advertise-10full",
+ &tmp)) {
+ if (tmp) {
+ *val |= ADVERTISE_10FULL;
+ phydev->advertising |= SUPPORTED_10baseT_Full;
+ } else {
+ phydev->advertising &=
+ ~(SUPPORTED_10baseT_Full);
+ }
+
+ *mask |= ADVERTISE_10FULL;
+ }
+ if (!of_property_read_u32(np, "phy-mii-advertise-100half",
+ &tmp)) {
+ if (tmp) {
+ *val |= ADVERTISE_100HALF;
+ phydev->advertising |= SUPPORTED_100baseT_Half;
+ } else {
+ phydev->advertising &=
+ ~(SUPPORTED_100baseT_Half);
+ }
+
+ *mask |= ADVERTISE_100HALF;
+ }
+ if (!of_property_read_u32(np, "phy-mii-advertise-100full",
+ &tmp)) {
+ if (tmp) {
+ *val |= ADVERTISE_100FULL;
+ phydev->advertising |= SUPPORTED_100baseT_Full;
+ } else {
+ phydev->advertising &=
+ ~(SUPPORTED_100baseT_Full);
+ }
+
+ *mask |= ADVERTISE_100FULL;
+ }
+ if (!of_property_read_u32(np, "phy-mii-advertise-100base4",
+ &tmp)) {
+ if (tmp)
+ *val |= ADVERTISE_100BASE4;
+ *mask |= ADVERTISE_100BASE4;
+ }
+ break;
+ case MII_CTRL1000:
+ if (!of_property_read_u32(np, "phy-mii-advertise-1000full",
+ &tmp)) {
+ if (tmp) {
+ *val |= ADVERTISE_1000FULL;
+ phydev->advertising |= SUPPORTED_1000baseT_Full;
+ } else {
+ phydev->advertising &=
+ ~(SUPPORTED_1000baseT_Full);
+ }
+
+ *mask |= ADVERTISE_1000FULL;
+ }
+ if (!of_property_read_u32(np, "phy-mii-advertise-1000half",
+ &tmp)) {
+ if (tmp) {
+ *val |= ADVERTISE_1000HALF;
+ phydev->advertising |= SUPPORTED_1000baseT_Half;
+ } else {
+ phydev->advertising &=
+ ~(SUPPORTED_1000baseT_Half);
+ }
+
+ *mask |= ADVERTISE_1000HALF;
+ }
+ if (!of_property_read_u32(np, "phy-mii-as-master",
+ &tmp)) {
+ if (tmp)
+ *val |= CTL1000_AS_MASTER;
+ *mask |= CTL1000_AS_MASTER;
+ }
+ if (!of_property_read_u32(np, "phy-mii-manual-master",
+ &tmp)) {
+ if (tmp)
+ *val |= CTL1000_ENABLE_MASTER;
+ *mask |= CTL1000_ENABLE_MASTER;
+ }
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(of_get_mii_register);
diff --git a/include/linux/of_net.h b/include/linux/of_net.h
index 34597c8..2e478bc 100644
--- a/include/linux/of_net.h
+++ b/include/linux/of_net.h
@@ -7,10 +7,14 @@
#ifndef __LINUX_OF_NET_H
#define __LINUX_OF_NET_H
+#include <linux/phy.h>
+
#ifdef CONFIG_OF_NET
#include <linux/of.h>
extern int of_get_phy_mode(struct device_node *np);
extern const void *of_get_mac_address(struct device_node *np);
+extern int of_get_mii_register(struct phy_device *np, int reg, u16 *val,
+ u16 *mask);
#else
static inline int of_get_phy_mode(struct device_node *np)
{
@@ -21,6 +25,14 @@ static inline const void *of_get_mac_address(struct device_node *np)
{
return NULL;
}
+static inline int of_get_mii_register(struct phy_device *np, int reg, u16 *val,
+ u16 *mask)
+{
+ *val = 0;
+ *mask = 0;
+
+ return -EINVAL;
+}
#endif
#endif /* __LINUX_OF_NET_H */
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] net/dt: Add support for overriding phy configuration from device tree
From: Matthew Garrett @ 2014-01-16 14:40 UTC (permalink / raw)
To: gsi@denx.de
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, devicetree@vger.kernel.org
In-Reply-To: <20140116135905.GV20094@book.gsilab.sittig.org>
On Thu, 2014-01-16 at 14:59 +0100, Gerhard Sittig wrote:
> These properties are booleans, and optional? Does it mean that
> you cannot _disable_ broken features? Or does it mean that you
> _must_ specify the non-broken features and thus break backwards
> compatibility? Or are these properties not boolean (they are not
> used in the example either, unfortunately), and the binding text
> would need an update for clarity? What am I missing?
They're not booleans. I'll update the text to make that clear.
--
Matthew Garrett <matthew.garrett@nebula.com>
^ permalink raw reply
* Re: ipv6 addrconfg warn_on hit: WARN_ON(ifp->idev->valid_ll_addr_cnt < 0);
From: Hannes Frederic Sowa @ 2014-01-16 14:38 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev
In-Reply-To: <20140116140701.GB7961@minipsycho.orion>
On Thu, Jan 16, 2014 at 03:07:01PM +0100, Jiri Pirko wrote:
> Thu, Jan 16, 2014 at 02:53:23PM CET, jiri@resnulli.us wrote:
> >Hi Hannes.
> >
> >WARN_ON(ifp->idev->valid_ll_addr_cnt < 0);
> >
> >We did hit once this warning during the tests. The person who hit this
> >says that it was during the setup of many macvlan devices.
> >
> >I examined the code but I'm not sure how this could happen. Looks like a
> >race condition between addrconf_dad_completed() and addrconf_ifdown().
> >Not sure how to easily resolve that though.
That seems to be the case. Actually we don't need to count precisiely
here, we just must precisiely identify the situation where the first
LL address comes into operational state. Maybe we can implement this
somehow differently. I'll play with the code soon.
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH V2 net-next 1/3] ipv6: add the IPV6_FL_F_REFLECT flag to IPV6_FL_A_GET
From: Florent Fourcot @ 2014-01-16 14:34 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <20140116130753.GE7436@order.stressinduktion.org>
Le 16/01/2014 14:07, Hannes Frederic Sowa a écrit :
> Would it make sense to sync the flowlabel if it changes with the socket, so
> user space can query the label really used? Otherwise I wouldn't even report
> it.
I see at least one use case. In the same way that openssh sets the
tclass field after the SSH session initialization, a software could set
the label after the beginning of the L7 session (and ignoring QoS
priority for non-interactive packet at the beginning).
^ permalink raw reply
* [PATCH net-next v4 2/2] stmmac: Fix kernel crashes for jumbo frames
From: Vince Bridgers @ 2014-01-16 14:05 UTC (permalink / raw)
To: devicetree, netdev
Cc: peppe.cavallaro, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, dinguyen, rayagond, vbridgers2013
In-Reply-To: <1389881155-9758-1-git-send-email-vbridgers2013@gmail.com>
These changes correct the following issues with jumbo frames on the
stmmac driver:
1) The Synopsys EMAC can be configured to support different FIFO
sizes at core configuration time. There's no way to query the
controller and know the FIFO size, so the driver needs to get this
information from the device tree in order to know how to correctly
handle MTU changes and setting up dma buffers. The default
max-frame-size is as currently used, which is the size of a jumbo
frame.
2) The driver was enabling Jumbo frames by default, but was not allocating
dma buffers of sufficient size to handle the maximum possible packet
size that could be received. This led to memory corruption since DMAs were
occurring beyond the extent of the allocated receive buffers for certain types
of network traffic.
kernel BUG at net/core/skbuff.c:126!
Internal error: Oops - BUG: 0 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 563 Comm: sockperf Not tainted 3.13.0-rc6-01523-gf7111b9 #31
task: ef35e580 ti: ef252000 task.ti: ef252000
PC is at skb_panic+0x60/0x64
LR is at skb_panic+0x60/0x64
pc : [<c03c7c3c>] lr : [<c03c7c3c>] psr: 60000113
sp : ef253c18 ip : 60000113 fp : 00000000
r10: ef3a5400 r9 : 00000ebc r8 : ef3a546c
r7 : ee59f000 r6 : ee59f084 r5 : ee59ff40 r4 : ee59f140
r3 : 000003e2 r2 : 00000007 r1 : c0b9c420 r0 : 0000007d
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: 2e8ac04a DAC: 00000015
Process sockperf (pid: 563, stack limit = 0xef252248)
Stack: (0xef253c18 to 0xef254000)
3c00: 00000ebc ee59f000
3c20: ee59f084 ee59ff40 ee59f140 c04a9cd8 ee8c50c0 00000ebc ee59ff40 00000000
3c40: ee59f140 c02d0ef0 00000056 ef1eda80 ee8c50c0 00000ebc 22bbef29 c0318f8c
3c60: 00000056 ef3a547c ffe2c716 c02c9c90 c0ba1298 ef3a5838 ef3a5838 ef3a5400
3c80: 000020c0 ee573840 000055cb ef3f2050 c053f0e0 c0319214 22b9b085 22d92813
3ca0: 00001c80 004b8e00 ef3a5400 ee573840 ef3f2064 22d92813 ef3f2064 000055cb
3cc0: ef3f2050 c031a19c ef252000 00000000 00000000 c0561bc0 00000000 ff00ffff
3ce0: c05621c0 ef3a5400 ef3f2064 ee573840 00000020 ef3f2064 000055cb ef3f2050
3d00: c053f0e0 c031cad0 c053e740 00000e60 00000000 00000000 ee573840 ef3a5400
3d20: ef0a6e00 00000000 ef3f2064 c032507c 00010000 00000020 c0561bc0 c0561bc0
3d40: ee599850 c032799c 00000000 ee573840 c055a380 ef3a5400 00000000 ef3f2064
3d60: ef3f2050 c032799c 0101c7c0 2b6755cb c059a280 c030e4d8 000055cb ffffffff
3d80: ee574fc0 c055a380 ee574000 ee573840 00002b67 ee573840 c03fe9c4 c053fa68
3da0: c055a380 00001f6f 00000000 ee573840 c053f0e0 c0304fdc ef0a6e01 ef3f2050
3dc0: ee573858 ef031000 ee573840 c03055d8 c0ba0c40 ef000f40 00100100 c053f0dc
3de0: c053ffdc c053f0f0 00000008 00000000 ef031000 c02da948 00001140 00000000
3e00: c0563c78 ef253e5f 00000020 ee573840 00000020 c053f0f0 ef313400 ee573840
3e20: c053f0e0 00000000 00000000 c05380c0 ef313400 00001000 00000015 c02df280
3e40: ee574000 ef001e00 00000000 00001080 00000042 005cd980 ef031500 ef031500
3e60: 00000000 c02df824 ef031500 c053e390 c0541084 f00b1e00 c05925e8 c02df864
3e80: 00001f5c ef031440 c053e390 c0278524 00000002 00000000 c0b9eb48 c02df280
3ea0: ee8c7180 00000100 c0542ca8 00000015 00000040 ef031500 ef031500 ef031500
3ec0: c027803c ef252000 00000040 000000ec c05380c0 c0b9eb40 c0b9eb48 c02df940
3ee0: ef060780 ffffa4dd c0564a9c c056343c 002e80a8 00000080 ef031500 00000001
3f00: c053808c ef252000 fffec100 00000003 00000004 002e80a8 0000000c c00258f0
3f20: 002e80a8 c005e704 00000005 00000100 c05634d0 c0538080 c05333e0 00000000
3f40: 0000000a c0565580 c05380c0 ffffa4dc c05434f4 00400100 00000004 c0534cd4
3f60: 00000098 00000000 fffec100 002e80a8 00000004 002e80a8 002a20e0 c0025da8
3f80: c0534cd4 c000f020 fffec10c c053ea60 ef253fb0 c0008530 0000ffe2 b6ef67f4
3fa0: 40000010 ffffffff 00000124 c0012f3c 0000ffe2 002e80f0 0000ffe2 00004000
3fc0: becb6338 becb6334 00000004 00000124 002e80a8 00000004 002e80a8 002a20e0
3fe0: becb6300 becb62f4 002773bb b6ef67f4 40000010 ffffffff 00000000 00000000
[<c03c7c3c>] (skb_panic+0x60/0x64) from [<c02d0ef0>] (skb_put+0x4c/0x50)
[<c02d0ef0>] (skb_put+0x4c/0x50) from [<c0318f8c>] (tcp_collapse+0x314/0x3ec)
[<c0318f8c>] (tcp_collapse+0x314/0x3ec) from [<c0319214>]
(tcp_try_rmem_schedule+0x1b0/0x3c4)
[<c0319214>] (tcp_try_rmem_schedule+0x1b0/0x3c4) from [<c031a19c>]
(tcp_data_queue+0x480/0xe6c)
[<c031a19c>] (tcp_data_queue+0x480/0xe6c) from [<c031cad0>]
(tcp_rcv_established+0x180/0x62c)
[<c031cad0>] (tcp_rcv_established+0x180/0x62c) from [<c032507c>]
(tcp_v4_do_rcv+0x13c/0x31c)
[<c032507c>] (tcp_v4_do_rcv+0x13c/0x31c) from [<c032799c>]
(tcp_v4_rcv+0x718/0x73c)
[<c032799c>] (tcp_v4_rcv+0x718/0x73c) from [<c0304fdc>]
(ip_local_deliver+0x98/0x274)
[<c0304fdc>] (ip_local_deliver+0x98/0x274) from [<c03055d8>]
(ip_rcv+0x420/0x758)
[<c03055d8>] (ip_rcv+0x420/0x758) from [<c02da948>]
(__netif_receive_skb_core+0x44c/0x5bc)
[<c02da948>] (__netif_receive_skb_core+0x44c/0x5bc) from [<c02df280>]
(netif_receive_skb+0x48/0xb4)
[<c02df280>] (netif_receive_skb+0x48/0xb4) from [<c02df824>]
(napi_gro_flush+0x70/0x94)
[<c02df824>] (napi_gro_flush+0x70/0x94) from [<c02df864>]
(napi_complete+0x1c/0x34)
[<c02df864>] (napi_complete+0x1c/0x34) from [<c0278524>]
(stmmac_poll+0x4e8/0x5c8)
[<c0278524>] (stmmac_poll+0x4e8/0x5c8) from [<c02df940>]
(net_rx_action+0xc4/0x1e4)
[<c02df940>] (net_rx_action+0xc4/0x1e4) from [<c00258f0>]
(__do_softirq+0x12c/0x2e8)
[<c00258f0>] (__do_softirq+0x12c/0x2e8) from [<c0025da8>] (irq_exit+0x78/0xac)
[<c0025da8>] (irq_exit+0x78/0xac) from [<c000f020>] (handle_IRQ+0x44/0x90)
[<c000f020>] (handle_IRQ+0x44/0x90) from [<c0008530>]
(gic_handle_irq+0x2c/0x5c)
[<c0008530>] (gic_handle_irq+0x2c/0x5c) from [<c0012f3c>]
(__irq_usr+0x3c/0x60)
3) The driver was setting the dma buffer size after allocating dma buffers,
which caused a system panic when changing the MTU.
BUG: Bad page state in process ifconfig pfn:2e850
page:c0b72a00 count:0 mapcount:0 mapping: (null) index:0x0
page flags: 0x200(arch_1)
Modules linked in:
CPU: 0 PID: 566 Comm: ifconfig Not tainted 3.13.0-rc6-01523-gf7111b9 #29
[<c001547c>] (unwind_backtrace+0x0/0xf8) from [<c00122dc>]
(show_stack+0x10/0x14)
[<c00122dc>] (show_stack+0x10/0x14) from [<c03c793c>] (dump_stack+0x70/0x88)
[<c03c793c>] (dump_stack+0x70/0x88) from [<c00b2620>] (bad_page+0xc8/0x118)
[<c00b2620>] (bad_page+0xc8/0x118) from [<c00b302c>]
(get_page_from_freelist+0x744/0x870)
[<c00b302c>] (get_page_from_freelist+0x744/0x870) from [<c00b40f4>]
(__alloc_pages_nodemask+0x118/0x86c)
[<c00b40f4>] (__alloc_pages_nodemask+0x118/0x86c) from [<c00b4858>]
(__get_free_pages+0x10/0x54)
[<c00b4858>] (__get_free_pages+0x10/0x54) from [<c00cba1c>]
(kmalloc_order_trace+0x24/0xa0)
[<c00cba1c>] (kmalloc_order_trace+0x24/0xa0) from [<c02d199c>]
(__kmalloc_reserve.isra.21+0x24/0x70)
[<c02d199c>] (__kmalloc_reserve.isra.21+0x24/0x70) from [<c02d240c>]
(__alloc_skb+0x68/0x13c)
[<c02d240c>] (__alloc_skb+0x68/0x13c) from [<c02d3930>]
(__netdev_alloc_skb+0x3c/0xe8)
[<c02d3930>] (__netdev_alloc_skb+0x3c/0xe8) from [<c0279378>]
(stmmac_open+0x63c/0x1024)
[<c0279378>] (stmmac_open+0x63c/0x1024) from [<c02e18cc>]
(__dev_open+0xa0/0xfc)
[<c02e18cc>] (__dev_open+0xa0/0xfc) from [<c02e1b40>]
(__dev_change_flags+0x94/0x158)
[<c02e1b40>] (__dev_change_flags+0x94/0x158) from [<c02e1c24>]
(dev_change_flags+0x18/0x48)
[<c02e1c24>] (dev_change_flags+0x18/0x48) from [<c0337bc0>]
(devinet_ioctl+0x638/0x700)
[<c0337bc0>] (devinet_ioctl+0x638/0x700) from [<c02c7aec>]
(sock_ioctl+0x64/0x290)
[<c02c7aec>] (sock_ioctl+0x64/0x290) from [<c0100890>]
(do_vfs_ioctl+0x78/0x5b8)
[<c0100890>] (do_vfs_ioctl+0x78/0x5b8) from [<c0100e0c>] (SyS_ioctl+0x3c/0x5c)
[<c0100e0c>] (SyS_ioctl+0x3c/0x5c) from [<c000e760>]
The fixes have been verified using reproducible, automated testing.
Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
---
V4: address inconsistency in comment, add comments explaining inconsistent
use of max-frame-size when reading device tree max-frame-size
V3: change snps,max-frame-size to max-frame-size
V2: change snps,max-mtu to snps,max-frame-size
---
drivers/net/ethernet/stmicro/stmmac/common.h | 4 +++-
drivers/net/ethernet/stmicro/stmmac/dwmac1000.h | 7 ++-----
.../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 7 ++++++-
.../net/ethernet/stmicro/stmmac/dwmac100_core.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 11 +++++++----
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 13 +++++++++++++
include/linux/stmmac.h | 1 +
7 files changed, 33 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
index fc94f20..97bfb6b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -293,6 +293,8 @@ struct dma_features {
#define STMMAC_CHAIN_MODE 0x1
#define STMMAC_RING_MODE 0x2
+#define JUMBO_LEN 9000
+
struct stmmac_desc_ops {
/* DMA RX descriptor ring initialization */
void (*init_rx_desc) (struct dma_desc *p, int disable_rx_ic, int mode,
@@ -369,7 +371,7 @@ struct stmmac_dma_ops {
struct stmmac_ops {
/* MAC core initialization */
- void (*core_init) (void __iomem *ioaddr);
+ void (*core_init) (void __iomem *ioaddr, int mtu);
/* Enable and verify that the IPC module is supported */
int (*rx_ipc) (void __iomem *ioaddr);
/* Dump MAC registers */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
index c12aabb..f37d90f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000.h
@@ -126,11 +126,8 @@ enum power_event {
#define GMAC_ANE_PSE (3 << 7)
#define GMAC_ANE_PSE_SHIFT 7
- /* GMAC Configuration defines */
-#define GMAC_CONTROL_TC 0x01000000 /* Transmit Conf. in RGMII/SGMII */
-#define GMAC_CONTROL_WD 0x00800000 /* Disable Watchdog on receive */
-
/* GMAC Configuration defines */
+#define GMAC_CONTROL_2K 0x08000000 /* IEEE 802.3as 2K packets */
#define GMAC_CONTROL_TC 0x01000000 /* Transmit Conf. in RGMII/SGMII */
#define GMAC_CONTROL_WD 0x00800000 /* Disable Watchdog on receive */
#define GMAC_CONTROL_JD 0x00400000 /* Jabber disable */
@@ -156,7 +153,7 @@ enum inter_frame_gap {
#define GMAC_CONTROL_RE 0x00000004 /* Receiver Enable */
#define GMAC_CORE_INIT (GMAC_CONTROL_JD | GMAC_CONTROL_PS | GMAC_CONTROL_ACS | \
- GMAC_CONTROL_JE | GMAC_CONTROL_BE)
+ GMAC_CONTROL_BE)
/* GMAC Frame Filter defines */
#define GMAC_FRAME_FILTER_PR 0x00000001 /* Promiscuous Mode */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index cdd9268..b3e148e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -32,10 +32,15 @@
#include <asm/io.h>
#include "dwmac1000.h"
-static void dwmac1000_core_init(void __iomem *ioaddr)
+static void dwmac1000_core_init(void __iomem *ioaddr, int mtu)
{
u32 value = readl(ioaddr + GMAC_CONTROL);
value |= GMAC_CORE_INIT;
+ if (mtu > 1500)
+ value |= GMAC_CONTROL_2K;
+ if (mtu > 2000)
+ value |= GMAC_CONTROL_JE;
+
writel(value, ioaddr + GMAC_CONTROL);
/* Mask GMAC interrupts */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
index 5857d67..2ff767b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
@@ -32,7 +32,7 @@
#include <asm/io.h>
#include "dwmac100.h"
-static void dwmac100_core_init(void __iomem *ioaddr)
+static void dwmac100_core_init(void __iomem *ioaddr, int mtu)
{
u32 value = readl(ioaddr + MAC_CONTROL);
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index ecdc8ab..58f7744 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -52,7 +52,6 @@
#include "stmmac.h"
#define STMMAC_ALIGN(x) L1_CACHE_ALIGN(x)
-#define JUMBO_LEN 9000
/* Module parameters */
#define TX_TIMEO 5000
@@ -91,7 +90,7 @@ static int tc = TC_DEFAULT;
module_param(tc, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(tc, "DMA threshold control value");
-#define DMA_BUFFER_SIZE BUF_SIZE_2KiB
+#define DMA_BUFFER_SIZE BUF_SIZE_4KiB
static int buf_sz = DMA_BUFFER_SIZE;
module_param(buf_sz, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(buf_sz, "DMA buffer size");
@@ -990,6 +989,8 @@ static int init_dma_desc_rings(struct net_device *dev)
if (bfsize < BUF_SIZE_16KiB)
bfsize = stmmac_set_bfsize(dev->mtu, priv->dma_buf_sz);
+ priv->dma_buf_sz = bfsize;
+
if (netif_msg_probe(priv))
pr_debug("%s: txsize %d, rxsize %d, bfsize %d\n", __func__,
txsize, rxsize, bfsize);
@@ -1079,7 +1080,6 @@ static int init_dma_desc_rings(struct net_device *dev)
}
priv->cur_rx = 0;
priv->dirty_rx = (unsigned int)(i - rxsize);
- priv->dma_buf_sz = bfsize;
buf_sz = bfsize;
/* Setup the chained descriptor addresses */
@@ -1642,7 +1642,7 @@ static int stmmac_open(struct net_device *dev)
priv->plat->bus_setup(priv->ioaddr);
/* Initialize the MAC Core */
- priv->hw->mac->core_init(priv->ioaddr);
+ priv->hw->mac->core_init(priv->ioaddr, dev->mtu);
/* Request the IRQ lines */
ret = request_irq(dev->irq, stmmac_interrupt,
@@ -2248,6 +2248,9 @@ static int stmmac_change_mtu(struct net_device *dev, int new_mtu)
else
max_mtu = SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN);
+ if (priv->plat->maxmtu < max_mtu)
+ max_mtu = priv->plat->maxmtu;
+
if ((new_mtu < 46) || (new_mtu > max_mtu)) {
pr_err("%s: invalid MTU, max MTU is: %d\n", dev->name, max_mtu);
return -EINVAL;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 38bd1f4..48ec035 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -52,6 +52,11 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
sizeof(struct stmmac_mdio_bus_data),
GFP_KERNEL);
+ /* Set the maxmtu to a default of JUMBO_LEN in case the
+ * parameter is not present in the device tree.
+ */
+ plat->maxmtu = JUMBO_LEN;
+
/*
* Currently only the properties needed on SPEAr600
* are provided. All other properties should be added
@@ -60,6 +65,14 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
if (of_device_is_compatible(np, "st,spear600-gmac") ||
of_device_is_compatible(np, "snps,dwmac-3.70a") ||
of_device_is_compatible(np, "snps,dwmac")) {
+ /* Note that the max-frame-size parameter as defined in the
+ * ePAPR v1.1 spec is defined as max-frame-size, it's
+ * actually used as the IEEE definition of MAC Client
+ * data, or MTU. The ePAPR specification is confusing as
+ * the definition is max-frame-size, but usage examples
+ * are clearly MTUs
+ */
+ of_property_read_u32(np, "max-frame-size", &plat->maxmtu);
plat->has_gmac = 1;
plat->pmt = 1;
}
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index bb5deb0..9689706 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -110,6 +110,7 @@ struct plat_stmmacenet_data {
int force_sf_dma_mode;
int force_thresh_dma_mode;
int riwt_off;
+ int maxmtu;
void (*fix_mac_speed)(void *priv, unsigned int speed);
void (*bus_setup)(void __iomem *ioaddr);
int (*init)(struct platform_device *pdev);
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next v4 1/2] dts: Add a binding for Synopsys emac max-frame-size
From: Vince Bridgers @ 2014-01-16 14:05 UTC (permalink / raw)
To: devicetree, netdev
Cc: peppe.cavallaro, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, dinguyen, rayagond, vbridgers2013
In-Reply-To: <1389881155-9758-1-git-send-email-vbridgers2013@gmail.com>
This change adds a parameter for the Synopsys 10/100/1000
stmmac Ethernet driver to configure the maximum frame
size supported by the EMAC driver. Synopsys allows the FIFO
sizes to be configured when the cores are built for a particular
device, but do not provide a way for the driver to read
information from the device about the maximum MTU size
supported as limited by the device's FIFO size.
Signed-off-by: Vince Bridgers <vbridgers2013@gmail.com>
---
V4: add comments to explain use of max-frame-size with respect
to inconsistent definition and use in the ePAPR v1.1 spec
V3: change snps,max-frame-size to max-frame-size
V2: change snps,max-mtu to snps,max-frame-size
---
Documentation/devicetree/bindings/net/stmmac.txt | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index eba0e5e..d553be2 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -29,7 +29,17 @@ Required properties:
ignored if force_thresh_dma_mode is set.
Optional properties:
-- mac-address: 6 bytes, mac address
+- mac-address: 6 bytes, mac address
+- max-frame-size: Maximum frame size permitted. This parameter is useful
+ since different implementations of the Synopsys MAC may
+ have different FIFO sizes depending on the selections
+ made in Synopsys Core Consultant. Note that the usage
+ is inconsistent with the definition in the ePAPR v1.1
+ specification, as it defines max-frame-size inclusive
+ of the MAC DA, SA, Ethertype and CRC while usage is
+ consistent with the IEEE definition of MAC Client
+ Data, which is sans the MAC DA, SA, Ethertype and
+ CRC.
Examples:
@@ -40,5 +50,6 @@ Examples:
interrupts = <24 23>;
interrupt-names = "macirq", "eth_wake_irq";
mac-address = [000000000000]; /* Filled in by U-Boot */
+ max-frame-size = <3800>;
phy-mode = "gmii";
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next v4 0/2] stmmac: fix kernel crashes for jumbo frames
From: Vince Bridgers @ 2014-01-16 14:05 UTC (permalink / raw)
To: devicetree, netdev
Cc: peppe.cavallaro, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, dinguyen, rayagond, vbridgers2013
v4:
* Address inconsistent comment with use, add comments about inconsistency
of max-frame-size definition and use in the ePAPR v1.1 specification.
v3:
* change snps,max-frame-size to max-frame-size
v2:
* change snps,max-mtu to snps,max-frame-size
These patches address two kernel crashes seen when using jumbo frames on
the Synopsys stmmac driver, and adds device tree configurability for the
maximum mtu. The Synopsys emac fifo sizes can be configured when a logic
design is synthesized, but does not provide a way for a driver to query the
exact fifo size.
The crashes seen were due to two issues.
1) The dma buffer size was being set after the dma buffers were allocated.
This caused a crash when changing the mtu since it was possible the buffers
would subsequently be freed using an incorrect dma buffer size. This could
also cause kernel panics due to memory corruption since a large mtu size could
have been configured, but the dma buffers were not sized accordingly.
2) Jumbo frames were being enabled by default, but the dma buffers were not
sized accordingly. This caused memory corruption in the context of certain
types of network traffic, leading to kernel panics.
I've tested these changes using automated, reproducible testware. I can
demonstrate the panics described before the fixes and show that the fixes
address the problems described.
Testing and improvements continue through the use of the mentioned automated
and reproducible testware.
Vince Bridgers
Vince Bridgers (2):
dts: Add a binding for Synopsys emac max-frame-size
stmmac: Fix kernel crashes for jumbo frames
Documentation/devicetree/bindings/net/stmmac.txt | 13 ++++++++++++-
drivers/net/ethernet/stmicro/stmmac/common.h | 4 +++-
drivers/net/ethernet/stmicro/stmmac/dwmac1000.h | 7 ++-----
.../net/ethernet/stmicro/stmmac/dwmac1000_core.c | 7 ++++++-
.../net/ethernet/stmicro/stmmac/dwmac100_core.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 11 +++++++----
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 13 +++++++++++++
include/linux/stmmac.h | 1 +
8 files changed, 45 insertions(+), 13 deletions(-)
--
1.7.9.5
^ permalink raw reply
* Re: ipv6 addrconfg warn_on hit: WARN_ON(ifp->idev->valid_ll_addr_cnt < 0);
From: Jiri Pirko @ 2014-01-16 14:07 UTC (permalink / raw)
To: hannes; +Cc: netdev
In-Reply-To: <20140116135323.GA7961@minipsycho.orion>
Thu, Jan 16, 2014 at 02:53:23PM CET, jiri@resnulli.us wrote:
>Hi Hannes.
>
>WARN_ON(ifp->idev->valid_ll_addr_cnt < 0);
>
>We did hit once this warning during the tests. The person who hit this
>says that it was during the setup of many macvlan devices.
>
>I examined the code but I'm not sure how this could happen. Looks like a
>race condition between addrconf_dad_completed() and addrconf_ifdown().
>Not sure how to easily resolve that though.
>
>Would you please take a look?
>
>Thanks!
>
>Jiri
[16661.669422] Call Trace:
[16661.684417] [<ffffffff815b4dde>] dump_stack+0x19/0x1b
[16661.714596] [<ffffffff81058bd1>] warn_slowpath_common+0x61/0x80
[16661.748587] [<ffffffff81058caa>] warn_slowpath_null+0x1a/0x20
[16661.780334] [<ffffffff81551e1a>] update_valid_ll_addr_cnt+0x9a/0xa0
[16661.816145] [<ffffffff81555ca5>] __ipv6_ifa_notify+0xb5/0x2e0
[16661.849222] [<ffffffff8155819e>] addrconf_ifdown+0x21e/0x3e0
[16661.880245] [<ffffffff815594be>] addrconf_notify+0x5e/0x430
[16661.912233] [<ffffffff815662ce>] ? ndisc_netdev_event+0x4e/0x100
[16661.945485] [<ffffffff815c064c>] notifier_call_chain+0x4c/0x70
[16661.979227] [<ffffffff81084756>] raw_notifier_call_chain+0x16/0x20
[16662.013434] [<ffffffff814a5fad>] call_netdevice_notifiers+0x2d/0x60
[16662.051709] [<ffffffff814a6217>] dev_close_many+0xb7/0x100
[16662.084728] [<ffffffff814a62c0>] dev_close+0x60/0x80
[16662.114689] [<ffffffff814a9134>] dev_change_net_namespace+0x94/0x220
[16662.152638] [<ffffffff814ba043>] do_setlink+0x83/0x9f0
[16662.183447] [<ffffffff812bae36>] ? nla_parse+0x96/0xe0
[16662.214146] [<ffffffff814bb614>] rtnl_newlink+0x394/0x5e0
[16662.247097] [<ffffffff8123cc0e>] ? selinux_capable+0x2e/0x40
[16662.281035] [<ffffffff814b8009>] rtnetlink_rcv_msg+0x99/0x260
[16662.313053] [<ffffffff81239e25>] ? sock_has_perm+0x75/0x90
[16662.344678] [<ffffffff814b7f70>] ? rtnetlink_rcv+0x30/0x30
[16662.375627] [<ffffffff814d6fc9>] netlink_rcv_skb+0xa9/0xc0
[16662.409066] [<ffffffff814b7f68>] rtnetlink_rcv+0x28/0x30
[16662.438982] [<ffffffff814d662d>] netlink_unicast+0xdd/0x190
[16662.470946] [<ffffffff814d69df>] netlink_sendmsg+0x2ff/0x730
[16662.502797] [<ffffffff81493289>] sock_sendmsg+0x99/0xd0
[16662.532625] [<ffffffff8149367c>] ___sys_sendmsg+0x36c/0x380
[16662.564507] [<ffffffff8149b329>] ? skb_dequeue+0x59/0x70
[16662.596497] [<ffffffff8115d4b5>] ? handle_mm_fault+0x285/0x3a0
[16662.631456] [<ffffffff815c0174>] ? __do_page_fault+0x1f4/0x510
[16662.666968] [<ffffffff811b3a85>] ? d_free+0x55/0x60
[16662.695923] [<ffffffff811bcc1e>] ? mntput_no_expire+0x3e/0x120
[16662.731922] [<ffffffff811bcd24>] ? mntput+0x24/0x40
[16662.761353] [<ffffffff8119f823>] ? __fput+0x183/0x270
[16662.792218] [<ffffffff81494462>] __sys_sendmsg+0x42/0x80
[16662.824368] [<ffffffff814944b2>] SyS_sendmsg+0x12/0x20
[16662.855854] [<ffffffff815c4c99>] system_call_fastpath+0x16/0x1b
[16662.892006] ---[ end trace 9f96f71eeb981f7e ]---
^ permalink raw reply
* I need your trust reply.
From: Zakan M @ 2014-01-16 13:24 UTC (permalink / raw)
Dear Friend,
I am contacting you to assist me in a transaction of 6,200,000.00 U.S dollars to be transferred out from my bank. This transaction is confidential and 100% genuine, so we MUST remain fiducially in all our dealings since i cannot complete the transaction alone without the help of a foreigner. Therefore, I am contacting you in this business for the benefit of both of us and kindly reply me on this E-Mail ID zak001m@terra.com for confidential reasons.
Upon achieving this goal you will be entitled to 30% of the total sum and 70% will be mine. So kindly indicate your full interest on assurance of trust to enable me give you full details and how this transaction will be executed. I look forward to hear from you soon.
Best regards,
Mr. Zakan .M.
^ permalink raw reply
* Re: [PATCH] net/dt: Add support for overriding phy configuration from device tree
From: Gerhard Sittig @ 2014-01-16 13:59 UTC (permalink / raw)
To: Matthew Garrett; +Cc: netdev, devicetree, linux-kernel, kishon
In-Reply-To: <1389821938-3126-1-git-send-email-matthew.garrett@nebula.com>
On Wed, Jan 15, 2014 at 16:38 -0500, Matthew Garrett wrote:
>
> Some hardware may be broken in interesting and board-specific ways, such
> that various bits of functionality don't work. This patch provides a
> mechanism for overriding mii registers during init based on the contents of
> the device tree data, allowing board-specific fixups without having to
> pollute generic code.
>
> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
> ---
> Documentation/devicetree/bindings/net/phy.txt | 13 +++
> drivers/net/phy/phy_device.c | 29 +++++-
> drivers/of/of_net.c | 124 ++++++++++++++++++++++++++
> include/linux/of_net.h | 12 +++
> 4 files changed, 177 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
> index 7cd18fb..552a5e0 100644
> --- a/Documentation/devicetree/bindings/net/phy.txt
> +++ b/Documentation/devicetree/bindings/net/phy.txt
> @@ -23,6 +23,19 @@ Optional Properties:
> assume clause 22. The compatible list may also contain other
> elements.
>
> +The following properties may be added to either the phy node or the parent
> +ethernet device:
> +
> +- phy-mii-advertise-10half: Whether to advertise half-duplex 10MBit
> +- phy-mii-advertise-10full: Whether to advertise full-duplex 10MBit
> +- phy-mii-advertise-100half: Whether to advertise half-duplex 100MBit
> +- phy-mii-advertise-100full: Whether to advertise full-duplex 100MBit
> +- phy-mii-advertise-100base4: Whether to advertise 100base4
> +- phy-mii-advertise-1000half: Whether to advertise half-duplex 1000MBit
> +- phy-mii-advertise-1000full: Whether to advertise full-duplex 1000MBit
> +- phy-mii-as-master: Configure phy to act as master/slave
> +- phy-mii-manual-master: Enable/disable manual master/slave configuration
> +
> Example:
>
> ethernet-phy@0 {
These properties are booleans, and optional? Does it mean that
you cannot _disable_ broken features? Or does it mean that you
_must_ specify the non-broken features and thus break backwards
compatibility? Or are these properties not boolean (they are not
used in the example either, unfortunately), and the binding text
would need an update for clarity? What am I missing?
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* ipv6 addrconfg warn_on hit: WARN_ON(ifp->idev->valid_ll_addr_cnt < 0);
From: Jiri Pirko @ 2014-01-16 13:53 UTC (permalink / raw)
To: hannes; +Cc: netdev
Hi Hannes.
WARN_ON(ifp->idev->valid_ll_addr_cnt < 0);
We did hit once this warning during the tests. The person who hit this
says that it was during the setup of many macvlan devices.
I examined the code but I'm not sure how this could happen. Looks like a
race condition between addrconf_dad_completed() and addrconf_ifdown().
Not sure how to easily resolve that though.
Would you please take a look?
Thanks!
Jiri
^ permalink raw reply
* Re: [Xen-devel][PATCH net-next v2] xen-netfront: clean up code in xennet_release_rx_bufs
From: annie li @ 2014-01-16 13:42 UTC (permalink / raw)
To: David Vrabel
Cc: xen-devel, netdev, davem, konrad.wilk, ian.campbell, wei.liu2,
andrew.bennieston
In-Reply-To: <52D7BE19.2010009@citrix.com>
On 2014-1-16 19:10, David Vrabel wrote:
> On 15/01/14 23:57, Annie Li wrote:
>> This patch implements two things:
>>
>> * release grant reference and skb for rx path, this fixex resource leaking.
>> * clean up grant transfer code kept from old netfront(2.6.18) which grants
>> pages for access/map and transfer. But grant transfer is deprecated in current
>> netfront, so remove corresponding release code for transfer.
>>
>> gnttab_end_foreign_access_ref may fail when the grant entry is currently used
>> for reading or writing. But this patch does not cover this and improvement for
>> this failure may be implemented in a separate patch.
> I don't think replacing a resource leak with a security bug is a good idea.
>
> If you would prefer not to fix the gnttab_end_foreign_access() call, I
> think you can fix this in netfront by taking a reference to the page
> before calling gnttab_end_foreign_access(). This will ensure the page
> isn't freed until the subsequent kfree_skb(), or the gref is released by
> the foreign domain (whichever is later).
What I thought is to split the implementation into two patches, this
patch fixes the rx path resource leak(just like what tx path does), then
a separate patch fixes gnttab_end_foreign_access_ref failure issue for
both tx/rx through taking reference to the page before
gnttab_end_foreign_access.
If you'd like they are posted together, I will create new patch for the
latter and then post them.:-)
Thanks
Annie
^ permalink raw reply
* Re: [PATCH v4 0/2] ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of IP6 routes
From: Hannes Frederic Sowa @ 2014-01-16 13:38 UTC (permalink / raw)
To: David Miller; +Cc: jiri, thaller, netdev, stephen, dcbw
In-Reply-To: <20140115.135328.514671277431781958.davem@davemloft.net>
On Wed, Jan 15, 2014 at 01:53:28PM -0800, David Miller wrote:
> From: Jiri Pirko <jiri@resnulli.us>
> Date: Mon, 13 Jan 2014 16:31:10 +0100
>
> > Sat, Jan 11, 2014 at 12:10:30AM CET, davem@davemloft.net wrote:
> >>From: Thomas Haller <thaller@redhat.com>
> >>Date: Thu, 9 Jan 2014 01:30:02 +0100
> >>
> >>> v1 -> v2: add a second commit, handling NOPREFIXROUTE in ip6_del_addr.
> >>> v2 -> v3: reword commit messages, code comments and some refactoring.
> >>> v3 -> v4: refactor, rename variables, add enum
> >>>
> >>> Thomas Haller (2):
> >>> ipv6 addrconf: add IFA_F_NOPREFIXROUTE flag to suppress creation of
> >>> IP6 routes
> >>> ipv6 addrconf: don't cleanup prefix route for IFA_F_NOPREFIXROUTE
> >>
> >>Series applied, thanks Thomas.
> >
> > Hi Dave. Have you pushed this already? I can't see these patches in
> > net-next.
>
> Sorry, I must have forgotten to push these changes out before I travelled
> on Saturday.
>
> Please respin and resubmit and I'll make sure they get integrated properly.
Just fyi, I noticed at least one other patch missing from the repos:
http://patchwork.ozlabs.org/patch/308452/
Greetings,
Hannes
^ permalink raw reply
* Re: unable to send TCP SYNs from ports below 1024
From: Stuart Kendrick @ 2014-01-16 13:37 UTC (permalink / raw)
To: Stuart Kendrick, netdev
In-Reply-To: <20140115114715.GC19945@order.stressinduktion.org>
I hadn't thought of the switch. And inserting an in-line tap on
either side of the switch ... shows that it is dropping these frames.
Thanx for the suggestion,
--sk
^ permalink raw reply
* Re: [Patch net-next] net_sched: act: remove capab from struct tc_action_ops
From: Jamal Hadi Salim @ 2014-01-16 13:30 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: David S. Miller
In-Reply-To: <1389829770-811-1-git-send-email-xiyou.wangcong@gmail.com>
On 01/15/14 18:49, Cong Wang wrote:
> It is not actually implemented.
Why dont you do something more useful like allow user to
query capability?
If that doesnt make sense - lets talk offline.
cheers,
jamal
>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> include/net/act_api.h | 2 --
> net/sched/act_csum.c | 1 -
> net/sched/act_gact.c | 1 -
> net/sched/act_ipt.c | 2 --
> net/sched/act_mirred.c | 1 -
> net/sched/act_nat.c | 1 -
> net/sched/act_pedit.c | 1 -
> net/sched/act_police.c | 1 -
> net/sched/act_simple.c | 1 -
> net/sched/act_skbedit.c | 1 -
> 10 files changed, 12 deletions(-)
>
> diff --git a/include/net/act_api.h b/include/net/act_api.h
> index e171387..8ed9746 100644
> --- a/include/net/act_api.h
> +++ b/include/net/act_api.h
> @@ -81,13 +81,11 @@ struct tc_action {
> struct list_head list;
> };
>
> -#define TCA_CAP_NONE 0
> struct tc_action_ops {
> struct list_head head;
> struct tcf_hashinfo *hinfo;
> char kind[IFNAMSIZ];
> __u32 type; /* TBD to match kind */
> - __u32 capab; /* capabilities includes 4 bit version */
> struct module *owner;
> int (*act)(struct sk_buff *, const struct tc_action *, struct tcf_result *);
> int (*dump)(struct sk_buff *, struct tc_action *, int, int);
> diff --git a/net/sched/act_csum.c b/net/sched/act_csum.c
> index ee28e1c..9d5c1d3 100644
> --- a/net/sched/act_csum.c
> +++ b/net/sched/act_csum.c
> @@ -572,7 +572,6 @@ static struct tc_action_ops act_csum_ops = {
> .kind = "csum",
> .hinfo = &csum_hash_info,
> .type = TCA_ACT_CSUM,
> - .capab = TCA_CAP_NONE,
> .owner = THIS_MODULE,
> .act = tcf_csum,
> .dump = tcf_csum_dump,
> diff --git a/net/sched/act_gact.c b/net/sched/act_gact.c
> index 3133307..72c49de 100644
> --- a/net/sched/act_gact.c
> +++ b/net/sched/act_gact.c
> @@ -194,7 +194,6 @@ static struct tc_action_ops act_gact_ops = {
> .kind = "gact",
> .hinfo = &gact_hash_info,
> .type = TCA_ACT_GACT,
> - .capab = TCA_CAP_NONE,
> .owner = THIS_MODULE,
> .act = tcf_gact,
> .dump = tcf_gact_dump,
> diff --git a/net/sched/act_ipt.c b/net/sched/act_ipt.c
> index bc9f498..67d701e 100644
> --- a/net/sched/act_ipt.c
> +++ b/net/sched/act_ipt.c
> @@ -287,7 +287,6 @@ static struct tc_action_ops act_ipt_ops = {
> .kind = "ipt",
> .hinfo = &ipt_hash_info,
> .type = TCA_ACT_IPT,
> - .capab = TCA_CAP_NONE,
> .owner = THIS_MODULE,
> .act = tcf_ipt,
> .dump = tcf_ipt_dump,
> @@ -299,7 +298,6 @@ static struct tc_action_ops act_xt_ops = {
> .kind = "xt",
> .hinfo = &ipt_hash_info,
> .type = TCA_ACT_XT,
> - .capab = TCA_CAP_NONE,
> .owner = THIS_MODULE,
> .act = tcf_ipt,
> .dump = tcf_ipt_dump,
> diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
> index 5d05b57..376234e 100644
> --- a/net/sched/act_mirred.c
> +++ b/net/sched/act_mirred.c
> @@ -257,7 +257,6 @@ static struct tc_action_ops act_mirred_ops = {
> .kind = "mirred",
> .hinfo = &mirred_hash_info,
> .type = TCA_ACT_MIRRED,
> - .capab = TCA_CAP_NONE,
> .owner = THIS_MODULE,
> .act = tcf_mirred,
> .dump = tcf_mirred_dump,
> diff --git a/net/sched/act_nat.c b/net/sched/act_nat.c
> index a49fa23..46e1aa3 100644
> --- a/net/sched/act_nat.c
> +++ b/net/sched/act_nat.c
> @@ -296,7 +296,6 @@ static struct tc_action_ops act_nat_ops = {
> .kind = "nat",
> .hinfo = &nat_hash_info,
> .type = TCA_ACT_NAT,
> - .capab = TCA_CAP_NONE,
> .owner = THIS_MODULE,
> .act = tcf_nat,
> .dump = tcf_nat_dump,
> diff --git a/net/sched/act_pedit.c b/net/sched/act_pedit.c
> index f361e4e..109265d 100644
> --- a/net/sched/act_pedit.c
> +++ b/net/sched/act_pedit.c
> @@ -233,7 +233,6 @@ static struct tc_action_ops act_pedit_ops = {
> .kind = "pedit",
> .hinfo = &pedit_hash_info,
> .type = TCA_ACT_PEDIT,
> - .capab = TCA_CAP_NONE,
> .owner = THIS_MODULE,
> .act = tcf_pedit,
> .dump = tcf_pedit_dump,
> diff --git a/net/sched/act_police.c b/net/sched/act_police.c
> index a719fdf..7fd0993 100644
> --- a/net/sched/act_police.c
> +++ b/net/sched/act_police.c
> @@ -385,7 +385,6 @@ static struct tc_action_ops act_police_ops = {
> .kind = "police",
> .hinfo = &police_hash_info,
> .type = TCA_ID_POLICE,
> - .capab = TCA_CAP_NONE,
> .owner = THIS_MODULE,
> .act = tcf_act_police,
> .dump = tcf_act_police_dump,
> diff --git a/net/sched/act_simple.c b/net/sched/act_simple.c
> index f7d5406..92236da 100644
> --- a/net/sched/act_simple.c
> +++ b/net/sched/act_simple.c
> @@ -190,7 +190,6 @@ static struct tc_action_ops act_simp_ops = {
> .kind = "simple",
> .hinfo = &simp_hash_info,
> .type = TCA_ACT_SIMP,
> - .capab = TCA_CAP_NONE,
> .owner = THIS_MODULE,
> .act = tcf_simp,
> .dump = tcf_simp_dump,
> diff --git a/net/sched/act_skbedit.c b/net/sched/act_skbedit.c
> index 74af461..c36b520 100644
> --- a/net/sched/act_skbedit.c
> +++ b/net/sched/act_skbedit.c
> @@ -189,7 +189,6 @@ static struct tc_action_ops act_skbedit_ops = {
> .kind = "skbedit",
> .hinfo = &skbedit_hash_info,
> .type = TCA_ACT_SKBEDIT,
> - .capab = TCA_CAP_NONE,
> .owner = THIS_MODULE,
> .act = tcf_skbedit,
> .dump = tcf_skbedit_dump,
>
^ permalink raw reply
* Re: [Patch net-next] net_sched: act: pick a different type for act_xt
From: Jamal Hadi Salim @ 2014-01-16 13:28 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: David S. Miller
In-Reply-To: <1389829123-22914-1-git-send-email-xiyou.wangcong@gmail.com>
On 01/15/14 18:38, Cong Wang wrote:
> In tcf_register_action() we check either ->type or ->kind to see if
> there is an existing action registered, but ipt action registers two
> actions with same type but different kinds. They should have different
> types too.
>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
> ---
> include/uapi/linux/tc_act/tc_ipt.h | 1 +
> net/sched/act_ipt.c | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/tc_act/tc_ipt.h b/include/uapi/linux/tc_act/tc_ipt.h
> index a233556..130aaad 100644
> --- a/include/uapi/linux/tc_act/tc_ipt.h
> +++ b/include/uapi/linux/tc_act/tc_ipt.h
> @@ -4,6 +4,7 @@
> #include <linux/pkt_cls.h>
>
> #define TCA_ACT_IPT 6
> +#define TCA_ACT_XT 10
>
> enum {
> TCA_IPT_UNSPEC,
> diff --git a/net/sched/act_ipt.c b/net/sched/act_ipt.c
> index 484bd19..bc9f498 100644
> --- a/net/sched/act_ipt.c
> +++ b/net/sched/act_ipt.c
> @@ -298,7 +298,7 @@ static struct tc_action_ops act_ipt_ops = {
> static struct tc_action_ops act_xt_ops = {
> .kind = "xt",
> .hinfo = &ipt_hash_info,
> - .type = TCA_ACT_IPT,
> + .type = TCA_ACT_XT,
> .capab = TCA_CAP_NONE,
> .owner = THIS_MODULE,
> .act = tcf_ipt,
>
^ permalink raw reply
* Re: [Patch net-next] net_sched: act: use tcf_hash_release() in net/sched/act_police.c
From: Jamal Hadi Salim @ 2014-01-16 13:25 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: David S. Miller
In-Reply-To: <1389828206-9467-1-git-send-email-xiyou.wangcong@gmail.com>
On 01/15/14 18:23, Cong Wang wrote:
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
> ---
> net/sched/act_police.c | 30 +++---------------------------
> 1 file changed, 3 insertions(+), 27 deletions(-)
>
> diff --git a/net/sched/act_police.c b/net/sched/act_police.c
> index a719fdf..5ba467b 100644
> --- a/net/sched/act_police.c
> +++ b/net/sched/act_police.c
> @@ -104,20 +104,6 @@ nla_put_failure:
> goto done;
> }
>
> -static void tcf_police_destroy(struct tcf_police *p)
> -{
> - spin_lock_bh(&police_hash_info.lock);
> - hlist_del(&p->tcf_head);
> - spin_unlock_bh(&police_hash_info.lock);
> - gen_kill_estimator(&p->tcf_bstats,
> - &p->tcf_rate_est);
> - /*
> - * gen_estimator est_timer() might access p->tcf_lock
> - * or bstats, wait a RCU grace period before freeing p
> - */
> - kfree_rcu(p, tcf_rcu);
> -}
> -
> static const struct nla_policy police_policy[TCA_POLICE_MAX + 1] = {
> [TCA_POLICE_RATE] = { .len = TC_RTAB_SIZE },
> [TCA_POLICE_PEAKRATE] = { .len = TC_RTAB_SIZE },
> @@ -272,19 +258,9 @@ failure:
> static int tcf_act_police_cleanup(struct tc_action *a, int bind)
> {
> struct tcf_police *p = a->priv;
> - int ret = 0;
> -
> - if (p != NULL) {
> - if (bind)
> - p->tcf_bindcnt--;
> -
> - p->tcf_refcnt--;
> - if (p->tcf_refcnt <= 0 && !p->tcf_bindcnt) {
> - tcf_police_destroy(p);
> - ret = 1;
> - }
> - }
> - return ret;
> + if (p)
> + return tcf_hash_release(&p->common, bind, &police_hash_info);
> + return 0;
> }
>
> static int tcf_act_police(struct sk_buff *skb, const struct tc_action *a,
>
^ permalink raw reply
* Re: [PATCH V2 net-next 1/3] ipv6: add the IPV6_FL_F_REFLECT flag to IPV6_FL_A_GET
From: Hannes Frederic Sowa @ 2014-01-16 13:07 UTC (permalink / raw)
To: Florent Fourcot; +Cc: netdev
In-Reply-To: <52D7D45E.6000908@enst-bretagne.fr>
On Thu, Jan 16, 2014 at 01:45:18PM +0100, Florent Fourcot wrote:
>
> >> Was there a specific reason you did not use np->flow_label here and just
> >> mirroring the flowlabel from the first packet of the connection for the
> >> whole connection?
> >>
> >> I don't know if it makes a difference, but maybe it was done on purpose?
> >
> > I thought about it and am actually in favor of reusing the flowid from the syn
> > packet so userspace does report correct outgoing flowlabel even in case of
> > strange tcp peer changing it mid-stream.
> >
>
> Actually, the idea was that the remote could changed the flow label
> during the lifetime of a connection.
> I do not have a strong opinion on that, but in a "reflect" mode, I
> except that the last received value will be in used.
Would it make sense to sync the flowlabel if it changes with the socket, so
user space can query the label really used? Otherwise I wouldn't even report
it.
> Second, in case of SYN cookie, is the SYN flow label stored somewhere?
Should then be synced as soon as the cookie is validated. You can test it by
setting tcp_syncookies to 2. It uses syncookies unconditionally then.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH V2 net-next 1/3] ipv6: add the IPV6_FL_F_REFLECT flag to IPV6_FL_A_GET
From: Florent Fourcot @ 2014-01-16 12:45 UTC (permalink / raw)
To: netdev, Hannes Frederic Sowa
In-Reply-To: <20140116123515.GD7436@order.stressinduktion.org>
>> Was there a specific reason you did not use np->flow_label here and just
>> mirroring the flowlabel from the first packet of the connection for the
>> whole connection?
>>
>> I don't know if it makes a difference, but maybe it was done on purpose?
>
> I thought about it and am actually in favor of reusing the flowid from the syn
> packet so userspace does report correct outgoing flowlabel even in case of
> strange tcp peer changing it mid-stream.
>
Actually, the idea was that the remote could changed the flow label
during the lifetime of a connection.
I do not have a strong opinion on that, but in a "reflect" mode, I
except that the last received value will be in used.
Second, in case of SYN cookie, is the SYN flow label stored somewhere?
Thanks,
Florent.
^ permalink raw reply
* [PATCH] e1000e: Fix compilation warning when !CONFIG_PM_SLEEP
From: Mika Westerberg @ 2014-01-16 12:39 UTC (permalink / raw)
To: Dave Ertman
Cc: Aaron Brown, Jeff Kirsher, Bruce Allan, David S. Miller,
Mika Westerberg, netdev
Commit 7509963c703b (e1000e: Fix a compile flag mis-match for
suspend/resume) moved suspend and resume hooks to be available when
CONFIG_PM is set. However, it can be set even if CONFIG_PM_SLEEP is not set
causing following warnings to be emitted:
drivers/net/ethernet/intel/e1000e/netdev.c:6178:12: warning:
‘e1000_suspend’ defined but not used [-Wunused-function]
drivers/net/ethernet/intel/e1000e/netdev.c:6185:12: warning:
‘e1000_resume’ defined but not used [-Wunused-function]
To fix this make the hooks to be available only when CONFIG_PM_SLEEP is set
and remove CONFIG_PM wrapping from driver ops because this is already
handled by SET_SYSTEM_SLEEP_PM_OPS() and SET_RUNTIME_PM_OPS().
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Dave Ertman <davidx.m.ertman@intel.com>
Cc: Aaron Brown <aaron.f.brown@intel.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index c30d41d6e426..6d14eea17918 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6174,7 +6174,7 @@ static int __e1000_resume(struct pci_dev *pdev)
return 0;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int e1000_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
@@ -6193,7 +6193,7 @@ static int e1000_resume(struct device *dev)
return __e1000_resume(pdev);
}
-#endif /* CONFIG_PM */
+#endif /* CONFIG_PM_SLEEP */
#ifdef CONFIG_PM_RUNTIME
static int e1000_runtime_suspend(struct device *dev)
@@ -7015,13 +7015,11 @@ static DEFINE_PCI_DEVICE_TABLE(e1000_pci_tbl) = {
};
MODULE_DEVICE_TABLE(pci, e1000_pci_tbl);
-#ifdef CONFIG_PM
static const struct dev_pm_ops e1000_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(e1000_suspend, e1000_resume)
SET_RUNTIME_PM_OPS(e1000_runtime_suspend, e1000_runtime_resume,
e1000_idle)
};
-#endif
/* PCI Device API Driver */
static struct pci_driver e1000_driver = {
@@ -7029,11 +7027,9 @@ static struct pci_driver e1000_driver = {
.id_table = e1000_pci_tbl,
.probe = e1000_probe,
.remove = e1000_remove,
-#ifdef CONFIG_PM
.driver = {
.pm = &e1000_pm_ops,
},
-#endif
.shutdown = e1000_shutdown,
.err_handler = &e1000_err_handler
};
--
1.8.5.2
^ permalink raw reply related
* Re: [PATCH V2 net-next 1/3] ipv6: add the IPV6_FL_F_REFLECT flag to IPV6_FL_A_GET
From: Hannes Frederic Sowa @ 2014-01-16 12:35 UTC (permalink / raw)
To: Florent Fourcot, netdev
In-Reply-To: <20140115224726.GH19945@order.stressinduktion.org>
On Wed, Jan 15, 2014 at 11:47:26PM +0100, Hannes Frederic Sowa wrote:
> > @@ -1138,6 +1142,8 @@ static struct sock *tcp_v6_syn_recv_sock(struct sock *sk, struct sk_buff *skb,
> > newnp->mcast_oif = inet6_iif(skb);
> > newnp->mcast_hops = ipv6_hdr(skb)->hop_limit;
> > newnp->rcv_flowinfo = ip6_flowinfo(ipv6_hdr(skb));
> > + if (np->repflow)
> > + newnp->flow_label = ip6_flowlabel(ipv6_hdr(skb));
>
> Just asking:
>
> Was there a specific reason you did not use np->flow_label here and just
> mirroring the flowlabel from the first packet of the connection for the
> whole connection?
>
> I don't know if it makes a difference, but maybe it was done on purpose?
I thought about it and am actually in favor of reusing the flowid from the syn
packet so userspace does report correct outgoing flowlabel even in case of
strange tcp peer changing it mid-stream.
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net-next] ipv6: send Change Status Report after DAD is completed
From: Hannes Frederic Sowa @ 2014-01-16 12:24 UTC (permalink / raw)
To: Daniel Borkmann, netdev, Hideaki YOSHIFUJI
In-Reply-To: <20140116122154.GK5359@plex.lan>
On Thu, Jan 16, 2014 at 10:21:54AM -0200, Flavio Leitner wrote:
> > >diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
> > >index 99cd65c..8ac17f5 100644
> > >--- a/net/ipv6/mcast.c
> > >+++ b/net/ipv6/mcast.c
> > >@@ -1493,7 +1493,7 @@ static struct sk_buff *add_grhead(struct sk_buff *skb, struct ifmcaddr6 *pmc,
> > > skb_tailroom(skb)) : 0)
> > >
> > > static struct sk_buff *add_grec(struct sk_buff *skb, struct ifmcaddr6 *pmc,
> > >- int type, int gdeleted, int sdeleted)
> > >+ int type, int gdeleted, int sdeleted, int crsend)
> >
> > Maybe we should convert the last three to 'bool' at some point in time?
>
> I'd say so.
Maybe it works out those can be one enum with a specified operation and no
bool vector?
Maybe you could have a look?
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net-next] ipv6: send Change Status Report after DAD is completed
From: Flavio Leitner @ 2014-01-16 12:21 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, Hideaki YOSHIFUJI, Hannes Frederic Sowa
In-Reply-To: <52D7C0BA.7010908@redhat.com>
On Thu, Jan 16, 2014 at 12:21:30PM +0100, Daniel Borkmann wrote:
> On 01/15/2014 08:10 PM, Flavio Leitner wrote:
> >The RFC 3810 defines two type of messages for multicast
> >listeners. The "Current State Report" message, as the name
> >implies, refreshes the *current* state to the querier.
> >Since the querier sends Query messages periodically, there
> >is no need to retransmit the report.
> >
> >On the other hand, any change should be reported immediately
> >using "State Change Report" messages. Since it's an event
> >triggered by a change and that it can be affected by packet
> >loss, the rfc states it should be retransmitted [RobVar] times
> >to make sure routers will receive timely.
> >
> >Currently, we are sending "Current State Reports" after
> >DAD is completed. Before that, we send messages using
> >unspecified address (::) which should be silently discarded
> >by routers.
> >
> >This patch changes to send "State Change Report" messages
> >after DAD is completed fixing the behavior to be RFC compliant
> >and also to pass TAHI IPv6 testsuite.
> >
> >Signed-off-by: Flavio Leitner <fbl@redhat.com>
> >---
> > net/ipv6/mcast.c | 64 ++++++++++++++++++++++++++++++++++----------------------
> > 1 file changed, 39 insertions(+), 25 deletions(-)
> >
> >diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
> >index 99cd65c..8ac17f5 100644
> >--- a/net/ipv6/mcast.c
> >+++ b/net/ipv6/mcast.c
> >@@ -1493,7 +1493,7 @@ static struct sk_buff *add_grhead(struct sk_buff *skb, struct ifmcaddr6 *pmc,
> > skb_tailroom(skb)) : 0)
> >
> > static struct sk_buff *add_grec(struct sk_buff *skb, struct ifmcaddr6 *pmc,
> >- int type, int gdeleted, int sdeleted)
> >+ int type, int gdeleted, int sdeleted, int crsend)
>
> Maybe we should convert the last three to 'bool' at some point in time?
I'd say so.
> Nit: argument indent
Ok, will fix in the v2
[...]
> >+ if (MLD_V1_SEEN(idev))
> >+ return;
>
> $ git grep -n MLD_V1_SEEN
> $
>
> I believe I have removed that macro some time ago. ;)
>
> I presume you mean rather: mld_in_v1_mode(idev)
Oops, branched from the wrong (old) point here.
I will send a v2.
Thanks,
fbl
^ permalink raw reply
* Re: [PATCH net-next] sctp: remove the unnecessary assignment
From: Neil Horman @ 2014-01-16 12:18 UTC (permalink / raw)
To: Wang Weidong; +Cc: David Miller, Vlad Yasevich, netdev, linux-sctp
In-Reply-To: <52D7976F.7070708@huawei.com>
On Thu, Jan 16, 2014 at 04:25:19PM +0800, Wang Weidong wrote:
> When go the right path, the status is 0, no need to assign it again.
> So just remove the assignment.
>
> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
> ---
> net/sctp/protocol.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
> index 7c16108..d6934dc 100644
> --- a/net/sctp/protocol.c
> +++ b/net/sctp/protocol.c
> @@ -1461,7 +1461,6 @@ static __init int sctp_init(void)
> if (status)
> goto err_v6_add_protocol;
>
> - status = 0;
> out:
> return status;
> err_v6_add_protocol:
> --
> 1.7.12
>
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH net-next v3 5/5] virtio-net: initial rx sysfs support, export mergeable rx buffer size
From: Michael S. Tsirkin @ 2014-01-16 11:53 UTC (permalink / raw)
To: Michael Dalton; +Cc: netdev, virtualization, Eric Dumazet, David S. Miller
In-Reply-To: <1389865126-26225-5-git-send-email-mwdalton@google.com>
On Thu, Jan 16, 2014 at 01:38:46AM -0800, Michael Dalton wrote:
> Add initial support for per-rx queue sysfs attributes to virtio-net. If
> mergeable packet buffers are enabled, adds a read-only mergeable packet
> buffer size sysfs attribute for each RX queue.
>
> Signed-off-by: Michael Dalton <mwdalton@google.com>
> ---
> drivers/net/virtio_net.c | 66 +++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 62 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 3e82311..f315cbb 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -27,6 +27,7 @@
> #include <linux/slab.h>
> #include <linux/cpu.h>
> #include <linux/average.h>
> +#include <linux/seqlock.h>
>
> static int napi_weight = NAPI_POLL_WEIGHT;
> module_param(napi_weight, int, 0444);
> @@ -89,6 +90,12 @@ struct receive_queue {
> /* Average packet length for mergeable receive buffers. */
> struct ewma mrg_avg_pkt_len;
>
> + /* Sequence counter to allow sysfs readers to safely access stats.
> + * Assumes a single virtio-net writer, which is enforced by virtio-net
> + * and NAPI.
> + */
> + seqcount_t sysfs_seq;
> +
> /* Page frag for packet buffer allocation. */
> struct page_frag alloc_frag;
>
> @@ -416,7 +423,9 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> }
> }
>
> + write_seqcount_begin(&rq->sysfs_seq);
> ewma_add(&rq->mrg_avg_pkt_len, head_skb->len);
> + write_seqcount_end(&rq->sysfs_seq);
> return head_skb;
>
> err_skb:
Hmm this adds overhead just to prevent sysfs from getting wrong value.
Can't sysfs simply disable softirq while it's reading the value?
> @@ -604,18 +613,29 @@ static int add_recvbuf_big(struct receive_queue *rq, gfp_t gfp)
> return err;
> }
>
> -static int add_recvbuf_mergeable(struct receive_queue *rq, gfp_t gfp)
> +static unsigned int get_mergeable_buf_len(struct ewma *avg_pkt_len)
> {
> const size_t hdr_len = sizeof(struct virtio_net_hdr_mrg_rxbuf);
> + unsigned int len;
> +
> + len = hdr_len + clamp_t(unsigned int, ewma_read(avg_pkt_len),
> + GOOD_PACKET_LEN, PAGE_SIZE - hdr_len);
> + return ALIGN(len, MERGEABLE_BUFFER_ALIGN);
> +}
> +
> +static int add_recvbuf_mergeable(struct receive_queue *rq, gfp_t gfp)
> +{
> struct page_frag *alloc_frag = &rq->alloc_frag;
> char *buf;
> unsigned long ctx;
> int err;
> unsigned int len, hole;
>
> - len = hdr_len + clamp_t(unsigned int, ewma_read(&rq->mrg_avg_pkt_len),
> - GOOD_PACKET_LEN, PAGE_SIZE - hdr_len);
> - len = ALIGN(len, MERGEABLE_BUFFER_ALIGN);
> + /* avg_pkt_len is written only in NAPI rx softirq context. We may
> + * read avg_pkt_len without using the sysfs_seq seqcount, as this code
> + * is called only in NAPI rx softirq context or when NAPI is disabled.
> + */
> + len = get_mergeable_buf_len(&rq->mrg_avg_pkt_len);
> if (unlikely(!skb_page_frag_refill(len, alloc_frag, gfp)))
> return -ENOMEM;
>
> @@ -1557,6 +1577,7 @@ static int virtnet_alloc_queues(struct virtnet_info *vi)
> napi_weight);
>
> sg_init_table(vi->rq[i].sg, ARRAY_SIZE(vi->rq[i].sg));
> + seqcount_init(&vi->rq[i].sysfs_seq);
> ewma_init(&vi->rq[i].mrg_avg_pkt_len, 1, RECEIVE_AVG_WEIGHT);
> sg_init_table(vi->sq[i].sg, ARRAY_SIZE(vi->sq[i].sg));
> }
> @@ -1594,6 +1615,39 @@ err:
> return ret;
> }
>
> +#ifdef CONFIG_SYSFS
> +static ssize_t mergeable_rx_buffer_size_show(struct netdev_rx_queue *queue,
> + struct rx_queue_attribute *attribute, char *buf)
> +{
> + struct virtnet_info *vi = netdev_priv(queue->dev);
> + unsigned int queue_index = get_netdev_rx_queue_index(queue);
> + struct receive_queue *rq;
> + struct ewma avg;
> + unsigned int start;
> +
> + BUG_ON(queue_index >= vi->max_queue_pairs);
> + rq = &vi->rq[queue_index];
> + do {
> + start = read_seqcount_begin(&rq->sysfs_seq);
> + avg = rq->mrg_avg_pkt_len;
> + } while (read_seqcount_retry(&rq->sysfs_seq, start));
> + return sprintf(buf, "%u\n", get_mergeable_buf_len(&avg));
> +}
> +
> +static struct rx_queue_attribute mergeable_rx_buffer_size_attribute =
> + __ATTR_RO(mergeable_rx_buffer_size);
> +
> +static struct attribute *virtio_net_mrg_rx_attrs[] = {
> + &mergeable_rx_buffer_size_attribute.attr,
> + NULL
> +};
> +
> +static const struct attribute_group virtio_net_mrg_rx_group = {
> + .name = "virtio_net",
> + .attrs = virtio_net_mrg_rx_attrs
> +};
> +#endif
> +
> static int virtnet_probe(struct virtio_device *vdev)
> {
> int i, err;
> @@ -1708,6 +1762,10 @@ static int virtnet_probe(struct virtio_device *vdev)
> if (err)
> goto free_stats;
>
> +#ifdef CONFIG_SYSFS
> + if (vi->mergeable_rx_bufs)
> + dev->sysfs_rx_queue_group = &virtio_net_mrg_rx_group;
> +#endif
> netif_set_real_num_tx_queues(dev, vi->curr_queue_pairs);
> netif_set_real_num_rx_queues(dev, vi->curr_queue_pairs);
>
> --
> 1.8.5.2
^ 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