* Re: [PATCH] xen-netback: use correct index for invalidation in netbk_tx_check_mop()
From: Ian Campbell @ 2011-11-18 15:09 UTC (permalink / raw)
To: netdev@vger.kernel.org, stable; +Cc: xen-devel@lists.xensource.com, Jan Beulich
In-Reply-To: <1321625599-3739-1-git-send-email-ian.campbell@citrix.com>
On Fri, 2011-11-18 at 14:13 +0000, Ian Campbell wrote:
> From: Jan Beulich <JBeulich@suse.com>
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
I forgot to CC stable@ here. This applies to 2.6.39 onwards.
> ---
> drivers/net/xen-netback/netback.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 0cb594c..1ae270e 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1021,7 +1021,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
> pending_idx = *((u16 *)skb->data);
> xen_netbk_idx_release(netbk, pending_idx);
> for (j = start; j < i; j++) {
> - pending_idx = frag_get_pending_idx(&shinfo->frags[i]);
> + pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
> xen_netbk_idx_release(netbk, pending_idx);
> }
>
^ permalink raw reply
* [PATCH] stmmac: mask mmc interrupts
From: Giuseppe CAVALLARO @ 2011-11-18 15:00 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
We need to mask the MMC irq otherwise if we raise the mmc
interrupts that are not handled the driver loops in the
handler.
In fact, by default all mmc counters (only used for stats)
are managed in SW and registers are cleared on each READ.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 8ea770a..72cd190 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -781,10 +781,15 @@ static void stmmac_mmc_setup(struct stmmac_priv *priv)
unsigned int mode = MMC_CNTRL_RESET_ON_READ | MMC_CNTRL_COUNTER_RESET |
MMC_CNTRL_PRESET | MMC_CNTRL_FULL_HALF_PRESET;
- /* Do not manage MMC IRQ (FIXME) */
+ /* Mask MMC irq, counters are managed in SW and registers
+ * are cleared on each READ eventually. */
dwmac_mmc_intr_all_mask(priv->ioaddr);
- dwmac_mmc_ctrl(priv->ioaddr, mode);
- memset(&priv->mmc, 0, sizeof(struct stmmac_counters));
+
+ if (priv->dma_cap.rmon) {
+ dwmac_mmc_ctrl(priv->ioaddr, mode);
+ memset(&priv->mmc, 0, sizeof(struct stmmac_counters));
+ } else
+ pr_info(" No MAC Management Counters available");
}
static u32 stmmac_get_synopsys_id(struct stmmac_priv *priv)
@@ -1012,8 +1017,7 @@ static int stmmac_open(struct net_device *dev)
memset(&priv->xstats, 0, sizeof(struct stmmac_extra_stats));
priv->xstats.threshold = tc;
- if (priv->dma_cap.rmon)
- stmmac_mmc_setup(priv);
+ stmmac_mmc_setup(priv);
/* Start the ball rolling... */
DBG(probe, DEBUG, "%s: DMA RX/TX processes started...\n", dev->name);
--
1.7.4.4
^ permalink raw reply related
* [PATCH 1/1] net/macb: add DT support
From: Jean-Christophe PLAGNIOL-VILLARD @ 2011-11-18 14:29 UTC (permalink / raw)
To: devicetree-discuss-mnsaURCQ41sdnm+yROfE0A; +Cc: netdev-u79uwXL29TY76Z2rM5mHXA
allow the DT to pass the mac address and the phy mode
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
Cc: Jamie Iles <jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org>
Cc: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
---
Documentation/devicetree/bindings/net/macb.txt | 22 ++++++++
drivers/net/ethernet/cadence/macb.c | 65 +++++++++++++++++++++---
drivers/net/ethernet/cadence/macb.h | 2 +
3 files changed, 81 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/macb.txt
diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
new file mode 100644
index 0000000..2b727ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -0,0 +1,22 @@
+* Cadence EMACB
+
+Implemeted on Atmel AT91 & AVR32 SoC
+
+Required properties:
+- compatible : Should be "atmel,macb" for Atmel
+- reg : Address and length of the register set for the device
+- interrupts : Should contain macb interrupt
+- phy-mode : String, operation mode of the PHY interface.
+ Supported values are: "mii", "rmii",
+
+Optional properties:
+- local-mac-address : 6 bytes, mac address
+
+Examples:
+
+ macb0: macb@fffc4000 {
+ compatible = "atmel,macb";
+ reg = <oxfffc4000 0x4000>;
+ interrupts = <21>;
+ phy-mode = "mii";
+ };
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index a437b46..2c345bc 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -20,6 +20,9 @@
#include <linux/etherdevice.h>
#include <linux/dma-mapping.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_net.h>
#include <linux/phy.h>
#include <mach/board.h>
@@ -81,6 +84,20 @@ static void __init macb_get_hwaddr(struct macb *bp)
addr[4] = top & 0xff;
addr[5] = (top >> 8) & 0xff;
+#ifdef CONFIG_OF
+ /*
+ * 2) from device tree data
+ */
+ if (!is_valid_ether_addr(addr)) {
+ struct device_node *np = bp->pdev->dev.of_node;
+ if (np) {
+ const char *mac = of_get_mac_address(np);
+ if (mac)
+ memcpy(addr, mac, sizeof(addr));
+ }
+ }
+#endif
+
if (is_valid_ether_addr(addr)) {
memcpy(bp->dev->dev_addr, addr, sizeof(addr));
} else {
@@ -191,7 +208,6 @@ static int macb_mii_probe(struct net_device *dev)
{
struct macb *bp = netdev_priv(dev);
struct phy_device *phydev;
- struct eth_platform_data *pdata;
int ret;
phydev = phy_find_first(bp->mii_bus);
@@ -200,14 +216,11 @@ static int macb_mii_probe(struct net_device *dev)
return -1;
}
- pdata = bp->pdev->dev.platform_data;
/* TODO : add pin_irq */
/* attach the mac to the phy */
ret = phy_connect_direct(dev, phydev, &macb_handle_link_change, 0,
- pdata && pdata->is_rmii ?
- PHY_INTERFACE_MODE_RMII :
- PHY_INTERFACE_MODE_MII);
+ bp->phy_interface);
if (ret) {
printk(KERN_ERR "%s: Could not attach to PHY\n", dev->name);
return ret;
@@ -1117,6 +1130,30 @@ static const struct net_device_ops macb_netdev_ops = {
#endif
};
+#if defined(CONFIG_OF)
+static const struct of_device_id macb_dt_ids[] = {
+ { .compatible = "atmel,macb" },
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, macb_dt_ids);
+
+static int __devinit macb_get_phy_mode_dt(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+
+ if (np)
+ return of_get_phy_mode(np);
+
+ return -ENODEV;
+}
+#else
+static int __devinit macb_get_phy_mode_dt(struct platform_device *pdev)
+{
+ return -ENODEV;
+}
+#endif
+
static int __init macb_probe(struct platform_device *pdev)
{
struct eth_platform_data *pdata;
@@ -1210,20 +1247,31 @@ static int __init macb_probe(struct platform_device *pdev)
macb_writel(bp, NCFGR, config);
macb_get_hwaddr(bp);
- pdata = pdev->dev.platform_data;
- if (pdata && pdata->is_rmii)
+ err = macb_get_phy_mode_dt(pdev);
+ if (err < 0) {
+ pdata = pdev->dev.platform_data;
+ if (pdata && pdata->is_rmii)
+ bp->phy_interface = PHY_INTERFACE_MODE_RMII;
+ else
+ bp->phy_interface = PHY_INTERFACE_MODE_MII;
+ } else {
+ bp->phy_interface = err;
+ }
+
+ if (bp->phy_interface == PHY_INTERFACE_MODE_RMII) {
#if defined(CONFIG_ARCH_AT91)
macb_writel(bp, USRIO, (MACB_BIT(RMII) | MACB_BIT(CLKEN)) );
#else
macb_writel(bp, USRIO, 0);
#endif
- else
+ } else {
#if defined(CONFIG_ARCH_AT91)
macb_writel(bp, USRIO, MACB_BIT(CLKEN));
#else
macb_writel(bp, USRIO, MACB_BIT(MII));
#endif
+ }
bp->tx_pending = DEF_TX_RING_PENDING;
@@ -1344,6 +1392,7 @@ static struct platform_driver macb_driver = {
.driver = {
.name = "macb",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(macb_dt_ids),
},
};
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index d3212f6..8342744 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -389,6 +389,8 @@ struct macb {
unsigned int link;
unsigned int speed;
unsigned int duplex;
+
+ phy_interface_t phy_interface;
};
#endif /* _MACB_H */
--
1.7.7
^ permalink raw reply related
* [PATCH] xen-netback: use correct index for invalidation in netbk_tx_check_mop()
From: Ian Campbell @ 2011-11-18 14:13 UTC (permalink / raw)
To: netdev; +Cc: xen-devel, Ian Campbell, Jan Beulich
From: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
drivers/net/xen-netback/netback.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 0cb594c..1ae270e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1021,7 +1021,7 @@ static int xen_netbk_tx_check_gop(struct xen_netbk *netbk,
pending_idx = *((u16 *)skb->data);
xen_netbk_idx_release(netbk, pending_idx);
for (j = start; j < i; j++) {
- pending_idx = frag_get_pending_idx(&shinfo->frags[i]);
+ pending_idx = frag_get_pending_idx(&shinfo->frags[j]);
xen_netbk_idx_release(netbk, pending_idx);
}
--
1.7.2.5
^ permalink raw reply related
* Re: routing bug?
From: Eric Dumazet @ 2011-11-18 13:54 UTC (permalink / raw)
To: Pozsár Balázs
Cc: Sven-Haegar Koch, Linux-Kernel-Mailinglist,
Tamási János, netdev
In-Reply-To: <4EC65FF1.9010601@uhulinux.hu>
Le vendredi 18 novembre 2011 à 14:38 +0100, Pozsár Balázs a écrit :
> Unfortunately it does not solve the problem for me, I have have these
> "cache <redirected>" entries even after that echo command.
>
Its a problem with a cached value.
You must reboot to flush it.
It was already discussed yesterday on netdev.
^ permalink raw reply
* Re: routing bug?
From: Pozsár Balázs @ 2011-11-18 13:38 UTC (permalink / raw)
To: Eric Dumazet
Cc: Sven-Haegar Koch, Linux-Kernel-Mailinglist,
Tamási János, netdev
In-Reply-To: <1321623207.3277.4.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 2011-11-18 14:33, Eric Dumazet wrote:
> Le vendredi 18 novembre 2011 à 14:23 +0100, Pozsár Balázs a écrit :
>
>> On 2011-11-18 14:09, Eric Dumazet wrote:
>>
>>> Le vendredi 18 novembre 2011 à 13:48 +0100, Sven-Haegar Koch a écrit :
>>>
>>>
>>>> Added netdev list to CC:, there you should have a higher chance of a
>>>> usefull answer.
>>>>
>>>> On Fri, 18 Nov 2011, Pozsár Balázs wrote:
>>>>
>>>>
>>>>
>>>>> Hi all,
>>>>>
>>>>> I have been struggling with this not easily reproducible issue since a while.
>>>>> I am using linux kernel v3.1.0, and sometimes routing to a few IP addresses
>>>>> does not work. What seems to happen is that instead of sending the packet to
>>>>> the gateway, the kernel treats the destination address as local, and tries to
>>>>> gets its MAC address via ARP.
>>>>>
>>>>> For example, now my current IP address is 172.16.1.104/24, the gateway is
>>>>> 172.16.1.254:
>>>>>
>>>>> |# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:1B:63:97:FC:DC
>>>>> inet addr:172.16.1.104 Bcast:172.16.1.255 Mask:255.255.255.0
>>>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>>>>> RX packets:230772 errors:0 dropped:0 overruns:0 frame:0
>>>>> TX packets:171013 errors:0 dropped:0 overruns:0 carrier:0
>>>>> collisions:0 txqueuelen:1000
>>>>> RX bytes:191879370 (182.9 Mb) TX bytes:47173253 (44.9 Mb)
>>>>> Interrupt:17
>>>>>
>>>>> # route -n
>>>>> Kernel IP routing table
>>>>> Destination Gateway Genmask Flags Metric Ref Use Iface
>>>>> 0.0.0.0 172.16.1.254 0.0.0.0 UG 0 0 0 eth0
>>>>> 172.16.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
>>>>> |
>>>>>
>>>>> I can ping a few addresses, but not 172.16.0.59:
>>>>>
>>>>> |# ping -c1 172.16.1.254
>>>>> PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
>>>>> 64 bytes from 172.16.1.254: icmp_seq=1 ttl=64 time=0.383 ms
>>>>>
>>>>> --- 172.16.1.254 ping statistics ---
>>>>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>>>>> rtt min/avg/max/mdev = 0.383/0.383/0.383/0.000 ms
>>>>> root@pozsybook:~# ping -c1 172.16.0.1
>>>>> PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
>>>>> 64 bytes from 172.16.0.1: icmp_seq=1 ttl=63 time=5.54 ms
>>>>>
>>>>> --- 172.16.0.1 ping statistics ---
>>>>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>>>>> rtt min/avg/max/mdev = 5.545/5.545/5.545/0.000 ms
>>>>> root@pozsybook:~# ping -c1 172.16.0.2
>>>>> PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
>>>>> 64 bytes from 172.16.0.2: icmp_seq=1 ttl=62 time=7.92 ms
>>>>>
>>>>> --- 172.16.0.2 ping statistics ---
>>>>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>>>>> rtt min/avg/max/mdev = 7.925/7.925/7.925/0.000 ms
>>>>> root@pozsybook:~# ping -c1 172.16.0.59
>>>>> PING 172.16.0.59 (172.16.0.59) 56(84) bytes of data.
>>>>> From 172.16.1.104 icmp_seq=1 Destination Host Unreachable
>>>>>
>>>>> --- 172.16.0.59 ping statistics ---
>>>>> 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
>>>>> |
>>>>>
>>>>> When trying to ping 172.16.0.59, I can see in tcpdump that an ARP req was
>>>>> sent:
>>>>>
>>>>> |# tcpdump -n -i eth0|grep ARP
>>>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>>>>> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
>>>>> 15:25:16.671217 ARP, Request who-has 172.16.0.59 tell 172.16.1.104, length 28
>>>>> |
>>>>>
>>>>> and /proc/net/arp has an incomplete entry for 172.16.0.59:
>>>>>
>>>>> |# grep 172.16.0.59 /proc/net/arp
>>>>>
>>>>> 172.16.0.59 0x1 0x0 00:00:00:00:00:00 * eth0
>>>>> |
>>>>>
>>>>> Please note, that 172.16.0.59 /is/ accessible from this LAN from other
>>>>> computers.
>>>>>
>>>>>
>>>>> Does anyone have any idea of what's going on? Thanks,
>>>>>
>>>>>
>>>>> Balazs Pozsar
>>>>>
>>>>> ps: I think it is related to this one: https://lkml.org/lkml/2011/11/16/292
>>>>>
>>>>> --
>>>>>
>>>>>
>>> Could you send us result of :
>>>
>>> ip route get 172.16.0.59
>>> ip route list cache match 172.16.0.59
>>>
>>>
>> I did not tell you in my first mail, that some times different hosts are
>> reachable and unreachable. I will try to not confuse you :)
>> As of now, 172.16.0.59 is OK, and 172.16.0.37 is NOT OK.
>> Also, 172.16.0.64 is OK now, and 172.16.0.42 is NOT OK now.
>>
>> The two commands you have requested give the following output for these
>> IP addresses:
>>
>> These are OK:
>>
>> # ip route get 172.16.0.64
>> 172.16.0.64 via 172.16.1.254 dev eth0 src 172.16.1.22
>> cache
>> # ip route get 172.16.0.59
>> 172.16.0.59 via 172.16.1.254 dev eth0 src 172.16.1.22
>> cache
>>
>> These are NOT OK:
>>
>> # ip route get 172.16.0.37
>> 172.16.0.37 dev eth0 src 172.16.1.22
>> cache<redirected> ipid 0x97a4
>> # ip route get 172.16.0.42
>> 172.16.0.42 dev eth0 src 172.16.1.22
>> cache<redirected> ipid 0x0d21
>>
>> These are OK:
>>
>> # ip route list cache match 172.16.0.59
>> 172.16.0.59 via 172.16.1.254 dev eth0 src 172.16.1.22
>> cache
>> # ip route list cache match 172.16.0.64
>> 172.16.0.64 via 172.16.1.254 dev eth0 src 172.16.1.22
>> cache
>>
>> These are NOT OK:
>>
>> # ip route list cache match 172.16.0.37
>> 172.16.0.37 dev eth0 src 172.16.1.22
>> cache<redirected> ipid 0x97a4
>> 172.16.0.37 from 172.16.1.22 dev eth0
>> cache<redirected> ipid 0x97a4
>> 172.16.0.37 from 172.16.1.22 dev eth0
>> cache<redirected> ipid 0x97a4
>> # ip route list cache match 172.16.0.42
>> 172.16.0.42 dev eth0 src 172.16.1.22
>> cache<redirected> ipid 0x0d21
>> 172.16.0.42 from 172.16.1.22 dev eth0
>> cache<redirected> ipid 0x0d21
>>
>>
>> How can I fix this?
>>
>> Thanks!
>>
> We are working on it (see threads in netdev)
>
> You can in the meantime
>
> echo 0>/proc/sys/net/ipv4/conf/eth0/accept_redirects
>
Unfortunately it does not solve the problem for me, I have have these
"cache <redirected>" entries even after that echo command.
^ permalink raw reply
* Re: routing bug?
From: Eric Dumazet @ 2011-11-18 13:33 UTC (permalink / raw)
To: Pozsár Balázs
Cc: Sven-Haegar Koch, Linux-Kernel-Mailinglist,
Tamási János, netdev
In-Reply-To: <4EC65C4B.6050505@uhulinux.hu>
Le vendredi 18 novembre 2011 à 14:23 +0100, Pozsár Balázs a écrit :
> On 2011-11-18 14:09, Eric Dumazet wrote:
> > Le vendredi 18 novembre 2011 à 13:48 +0100, Sven-Haegar Koch a écrit :
> >
> >> Added netdev list to CC:, there you should have a higher chance of a
> >> usefull answer.
> >>
> >> On Fri, 18 Nov 2011, Pozsár Balázs wrote:
> >>
> >>
> >>> Hi all,
> >>>
> >>> I have been struggling with this not easily reproducible issue since a while.
> >>> I am using linux kernel v3.1.0, and sometimes routing to a few IP addresses
> >>> does not work. What seems to happen is that instead of sending the packet to
> >>> the gateway, the kernel treats the destination address as local, and tries to
> >>> gets its MAC address via ARP.
> >>>
> >>> For example, now my current IP address is 172.16.1.104/24, the gateway is
> >>> 172.16.1.254:
> >>>
> >>> |# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:1B:63:97:FC:DC
> >>> inet addr:172.16.1.104 Bcast:172.16.1.255 Mask:255.255.255.0
> >>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> >>> RX packets:230772 errors:0 dropped:0 overruns:0 frame:0
> >>> TX packets:171013 errors:0 dropped:0 overruns:0 carrier:0
> >>> collisions:0 txqueuelen:1000
> >>> RX bytes:191879370 (182.9 Mb) TX bytes:47173253 (44.9 Mb)
> >>> Interrupt:17
> >>>
> >>> # route -n
> >>> Kernel IP routing table
> >>> Destination Gateway Genmask Flags Metric Ref Use Iface
> >>> 0.0.0.0 172.16.1.254 0.0.0.0 UG 0 0 0 eth0
> >>> 172.16.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
> >>> |
> >>>
> >>> I can ping a few addresses, but not 172.16.0.59:
> >>>
> >>> |# ping -c1 172.16.1.254
> >>> PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
> >>> 64 bytes from 172.16.1.254: icmp_seq=1 ttl=64 time=0.383 ms
> >>>
> >>> --- 172.16.1.254 ping statistics ---
> >>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> >>> rtt min/avg/max/mdev = 0.383/0.383/0.383/0.000 ms
> >>> root@pozsybook:~# ping -c1 172.16.0.1
> >>> PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
> >>> 64 bytes from 172.16.0.1: icmp_seq=1 ttl=63 time=5.54 ms
> >>>
> >>> --- 172.16.0.1 ping statistics ---
> >>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> >>> rtt min/avg/max/mdev = 5.545/5.545/5.545/0.000 ms
> >>> root@pozsybook:~# ping -c1 172.16.0.2
> >>> PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
> >>> 64 bytes from 172.16.0.2: icmp_seq=1 ttl=62 time=7.92 ms
> >>>
> >>> --- 172.16.0.2 ping statistics ---
> >>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> >>> rtt min/avg/max/mdev = 7.925/7.925/7.925/0.000 ms
> >>> root@pozsybook:~# ping -c1 172.16.0.59
> >>> PING 172.16.0.59 (172.16.0.59) 56(84) bytes of data.
> >>> From 172.16.1.104 icmp_seq=1 Destination Host Unreachable
> >>>
> >>> --- 172.16.0.59 ping statistics ---
> >>> 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
> >>> |
> >>>
> >>> When trying to ping 172.16.0.59, I can see in tcpdump that an ARP req was
> >>> sent:
> >>>
> >>> |# tcpdump -n -i eth0|grep ARP
> >>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> >>> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> >>> 15:25:16.671217 ARP, Request who-has 172.16.0.59 tell 172.16.1.104, length 28
> >>> |
> >>>
> >>> and /proc/net/arp has an incomplete entry for 172.16.0.59:
> >>>
> >>> |# grep 172.16.0.59 /proc/net/arp
> >>>
> >>> 172.16.0.59 0x1 0x0 00:00:00:00:00:00 * eth0
> >>> |
> >>>
> >>> Please note, that 172.16.0.59 /is/ accessible from this LAN from other
> >>> computers.
> >>>
> >>>
> >>> Does anyone have any idea of what's going on? Thanks,
> >>>
> >>>
> >>> Balazs Pozsar
> >>>
> >>> ps: I think it is related to this one: https://lkml.org/lkml/2011/11/16/292
> >>>
> >>> --
> >>>
> > Could you send us result of :
> >
> > ip route get 172.16.0.59
> > ip route list cache match 172.16.0.59
> >
>
> I did not tell you in my first mail, that some times different hosts are
> reachable and unreachable. I will try to not confuse you :)
> As of now, 172.16.0.59 is OK, and 172.16.0.37 is NOT OK.
> Also, 172.16.0.64 is OK now, and 172.16.0.42 is NOT OK now.
>
> The two commands you have requested give the following output for these
> IP addresses:
>
> These are OK:
>
> # ip route get 172.16.0.64
> 172.16.0.64 via 172.16.1.254 dev eth0 src 172.16.1.22
> cache
> # ip route get 172.16.0.59
> 172.16.0.59 via 172.16.1.254 dev eth0 src 172.16.1.22
> cache
>
> These are NOT OK:
>
> # ip route get 172.16.0.37
> 172.16.0.37 dev eth0 src 172.16.1.22
> cache <redirected> ipid 0x97a4
> # ip route get 172.16.0.42
> 172.16.0.42 dev eth0 src 172.16.1.22
> cache <redirected> ipid 0x0d21
>
> These are OK:
>
> # ip route list cache match 172.16.0.59
> 172.16.0.59 via 172.16.1.254 dev eth0 src 172.16.1.22
> cache
> # ip route list cache match 172.16.0.64
> 172.16.0.64 via 172.16.1.254 dev eth0 src 172.16.1.22
> cache
>
> These are NOT OK:
>
> # ip route list cache match 172.16.0.37
> 172.16.0.37 dev eth0 src 172.16.1.22
> cache <redirected> ipid 0x97a4
> 172.16.0.37 from 172.16.1.22 dev eth0
> cache <redirected> ipid 0x97a4
> 172.16.0.37 from 172.16.1.22 dev eth0
> cache <redirected> ipid 0x97a4
> # ip route list cache match 172.16.0.42
> 172.16.0.42 dev eth0 src 172.16.1.22
> cache <redirected> ipid 0x0d21
> 172.16.0.42 from 172.16.1.22 dev eth0
> cache <redirected> ipid 0x0d21
>
>
> How can I fix this?
>
> Thanks!
We are working on it (see threads in netdev)
You can in the meantime
echo 0 >/proc/sys/net/ipv4/conf/eth0/accept_redirects
^ permalink raw reply
* Important Notice !!!
From: jose.riggins @ 2011-11-18 13:25 UTC (permalink / raw)
--
Attn. Mail User!
Information Technology Service (ITS) are currently upgrading e-mail
accounts. This will provide you the ability to store a greatly
increased amount of e-mail correspondence in your e-mail account. Your
account has been identified as one of the accounts which are to be
upgraded.
Please click the link below and follow the instruction
http://tinyurl.com/webmaster-Adminstrator
The new minimum quota level for e-mail accounts will be set to 1000mb.
Regards,
@2011 Support Team.
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
A la atención. De usuario de correo!
Servicio de Tecnología de la Información (ITS) están actualizando
cuentas de correo electrónico. Esto le proporcionará la capacidad de
almacenar una cantidad mucho mayor de la correspondencia por correo
electrónico en su cuenta de correo electrónico. Su cuenta ha sido
identificada como una de las cuentas que se van a actualizar.
Por favor, haga clic en el enlace de abajo y siga las instrucciones
http://tinyurl.com/webmaster-Adminstrator
El nivel mínimo de cuotas nuevas cuentas de correo electrónico se
ajustará a 1000Mb.
Saludos,
@ 2011 Equipo de Apoyo.
^ permalink raw reply
* Re: routing bug?
From: Pozsár Balázs @ 2011-11-18 13:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: Sven-Haegar Koch, Linux-Kernel-Mailinglist,
Tamási János, netdev
In-Reply-To: <1321621796.3277.1.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 2011-11-18 14:09, Eric Dumazet wrote:
> Le vendredi 18 novembre 2011 à 13:48 +0100, Sven-Haegar Koch a écrit :
>
>> Added netdev list to CC:, there you should have a higher chance of a
>> usefull answer.
>>
>> On Fri, 18 Nov 2011, Pozsár Balázs wrote:
>>
>>
>>> Hi all,
>>>
>>> I have been struggling with this not easily reproducible issue since a while.
>>> I am using linux kernel v3.1.0, and sometimes routing to a few IP addresses
>>> does not work. What seems to happen is that instead of sending the packet to
>>> the gateway, the kernel treats the destination address as local, and tries to
>>> gets its MAC address via ARP.
>>>
>>> For example, now my current IP address is 172.16.1.104/24, the gateway is
>>> 172.16.1.254:
>>>
>>> |# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:1B:63:97:FC:DC
>>> inet addr:172.16.1.104 Bcast:172.16.1.255 Mask:255.255.255.0
>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>>> RX packets:230772 errors:0 dropped:0 overruns:0 frame:0
>>> TX packets:171013 errors:0 dropped:0 overruns:0 carrier:0
>>> collisions:0 txqueuelen:1000
>>> RX bytes:191879370 (182.9 Mb) TX bytes:47173253 (44.9 Mb)
>>> Interrupt:17
>>>
>>> # route -n
>>> Kernel IP routing table
>>> Destination Gateway Genmask Flags Metric Ref Use Iface
>>> 0.0.0.0 172.16.1.254 0.0.0.0 UG 0 0 0 eth0
>>> 172.16.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
>>> |
>>>
>>> I can ping a few addresses, but not 172.16.0.59:
>>>
>>> |# ping -c1 172.16.1.254
>>> PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
>>> 64 bytes from 172.16.1.254: icmp_seq=1 ttl=64 time=0.383 ms
>>>
>>> --- 172.16.1.254 ping statistics ---
>>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>>> rtt min/avg/max/mdev = 0.383/0.383/0.383/0.000 ms
>>> root@pozsybook:~# ping -c1 172.16.0.1
>>> PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
>>> 64 bytes from 172.16.0.1: icmp_seq=1 ttl=63 time=5.54 ms
>>>
>>> --- 172.16.0.1 ping statistics ---
>>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>>> rtt min/avg/max/mdev = 5.545/5.545/5.545/0.000 ms
>>> root@pozsybook:~# ping -c1 172.16.0.2
>>> PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
>>> 64 bytes from 172.16.0.2: icmp_seq=1 ttl=62 time=7.92 ms
>>>
>>> --- 172.16.0.2 ping statistics ---
>>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>>> rtt min/avg/max/mdev = 7.925/7.925/7.925/0.000 ms
>>> root@pozsybook:~# ping -c1 172.16.0.59
>>> PING 172.16.0.59 (172.16.0.59) 56(84) bytes of data.
>>> From 172.16.1.104 icmp_seq=1 Destination Host Unreachable
>>>
>>> --- 172.16.0.59 ping statistics ---
>>> 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
>>> |
>>>
>>> When trying to ping 172.16.0.59, I can see in tcpdump that an ARP req was
>>> sent:
>>>
>>> |# tcpdump -n -i eth0|grep ARP
>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>>> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
>>> 15:25:16.671217 ARP, Request who-has 172.16.0.59 tell 172.16.1.104, length 28
>>> |
>>>
>>> and /proc/net/arp has an incomplete entry for 172.16.0.59:
>>>
>>> |# grep 172.16.0.59 /proc/net/arp
>>>
>>> 172.16.0.59 0x1 0x0 00:00:00:00:00:00 * eth0
>>> |
>>>
>>> Please note, that 172.16.0.59 /is/ accessible from this LAN from other
>>> computers.
>>>
>>>
>>> Does anyone have any idea of what's going on? Thanks,
>>>
>>>
>>> Balazs Pozsar
>>>
>>> ps: I think it is related to this one: https://lkml.org/lkml/2011/11/16/292
>>>
>>> --
>>>
> Could you send us result of :
>
> ip route get 172.16.0.59
> ip route list cache match 172.16.0.59
>
I did not tell you in my first mail, that some times different hosts are
reachable and unreachable. I will try to not confuse you :)
As of now, 172.16.0.59 is OK, and 172.16.0.37 is NOT OK.
Also, 172.16.0.64 is OK now, and 172.16.0.42 is NOT OK now.
The two commands you have requested give the following output for these
IP addresses:
These are OK:
# ip route get 172.16.0.64
172.16.0.64 via 172.16.1.254 dev eth0 src 172.16.1.22
cache
# ip route get 172.16.0.59
172.16.0.59 via 172.16.1.254 dev eth0 src 172.16.1.22
cache
These are NOT OK:
# ip route get 172.16.0.37
172.16.0.37 dev eth0 src 172.16.1.22
cache <redirected> ipid 0x97a4
# ip route get 172.16.0.42
172.16.0.42 dev eth0 src 172.16.1.22
cache <redirected> ipid 0x0d21
These are OK:
# ip route list cache match 172.16.0.59
172.16.0.59 via 172.16.1.254 dev eth0 src 172.16.1.22
cache
# ip route list cache match 172.16.0.64
172.16.0.64 via 172.16.1.254 dev eth0 src 172.16.1.22
cache
These are NOT OK:
# ip route list cache match 172.16.0.37
172.16.0.37 dev eth0 src 172.16.1.22
cache <redirected> ipid 0x97a4
172.16.0.37 from 172.16.1.22 dev eth0
cache <redirected> ipid 0x97a4
172.16.0.37 from 172.16.1.22 dev eth0
cache <redirected> ipid 0x97a4
# ip route list cache match 172.16.0.42
172.16.0.42 dev eth0 src 172.16.1.22
cache <redirected> ipid 0x0d21
172.16.0.42 from 172.16.1.22 dev eth0
cache <redirected> ipid 0x0d21
How can I fix this?
Thanks!
^ permalink raw reply
* Re: routing bug?
From: Eric Dumazet @ 2011-11-18 13:09 UTC (permalink / raw)
To: Sven-Haegar Koch
Cc: Pozsár Balázs, Linux-Kernel-Mailinglist,
Tamási János, netdev
In-Reply-To: <alpine.DEB.2.02.1111181346480.17023@aurora>
Le vendredi 18 novembre 2011 à 13:48 +0100, Sven-Haegar Koch a écrit :
> Added netdev list to CC:, there you should have a higher chance of a
> usefull answer.
>
> On Fri, 18 Nov 2011, Pozsár Balázs wrote:
>
> > Hi all,
> >
> > I have been struggling with this not easily reproducible issue since a while.
> > I am using linux kernel v3.1.0, and sometimes routing to a few IP addresses
> > does not work. What seems to happen is that instead of sending the packet to
> > the gateway, the kernel treats the destination address as local, and tries to
> > gets its MAC address via ARP.
> >
> > For example, now my current IP address is 172.16.1.104/24, the gateway is
> > 172.16.1.254:
> >
> > |# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:1B:63:97:FC:DC
> > inet addr:172.16.1.104 Bcast:172.16.1.255 Mask:255.255.255.0
> > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > RX packets:230772 errors:0 dropped:0 overruns:0 frame:0
> > TX packets:171013 errors:0 dropped:0 overruns:0 carrier:0
> > collisions:0 txqueuelen:1000
> > RX bytes:191879370 (182.9 Mb) TX bytes:47173253 (44.9 Mb)
> > Interrupt:17
> >
> > # route -n
> > Kernel IP routing table
> > Destination Gateway Genmask Flags Metric Ref Use Iface
> > 0.0.0.0 172.16.1.254 0.0.0.0 UG 0 0 0 eth0
> > 172.16.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
> > |
> >
> > I can ping a few addresses, but not 172.16.0.59:
> >
> > |# ping -c1 172.16.1.254
> > PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
> > 64 bytes from 172.16.1.254: icmp_seq=1 ttl=64 time=0.383 ms
> >
> > --- 172.16.1.254 ping statistics ---
> > 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> > rtt min/avg/max/mdev = 0.383/0.383/0.383/0.000 ms
> > root@pozsybook:~# ping -c1 172.16.0.1
> > PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
> > 64 bytes from 172.16.0.1: icmp_seq=1 ttl=63 time=5.54 ms
> >
> > --- 172.16.0.1 ping statistics ---
> > 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> > rtt min/avg/max/mdev = 5.545/5.545/5.545/0.000 ms
> > root@pozsybook:~# ping -c1 172.16.0.2
> > PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
> > 64 bytes from 172.16.0.2: icmp_seq=1 ttl=62 time=7.92 ms
> >
> > --- 172.16.0.2 ping statistics ---
> > 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> > rtt min/avg/max/mdev = 7.925/7.925/7.925/0.000 ms
> > root@pozsybook:~# ping -c1 172.16.0.59
> > PING 172.16.0.59 (172.16.0.59) 56(84) bytes of data.
> > From 172.16.1.104 icmp_seq=1 Destination Host Unreachable
> >
> > --- 172.16.0.59 ping statistics ---
> > 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
> > |
> >
> > When trying to ping 172.16.0.59, I can see in tcpdump that an ARP req was
> > sent:
> >
> > |# tcpdump -n -i eth0|grep ARP
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> > listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> > 15:25:16.671217 ARP, Request who-has 172.16.0.59 tell 172.16.1.104, length 28
> > |
> >
> > and /proc/net/arp has an incomplete entry for 172.16.0.59:
> >
> > |# grep 172.16.0.59 /proc/net/arp
> >
> > 172.16.0.59 0x1 0x0 00:00:00:00:00:00 * eth0
> > |
> >
> > Please note, that 172.16.0.59 /is/ accessible from this LAN from other
> > computers.
> >
> >
> > Does anyone have any idea of what's going on? Thanks,
> >
> >
> > Balazs Pozsar
> >
> > ps: I think it is related to this one: https://lkml.org/lkml/2011/11/16/292
> >
> > --
Could you send us result of :
ip route get 172.16.0.59
ip route list cache match 172.16.0.59
^ permalink raw reply
* Re: routing bug?
From: Sven-Haegar Koch @ 2011-11-18 12:48 UTC (permalink / raw)
To: Pozsár Balázs
Cc: Linux-Kernel-Mailinglist, Tamási János, netdev
In-Reply-To: <4EC648C9.8080405@uhulinux.hu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3834 bytes --]
Added netdev list to CC:, there you should have a higher chance of a
usefull answer.
On Fri, 18 Nov 2011, Pozsár Balázs wrote:
> Hi all,
>
> I have been struggling with this not easily reproducible issue since a while.
> I am using linux kernel v3.1.0, and sometimes routing to a few IP addresses
> does not work. What seems to happen is that instead of sending the packet to
> the gateway, the kernel treats the destination address as local, and tries to
> gets its MAC address via ARP.
>
> For example, now my current IP address is 172.16.1.104/24, the gateway is
> 172.16.1.254:
>
> |# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:1B:63:97:FC:DC
> inet addr:172.16.1.104 Bcast:172.16.1.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:230772 errors:0 dropped:0 overruns:0 frame:0
> TX packets:171013 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:191879370 (182.9 Mb) TX bytes:47173253 (44.9 Mb)
> Interrupt:17
>
> # route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 0.0.0.0 172.16.1.254 0.0.0.0 UG 0 0 0 eth0
> 172.16.1.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
> |
>
> I can ping a few addresses, but not 172.16.0.59:
>
> |# ping -c1 172.16.1.254
> PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
> 64 bytes from 172.16.1.254: icmp_seq=1 ttl=64 time=0.383 ms
>
> --- 172.16.1.254 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.383/0.383/0.383/0.000 ms
> root@pozsybook:~# ping -c1 172.16.0.1
> PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
> 64 bytes from 172.16.0.1: icmp_seq=1 ttl=63 time=5.54 ms
>
> --- 172.16.0.1 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 5.545/5.545/5.545/0.000 ms
> root@pozsybook:~# ping -c1 172.16.0.2
> PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
> 64 bytes from 172.16.0.2: icmp_seq=1 ttl=62 time=7.92 ms
>
> --- 172.16.0.2 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 7.925/7.925/7.925/0.000 ms
> root@pozsybook:~# ping -c1 172.16.0.59
> PING 172.16.0.59 (172.16.0.59) 56(84) bytes of data.
> From 172.16.1.104 icmp_seq=1 Destination Host Unreachable
>
> --- 172.16.0.59 ping statistics ---
> 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
> |
>
> When trying to ping 172.16.0.59, I can see in tcpdump that an ARP req was
> sent:
>
> |# tcpdump -n -i eth0|grep ARP
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> 15:25:16.671217 ARP, Request who-has 172.16.0.59 tell 172.16.1.104, length 28
> |
>
> and /proc/net/arp has an incomplete entry for 172.16.0.59:
>
> |# grep 172.16.0.59 /proc/net/arp
>
> 172.16.0.59 0x1 0x0 00:00:00:00:00:00 * eth0
> |
>
> Please note, that 172.16.0.59 /is/ accessible from this LAN from other
> computers.
>
>
> Does anyone have any idea of what's going on? Thanks,
>
>
> Balazs Pozsar
>
> ps: I think it is related to this one: https://lkml.org/lkml/2011/11/16/292
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
Three may keep a secret, if two of them are dead.
- Ben F.
^ permalink raw reply
* Re: ipv4 udplite broken in >=linux-3.0 ?
From: Jinxin Zheng @ 2011-11-18 12:35 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: gerrit, linux-kernel, netdev
In-Reply-To: <20111118120430.GG3317@hell>
On Fri, Nov 18, 2011 at 8:04 PM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:
> * Jinxin Zheng | 2011-11-18 12:09:25 [+0800]:
>
>>I don't know how to debug udplite. Can any one of you give me a tip on
>>how to get more debug info, then I can do further test and provide
>>with it?
>
> net-next works for me:
>
> $ sudo aptitude install netsend
> $ sudo tcpdump -n -ttt -vv -i lo > pcap.trace &
> $ netsend udplite receive &
> $ netsend udplite transmit /etc/fstab 127.0.0.1
>
> $ cat pcap.trace
> 00:00:00.000000 IP (tos 0x0, ttl 64, id 30602, offset 0, flags [DF], proto unknown (136), length 40) 127.0.0.1 > 127.0.0.1: udplite 20
> 00:00:00.000074 IP (tos 0x0, ttl 64, id 30603, offset 0, flags [DF], proto unknown (136), length 1125) 127.0.0.1 > 127.0.0.1: udplite 1105
>
>
> Kernel version? What is the output of strace?
>
The kernel version is 3.0. I compiled it myself on a Gentoo i386.
I do not use Ubuntu or Debian. Cannot get netsend in Gentoo ...
But I did the test using the hello_world application downloaded from
Gerrit's wiki:
http://www.erg.abdn.ac.uk/~gerrit/udp-lite/
It contains a simple 'server' and a 'client' program.
The client sends a "Hello World" to the server, and when the server
receives the message it exits.
$ tcpdump -n -ttt -vv -i lo > pcap.trace &
$ ./server &
$ ./client
$ cat pcap.trace
00:00:00.000000 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
unknown (136), length 41)
127.0.0.1 > 127.0.0.1: ip-proto-136 21
the pcap trace seems ok. The sendto() in the client returns ok. But
the server just cannot return from recv() and echo the message...
I can't see anything suspicious from strace for the server or client either...
--
Zheng Jinxin
^ permalink raw reply
* query : unregister/register netdev
From: Madhvapathi Sriram @ 2011-11-18 12:23 UTC (permalink / raw)
To: netdev
Hi,
In register_netdevice(), BUG_ON(dev->reg_state != NETREG_UNINITIALIZED) is
used to check if the device that is being registered is indeed a new one.
However, I see that this state is never moved to. It only happens when a
netdevice is allocated (by default to 0 using kzalloc).
So, the cycle register-->unregister-->register would fail since in the
unregister_netdevice the state is only moved to NETREG_UNREGISTERED (at max
to NETREG_RELEASED using free_netdev)
So, I presume that to reinitialize a netdevice one has to free the
netdevice, re allocate netdevice and only then re register.
Wondering why unregister and reregister is not allowed, rather than having
go through the free/alloc cycle - I am not an expert though.
Thanks
-Sriram
^ permalink raw reply
* [PATCH 6/6] ip_gre: Set needed_headroom dynamically again
From: Herbert Xu @ 2011-11-18 12:20 UTC (permalink / raw)
To: David Miller, eric.dumazet, evonlanthen, linux-kernel, netdev,
timo.teras
In-Reply-To: <20111118121832.GA2868@gondor.apana.org.au>
ip_gre: Set needed_headroom dynamically again
Now that all needed_headroom users have been fixed up so that
we can safely increase needed_headroom, this patch restore the
dynamic update of needed_headroom.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
net/ipv4/ip_gre.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index d55110e..d7bb94c 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -835,6 +835,8 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
if (skb_headroom(skb) < max_headroom || skb_shared(skb)||
(skb_cloned(skb) && !skb_clone_writable(skb, 0))) {
struct sk_buff *new_skb = skb_realloc_headroom(skb, max_headroom);
+ if (max_headroom > dev->needed_headroom)
+ dev->needed_headroom = max_headroom;
if (!new_skb) {
ip_rt_put(rt);
dev->stats.tx_dropped++;
^ permalink raw reply related
* [PATCH 5/6] packet: Add needed_tailroom to packet_sendmsg_spkt
From: Herbert Xu @ 2011-11-18 12:20 UTC (permalink / raw)
To: David Miller, eric.dumazet, evonlanthen, linux-kernel, netdev,
timo.teras
In-Reply-To: <20111118121832.GA2868@gondor.apana.org.au>
packet: Add needed_tailroom to packet_sendmsg_spkt
While auditing LL_ALLOCATED_SPACE I noticed that packet_sendmsg_spkt
did not include needed_tailroom when allocating an skb. This isn't
a fatal error as we should always tolerate inadequate tail room but
it isn't optimal.
This patch fixes that.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
net/packet/af_packet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 71c1a75..0da505c 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1499,10 +1499,11 @@ retry:
if (!skb) {
size_t reserved = LL_RESERVED_SPACE(dev);
+ int tlen = dev->needed_tailroom;
unsigned int hhlen = dev->header_ops ? dev->hard_header_len : 0;
rcu_read_unlock();
- skb = sock_wmalloc(sk, len + reserved, 0, GFP_KERNEL);
+ skb = sock_wmalloc(sk, len + reserved + tlen, 0, GFP_KERNEL);
if (skb == NULL)
return -ENOBUFS;
/* FIXME: Save some space for broken drivers that write a hard
^ permalink raw reply related
* [PATCH 4/6] net: Remove LL_ALLOCATED_SPACE
From: Herbert Xu @ 2011-11-18 12:20 UTC (permalink / raw)
To: David Miller, eric.dumazet, evonlanthen, linux-kernel, netdev,
timo.teras
In-Reply-To: <20111118121832.GA2868@gondor.apana.org.au>
net: Remove LL_ALLOCATED_SPACE
The macro LL_ALLOCATED_SPACE was ill-conceived. It applies the
alignment to the sum of needed_headroom and needed_tailroom. As
the amount that is then reserved for head room is needed_headroom
with alignment, this means that the tail room left may be too small.
Now that all uses of LL_ALLOCATED_SPACE have been removed, this
patch finally removes the macro itself.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
include/linux/netdevice.h | 5 -----
1 file changed, 5 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index cbeb586..1568c9d 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -272,16 +272,11 @@ struct hh_cache {
*
* We could use other alignment values, but we must maintain the
* relationship HH alignment <= LL alignment.
- *
- * LL_ALLOCATED_SPACE also takes into account the tailroom the device
- * may need.
*/
#define LL_RESERVED_SPACE(dev) \
((((dev)->hard_header_len+(dev)->needed_headroom)&~(HH_DATA_MOD - 1)) + HH_DATA_MOD)
#define LL_RESERVED_SPACE_EXTRA(dev,extra) \
((((dev)->hard_header_len+(dev)->needed_headroom+(extra))&~(HH_DATA_MOD - 1)) + HH_DATA_MOD)
-#define LL_ALLOCATED_SPACE(dev) \
- ((((dev)->hard_header_len+(dev)->needed_headroom+(dev)->needed_tailroom)&~(HH_DATA_MOD - 1)) + HH_DATA_MOD)
struct header_ops {
int (*create) (struct sk_buff *skb, struct net_device *dev,
^ permalink raw reply related
* [PATCH 2/6] ipv6: Remove all uses of LL_ALLOCATED_SPACE
From: Herbert Xu @ 2011-11-18 12:20 UTC (permalink / raw)
To: David Miller, eric.dumazet, evonlanthen, linux-kernel, netdev,
timo.teras
In-Reply-To: <20111118121832.GA2868@gondor.apana.org.au>
ipv6: Remove all uses of LL_ALLOCATED_SPACE
The macro LL_ALLOCATED_SPACE was ill-conceived. It applies the
alignment to the sum of needed_headroom and needed_tailroom. As
the amount that is then reserved for head room is needed_headroom
with alignment, this means that the tail room left may be too small.
This patch replaces all uses of LL_ALLOCATED_SPACE in net/ipv6
with the macro LL_RESERVED_SPACE and direct reference to
needed_tailroom.
This also fixes the problem with needed_headroom changing between
allocating the skb and reserving the head room.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
net/ipv6/ip6_output.c | 8 ++++++--
net/ipv6/mcast.c | 12 ++++++++----
net/ipv6/ndisc.c | 13 +++++++++----
net/ipv6/raw.c | 6 ++++--
4 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 84d0bd5..68ef97f 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -631,6 +631,7 @@ int ip6_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
struct ipv6hdr *tmp_hdr;
struct frag_hdr *fh;
unsigned int mtu, hlen, left, len;
+ int hroom, troom;
__be32 frag_id = 0;
int ptr, offset = 0, err=0;
u8 *prevhdr, nexthdr = 0;
@@ -797,6 +798,8 @@ slow_path:
*/
*prevhdr = NEXTHDR_FRAGMENT;
+ hroom = LL_RESERVED_SPACE(rt->dst.dev);
+ troom = rt->dst.dev->needed_tailroom;
/*
* Keep copying data until we run out.
@@ -815,7 +818,8 @@ slow_path:
* Allocate buffer.
*/
- if ((frag = alloc_skb(len+hlen+sizeof(struct frag_hdr)+LL_ALLOCATED_SPACE(rt->dst.dev), GFP_ATOMIC)) == NULL) {
+ if ((frag = alloc_skb(len + hlen + sizeof(struct frag_hdr) +
+ hroom + troom, GFP_ATOMIC)) == NULL) {
NETDEBUG(KERN_INFO "IPv6: frag: no memory for new fragment!\n");
IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)),
IPSTATS_MIB_FRAGFAILS);
@@ -828,7 +832,7 @@ slow_path:
*/
ip6_copy_metadata(frag, skb);
- skb_reserve(frag, LL_RESERVED_SPACE(rt->dst.dev));
+ skb_reserve(frag, hroom);
skb_put(frag, len + hlen + sizeof(struct frag_hdr));
skb_reset_network_header(frag);
fh = (struct frag_hdr *)(skb_network_header(frag) + hlen);
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index ee7839f..7b94beb 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -1343,13 +1343,15 @@ static struct sk_buff *mld_newpack(struct net_device *dev, int size)
struct mld2_report *pmr;
struct in6_addr addr_buf;
const struct in6_addr *saddr;
+ int hlen = LL_RESERVED_SPACE(dev);
+ int tlen = dev->needed_tailroom;
int err;
u8 ra[8] = { IPPROTO_ICMPV6, 0,
IPV6_TLV_ROUTERALERT, 2, 0, 0,
IPV6_TLV_PADN, 0 };
/* we assume size > sizeof(ra) here */
- size += LL_ALLOCATED_SPACE(dev);
+ size += hlen + tlen;
/* limit our allocations to order-0 page */
size = min_t(int, size, SKB_MAX_ORDER(0, 0));
skb = sock_alloc_send_skb(sk, size, 1, &err);
@@ -1357,7 +1359,7 @@ static struct sk_buff *mld_newpack(struct net_device *dev, int size)
if (!skb)
return NULL;
- skb_reserve(skb, LL_RESERVED_SPACE(dev));
+ skb_reserve(skb, hlen);
if (ipv6_get_lladdr(dev, &addr_buf, IFA_F_TENTATIVE)) {
/* <draft-ietf-magma-mld-source-05.txt>:
@@ -1723,6 +1725,8 @@ static void igmp6_send(struct in6_addr *addr, struct net_device *dev, int type)
struct mld_msg *hdr;
const struct in6_addr *snd_addr, *saddr;
struct in6_addr addr_buf;
+ int hlen = LL_RESERVED_SPACE(dev);
+ int tlen = dev->needed_tailroom;
int err, len, payload_len, full_len;
u8 ra[8] = { IPPROTO_ICMPV6, 0,
IPV6_TLV_ROUTERALERT, 2, 0, 0,
@@ -1744,7 +1748,7 @@ static void igmp6_send(struct in6_addr *addr, struct net_device *dev, int type)
IPSTATS_MIB_OUT, full_len);
rcu_read_unlock();
- skb = sock_alloc_send_skb(sk, LL_ALLOCATED_SPACE(dev) + full_len, 1, &err);
+ skb = sock_alloc_send_skb(sk, hlen + tlen + full_len, 1, &err);
if (skb == NULL) {
rcu_read_lock();
@@ -1754,7 +1758,7 @@ static void igmp6_send(struct in6_addr *addr, struct net_device *dev, int type)
return;
}
- skb_reserve(skb, LL_RESERVED_SPACE(dev));
+ skb_reserve(skb, hlen);
if (ipv6_get_lladdr(dev, &addr_buf, IFA_F_TENTATIVE)) {
/* <draft-ietf-magma-mld-source-05.txt>:
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 44e5b7f..5f191c4 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -446,6 +446,8 @@ struct sk_buff *ndisc_build_skb(struct net_device *dev,
struct sock *sk = net->ipv6.ndisc_sk;
struct sk_buff *skb;
struct icmp6hdr *hdr;
+ int hlen = LL_RESERVED_SPACE(dev);
+ int tlen = dev->needed_tailroom;
int len;
int err;
u8 *opt;
@@ -459,7 +461,7 @@ struct sk_buff *ndisc_build_skb(struct net_device *dev,
skb = sock_alloc_send_skb(sk,
(MAX_HEADER + sizeof(struct ipv6hdr) +
- len + LL_ALLOCATED_SPACE(dev)),
+ len + hlen + tlen),
1, &err);
if (!skb) {
ND_PRINTK0(KERN_ERR
@@ -468,7 +470,7 @@ struct sk_buff *ndisc_build_skb(struct net_device *dev,
return NULL;
}
- skb_reserve(skb, LL_RESERVED_SPACE(dev));
+ skb_reserve(skb, hlen);
ip6_nd_hdr(sk, skb, dev, saddr, daddr, IPPROTO_ICMPV6, len);
skb->transport_header = skb->tail;
@@ -1533,6 +1535,7 @@ void ndisc_send_redirect(struct sk_buff *skb, struct neighbour *neigh,
struct inet6_dev *idev;
struct flowi6 fl6;
u8 *opt;
+ int hlen, tlen;
int rd_len;
int err;
u8 ha_buf[MAX_ADDR_LEN], *ha = NULL;
@@ -1590,9 +1593,11 @@ void ndisc_send_redirect(struct sk_buff *skb, struct neighbour *neigh,
rd_len &= ~0x7;
len += rd_len;
+ hlen = LL_RESERVED_SPACE(dev);
+ tlen = dev->needed_tailroom;
buff = sock_alloc_send_skb(sk,
(MAX_HEADER + sizeof(struct ipv6hdr) +
- len + LL_ALLOCATED_SPACE(dev)),
+ len + hlen + tlen),
1, &err);
if (buff == NULL) {
ND_PRINTK0(KERN_ERR
@@ -1601,7 +1606,7 @@ void ndisc_send_redirect(struct sk_buff *skb, struct neighbour *neigh,
goto release;
}
- skb_reserve(buff, LL_RESERVED_SPACE(dev));
+ skb_reserve(buff, hlen);
ip6_nd_hdr(sk, buff, dev, &saddr_buf, &ipv6_hdr(skb)->saddr,
IPPROTO_ICMPV6, len);
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 331af3b..638fb2a 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -610,6 +610,8 @@ static int rawv6_send_hdrinc(struct sock *sk, void *from, int length,
struct sk_buff *skb;
int err;
struct rt6_info *rt = (struct rt6_info *)*dstp;
+ int hlen = LL_RESERVED_SPACE(rt->dst.dev);
+ int tlen = rt->dst.dev->needed_tailroom;
if (length > rt->dst.dev->mtu) {
ipv6_local_error(sk, EMSGSIZE, fl6, rt->dst.dev->mtu);
@@ -619,11 +621,11 @@ static int rawv6_send_hdrinc(struct sock *sk, void *from, int length,
goto out;
skb = sock_alloc_send_skb(sk,
- length + LL_ALLOCATED_SPACE(rt->dst.dev) + 15,
+ length + hlen + tlen + 15,
flags & MSG_DONTWAIT, &err);
if (skb == NULL)
goto error;
- skb_reserve(skb, LL_RESERVED_SPACE(rt->dst.dev));
+ skb_reserve(skb, hlen);
skb->priority = sk->sk_priority;
skb->mark = sk->sk_mark;
^ permalink raw reply related
* [PATCH 1/6] ipv4: Remove all uses of LL_ALLOCATED_SPACE
From: Herbert Xu @ 2011-11-18 12:20 UTC (permalink / raw)
To: David Miller, eric.dumazet, evonlanthen, linux-kernel, netdev,
timo.teras
In-Reply-To: <20111118121832.GA2868@gondor.apana.org.au>
ipv4: Remove all uses of LL_ALLOCATED_SPACE
The macro LL_ALLOCATED_SPACE was ill-conceived. It applies the
alignment to the sum of needed_headroom and needed_tailroom. As
the amount that is then reserved for head room is needed_headroom
with alignment, this means that the tail room left may be too small.
This patch replaces all uses of LL_ALLOCATED_SPACE in net/ipv4
with the macro LL_RESERVED_SPACE and direct reference to
needed_tailroom.
This also fixes the problem with needed_headroom changing between
allocating the skb and reserving the head room.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
net/ipv4/arp.c | 6 ++++--
net/ipv4/igmp.c | 13 +++++++++----
net/ipv4/ipconfig.c | 6 ++++--
net/ipv4/raw.c | 7 +++++--
4 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 96a164a..fb3fdbc 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -592,16 +592,18 @@ struct sk_buff *arp_create(int type, int ptype, __be32 dest_ip,
struct sk_buff *skb;
struct arphdr *arp;
unsigned char *arp_ptr;
+ int hlen = LL_RESERVED_SPACE(dev);
+ int tlen = dev->needed_tailroom;
/*
* Allocate a buffer
*/
- skb = alloc_skb(arp_hdr_len(dev) + LL_ALLOCATED_SPACE(dev), GFP_ATOMIC);
+ skb = alloc_skb(arp_hdr_len(dev) + hlen + tlen, GFP_ATOMIC);
if (skb == NULL)
return NULL;
- skb_reserve(skb, LL_RESERVED_SPACE(dev));
+ skb_reserve(skb, hlen);
skb_reset_network_header(skb);
arp = (struct arphdr *) skb_put(skb, arp_hdr_len(dev));
skb->dev = dev;
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index c7472ef..fbc5376 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -304,9 +304,11 @@ static struct sk_buff *igmpv3_newpack(struct net_device *dev, int size)
struct igmpv3_report *pig;
struct net *net = dev_net(dev);
struct flowi4 fl4;
+ int hlen = LL_RESERVED_SPACE(dev);
+ int tlen = dev->needed_tailroom;
while (1) {
- skb = alloc_skb(size + LL_ALLOCATED_SPACE(dev),
+ skb = alloc_skb(size + hlen + tlen,
GFP_ATOMIC | __GFP_NOWARN);
if (skb)
break;
@@ -327,7 +329,7 @@ static struct sk_buff *igmpv3_newpack(struct net_device *dev, int size)
skb_dst_set(skb, &rt->dst);
skb->dev = dev;
- skb_reserve(skb, LL_RESERVED_SPACE(dev));
+ skb_reserve(skb, hlen);
skb_reset_network_header(skb);
pip = ip_hdr(skb);
@@ -647,6 +649,7 @@ static int igmp_send_report(struct in_device *in_dev, struct ip_mc_list *pmc,
__be32 group = pmc ? pmc->multiaddr : 0;
struct flowi4 fl4;
__be32 dst;
+ int hlen, tlen;
if (type == IGMPV3_HOST_MEMBERSHIP_REPORT)
return igmpv3_send_report(in_dev, pmc);
@@ -661,7 +664,9 @@ static int igmp_send_report(struct in_device *in_dev, struct ip_mc_list *pmc,
if (IS_ERR(rt))
return -1;
- skb = alloc_skb(IGMP_SIZE+LL_ALLOCATED_SPACE(dev), GFP_ATOMIC);
+ hlen = LL_RESERVED_SPACE(dev);
+ tlen = dev->needed_tailroom;
+ skb = alloc_skb(IGMP_SIZE + hlen + tlen, GFP_ATOMIC);
if (skb == NULL) {
ip_rt_put(rt);
return -1;
@@ -669,7 +674,7 @@ static int igmp_send_report(struct in_device *in_dev, struct ip_mc_list *pmc,
skb_dst_set(skb, &rt->dst);
- skb_reserve(skb, LL_RESERVED_SPACE(dev));
+ skb_reserve(skb, hlen);
skb_reset_network_header(skb);
iph = ip_hdr(skb);
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 0da2afc..adcac64 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -763,13 +763,15 @@ static void __init ic_bootp_send_if(struct ic_device *d, unsigned long jiffies_d
struct sk_buff *skb;
struct bootp_pkt *b;
struct iphdr *h;
+ int hlen = LL_RESERVED_SPACE(dev);
+ int tlen = dev->needed_tailroom;
/* Allocate packet */
- skb = alloc_skb(sizeof(struct bootp_pkt) + LL_ALLOCATED_SPACE(dev) + 15,
+ skb = alloc_skb(sizeof(struct bootp_pkt) + hlen + tlen + 15,
GFP_KERNEL);
if (!skb)
return;
- skb_reserve(skb, LL_RESERVED_SPACE(dev));
+ skb_reserve(skb, hlen);
b = (struct bootp_pkt *) skb_put(skb, sizeof(struct bootp_pkt));
memset(b, 0, sizeof(struct bootp_pkt));
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 007e2eb..e6c1f0e 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -327,6 +327,7 @@ static int raw_send_hdrinc(struct sock *sk, struct flowi4 *fl4,
unsigned int iphlen;
int err;
struct rtable *rt = *rtp;
+ int hlen, tlen;
if (length > rt->dst.dev->mtu) {
ip_local_error(sk, EMSGSIZE, fl4->daddr, inet->inet_dport,
@@ -336,12 +337,14 @@ static int raw_send_hdrinc(struct sock *sk, struct flowi4 *fl4,
if (flags&MSG_PROBE)
goto out;
+ hlen = LL_RESERVED_SPACE(rt->dst.dev);
+ tlen = rt->dst.dev->needed_tailroom;
skb = sock_alloc_send_skb(sk,
- length + LL_ALLOCATED_SPACE(rt->dst.dev) + 15,
+ length + hlen + tlen + 15,
flags & MSG_DONTWAIT, &err);
if (skb == NULL)
goto error;
- skb_reserve(skb, LL_RESERVED_SPACE(rt->dst.dev));
+ skb_reserve(skb, hlen);
skb->priority = sk->sk_priority;
skb->mark = sk->sk_mark;
^ permalink raw reply related
* [PATCH 3/6] net: Remove all uses of LL_ALLOCATED_SPACE
From: Herbert Xu @ 2011-11-18 12:20 UTC (permalink / raw)
To: David Miller, eric.dumazet, evonlanthen, linux-kernel, netdev,
timo.teras
In-Reply-To: <20111118121832.GA2868@gondor.apana.org.au>
net: Remove all uses of LL_ALLOCATED_SPACE
The macro LL_ALLOCATED_SPACE was ill-conceived. It applies the
alignment to the sum of needed_headroom and needed_tailroom. As
the amount that is then reserved for head room is needed_headroom
with alignment, this means that the tail room left may be too small.
This patch replaces all uses of LL_ALLOCATED_SPACE with the macro
LL_RESERVED_SPACE and direct reference to needed_tailroom.
This also fixes the problem with needed_headroom changing between
allocating the skb and reserving the head room.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
net/core/netpoll.c | 6 ++++--
net/econet/af_econet.c | 7 +++++--
net/ieee802154/dgram.c | 7 +++++--
net/ieee802154/raw.c | 7 +++++--
net/packet/af_packet.c | 18 +++++++++++-------
5 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index cf64c1f..1a7d8e2 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -422,6 +422,7 @@ static void arp_reply(struct sk_buff *skb)
struct sk_buff *send_skb;
struct netpoll *np, *tmp;
unsigned long flags;
+ int hlen, tlen;
int hits = 0;
if (list_empty(&npinfo->rx_np))
@@ -479,8 +480,9 @@ static void arp_reply(struct sk_buff *skb)
if (tip != np->local_ip)
continue;
- send_skb = find_skb(np, size + LL_ALLOCATED_SPACE(np->dev),
- LL_RESERVED_SPACE(np->dev));
+ hlen = LL_RESERVED_SPACE(np->dev);
+ tlen = np->dev->needed_tailroom;
+ send_skb = find_skb(np, size + hlen + tlen, hlen);
if (!send_skb)
continue;
diff --git a/net/econet/af_econet.c b/net/econet/af_econet.c
index 1c1f26c..7e717cb 100644
--- a/net/econet/af_econet.c
+++ b/net/econet/af_econet.c
@@ -322,6 +322,7 @@ static int econet_sendmsg(struct kiocb *iocb, struct socket *sock,
/* Real hardware Econet. We're not worthy etc. */
#ifdef CONFIG_ECONET_NATIVE
unsigned short proto = 0;
+ int hlen, tlen;
int res;
if (len + 15 > dev->mtu) {
@@ -331,12 +332,14 @@ static int econet_sendmsg(struct kiocb *iocb, struct socket *sock,
dev_hold(dev);
- skb = sock_alloc_send_skb(sk, len + LL_ALLOCATED_SPACE(dev),
+ hlen = LL_RESERVED_SPACE(dev);
+ tlen = dev->needed_tailroom;
+ skb = sock_alloc_send_skb(sk, len + hlen + tlen,
msg->msg_flags & MSG_DONTWAIT, &err);
if (skb == NULL)
goto out_unlock;
- skb_reserve(skb, LL_RESERVED_SPACE(dev));
+ skb_reserve(skb, hlen);
skb_reset_network_header(skb);
eb = (struct ec_cb *)&skb->cb;
diff --git a/net/ieee802154/dgram.c b/net/ieee802154/dgram.c
index faecf64..1b09eaa 100644
--- a/net/ieee802154/dgram.c
+++ b/net/ieee802154/dgram.c
@@ -209,6 +209,7 @@ static int dgram_sendmsg(struct kiocb *iocb, struct sock *sk,
unsigned mtu;
struct sk_buff *skb;
struct dgram_sock *ro = dgram_sk(sk);
+ int hlen, tlen;
int err;
if (msg->msg_flags & MSG_OOB) {
@@ -229,13 +230,15 @@ static int dgram_sendmsg(struct kiocb *iocb, struct sock *sk,
mtu = dev->mtu;
pr_debug("name = %s, mtu = %u\n", dev->name, mtu);
- skb = sock_alloc_send_skb(sk, LL_ALLOCATED_SPACE(dev) + size,
+ hlen = LL_RESERVED_SPACE(dev);
+ tlen = dev->needed_tailroom;
+ skb = sock_alloc_send_skb(sk, hlen + tlen + size,
msg->msg_flags & MSG_DONTWAIT,
&err);
if (!skb)
goto out_dev;
- skb_reserve(skb, LL_RESERVED_SPACE(dev));
+ skb_reserve(skb, hlen);
skb_reset_network_header(skb);
diff --git a/net/ieee802154/raw.c b/net/ieee802154/raw.c
index 10970ca..f96bae8 100644
--- a/net/ieee802154/raw.c
+++ b/net/ieee802154/raw.c
@@ -108,6 +108,7 @@ static int raw_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
struct net_device *dev;
unsigned mtu;
struct sk_buff *skb;
+ int hlen, tlen;
int err;
if (msg->msg_flags & MSG_OOB) {
@@ -137,12 +138,14 @@ static int raw_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
goto out_dev;
}
- skb = sock_alloc_send_skb(sk, LL_ALLOCATED_SPACE(dev) + size,
+ hlen = LL_RESERVED_SPACE(dev);
+ tlen = dev->needed_tailroom;
+ skb = sock_alloc_send_skb(sk, hlen + tlen + size,
msg->msg_flags & MSG_DONTWAIT, &err);
if (!skb)
goto out_dev;
- skb_reserve(skb, LL_RESERVED_SPACE(dev));
+ skb_reserve(skb, hlen);
skb_reset_mac_header(skb);
skb_reset_network_header(skb);
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 82a6f34..71c1a75 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1944,7 +1944,7 @@ static void tpacket_destruct_skb(struct sk_buff *skb)
static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
void *frame, struct net_device *dev, int size_max,
- __be16 proto, unsigned char *addr)
+ __be16 proto, unsigned char *addr, int hlen)
{
union {
struct tpacket_hdr *h1;
@@ -1978,7 +1978,7 @@ static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
return -EMSGSIZE;
}
- skb_reserve(skb, LL_RESERVED_SPACE(dev));
+ skb_reserve(skb, hlen);
skb_reset_network_header(skb);
data = ph.raw + po->tp_hdrlen - sizeof(struct sockaddr_ll);
@@ -2053,6 +2053,7 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
unsigned char *addr;
int len_sum = 0;
int status = 0;
+ int hlen, tlen;
mutex_lock(&po->pg_vec_lock);
@@ -2101,16 +2102,17 @@ static int tpacket_snd(struct packet_sock *po, struct msghdr *msg)
}
status = TP_STATUS_SEND_REQUEST;
+ hlen = LL_RESERVED_SPACE(dev);
+ tlen = dev->needed_tailroom;
skb = sock_alloc_send_skb(&po->sk,
- LL_ALLOCATED_SPACE(dev)
- + sizeof(struct sockaddr_ll),
+ hlen + tlen + sizeof(struct sockaddr_ll),
0, &err);
if (unlikely(skb == NULL))
goto out_status;
tp_len = tpacket_fill_skb(po, skb, ph, dev, size_max, proto,
- addr);
+ addr, hlen);
if (unlikely(tp_len < 0)) {
if (po->tp_loss) {
@@ -2207,6 +2209,7 @@ static int packet_snd(struct socket *sock,
int vnet_hdr_len;
struct packet_sock *po = pkt_sk(sk);
unsigned short gso_type = 0;
+ int hlen, tlen;
/*
* Get and verify the address.
@@ -2291,8 +2294,9 @@ static int packet_snd(struct socket *sock,
goto out_unlock;
err = -ENOBUFS;
- skb = packet_alloc_skb(sk, LL_ALLOCATED_SPACE(dev),
- LL_RESERVED_SPACE(dev), len, vnet_hdr.hdr_len,
+ hlen = LL_RESERVED_SPACE(dev);
+ tlen = dev->needed_tailroom;
+ skb = packet_alloc_skb(sk, hlen + tlen, hlen, len, vnet_hdr.hdr_len,
msg->msg_flags & MSG_DONTWAIT, &err);
if (skb == NULL)
goto out_unlock;
^ permalink raw reply related
* (unknown),
From: Madhvapathi Sriram @ 2011-11-18 12:18 UTC (permalink / raw)
To: netdev
Hi,
In register_netdevice(), BUG_ON(dev->reg_state != NETREG_UNINITIALIZED) is
used to check if the device that is being registered is indeed a new one.
However, I see that this state is never moved to. It only happens when a
netdevice is allocated (by default to 0 using kzalloc).
So, the cycle register-->unregister-->register would fail since in the
unregister_netdevice the state is only moved to NETREG_UNREGISTERED (at max
to NETREG_RELEASED using free_netdev)
So, I presume that to reinitialize a netdevice one has to free the
netdevice, re allocate netdevice and only then re register.
Wondering why unregister and reregister is not allowed, rather than having
go through the free/alloc cycle - I am not an expert though.
Thanks
-Sriram
^ permalink raw reply
* [0/6] Replace LL_ALLOCATED_SPACE to allow needed_headroom adjustment
From: Herbert Xu @ 2011-11-18 12:18 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, evonlanthen, linux-kernel, netdev, timo.teras
In-Reply-To: <20111025.231204.257472162924919077.davem@davemloft.net>
On Tue, Oct 25, 2011 at 11:12:04PM -0400, David Miller wrote:
> From: Herbert Xu <herbert@gondor.hengli.com.au>
> Date: Tue, 25 Oct 2011 13:54:25 +0200
>
> > So I'm going to get rid of LL_ALLOCATED_SPACE completely and
> > replace it with explicit references to the tailroom as it doesn't
> > need the alignment anyway (The headroom needs alignment since
> > we use it to ensure the head is aligned).
>
> Ok.
Here are the patches that do this. I also picked up one spot
that should have used LL_ALLOCATED_SPACE but did not (see 2nd
last patch).
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] Don't allow sharing of tx skbs on xen-netfront
From: Neil Horman @ 2011-11-18 12:09 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev@vger.kernel.org, David S. Miller, Jeremy Fitzhardinge,
Konrad Rzeszutek Wilk, xen-devel@lists.xensource.com
In-Reply-To: <1321617190.3664.338.camel@zakaz.uk.xensource.com>
On Fri, Nov 18, 2011 at 11:53:09AM +0000, Ian Campbell wrote:
> On Fri, 2011-11-18 at 11:48 +0000, Neil Horman wrote:
> > On Fri, Nov 18, 2011 at 10:30:13AM +0000, Ian Campbell wrote:
> > > On Thu, 2011-11-17 at 20:45 +0000, Neil Horman wrote:
> > > > On Thu, Nov 17, 2011 at 08:17:01PM +0000, Ian Campbell wrote:
> > > > > On Thu, 2011-11-17 at 19:25 +0000, Neil Horman wrote:
> > > > > > On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> > > > > > > On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > > > > > > > It was pointed out to me recently that the xen-netfront driver can't safely
> > > > > > > > support shared skbs on transmit, since, while it doesn't maintain skb state
> > > > > > > > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > > > > > > > the hypervisor may expect the contents of the skb to remain stable. Clearing
> > > > > > > > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> > > > > > >
> > > > > > > What are the actual constraints here? The skb is used as a handle to the
> > > > > > > skb->data and shinfo (frags) and to complete at the end. It's actually
> > > > > > > those which are passed to the hypervisor (effectively the same as
> > > > > > > passing those addresses to the h/w for DMA).
> > > > > > >
> > > > > > > Which parts of the skb are expected/allowed to not remain stable?
> > > > > > >
> > > > > > > (Appologies if the above seems naive, I seem to have missed the
> > > > > > > introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> > > > > > >
> > > > > > Its ok, this is the most accurate description from the previous threads on the
> > > > > > subject:
> > > > > > 2
> > > > > >
> > > > > > The basic problem boils down the notion that some drivers, when they receive an
> > > > > > skb in their xmit paths, presume to have sole ownership of the skb, and as a
> > > > > > result may do things like add the skb to a list, or otherwise store stateful
> > > > > > data in the skb. If the skb is shared, thats unsafe to do, as the stack still
> > > > > > holds a reference to the skb, and make make changes without serializing them
> > > > > > against the driver. So we have to flag those drivers which preform these kinds
> > > > > > of actions. xen-netfront doesn't strictly speaking modify any state directly ni
> > > > > > an skb, but it does place a pointer to the skb in a data structure here:
> > > > > >
> > > > > > np->tx_skbs[id].skb = skb;
> > > > > >
> > > > > > Which then gets handed off to the hypervisior. Since the hypervisor now has
> > > > > > access to that skb pointer, and we can't be sure (from the guest perspective),
> > > > > > what it does with that information, it would be better to be safe by disallowing
> > > > > > shared skbs in this path.
> > > > >
> > > > > The skb pointer itself doesn't get given to the backend/hypervisor. The
> > > > > page which skb->data refers to is granted to the backend domain, as are
> > > > > the pages in the frags.
> > > > >
> > > > > I think we only need to be sure that the frontend doesn't rely on
> > > > > anything in the skb itself, right? Does skb->data or shinfo count from
> > > > > that perspective?
> > > > shinfo is definately a problem, as other devices may make modifications to it.
> > > > skb->data is probably safer, but is also potentially suspect (for instance if
> > > > another device appends an additional header to the data for instance)
> > >
> > > A device is allowed to rely on these things being stable while in its
> > > start_xmit, right? (otherwise I don't see how any device can ever
> > > cope...).
> > >
> > While the start_xmit routine is executing, yes. Its only after the driver
> > returns, that it can have no expectation of an skb's data to remain stable.
> >
> > > netfront only uses shinfo and ->data during start_xmit in order to
> > > create the necessary grant reference (which can be thought of as a DMA
> > > address passed to the virtual hardware). The only use of the stashed skb
> > > pointer outside of this are to dev_kfree_skb on tx completion (from
> > > either tx_buf_gc (normal completion) or release_tx_buf ("hardware"
> > > reset).
> > >
> > Ok, if you're certain you can guarantee that the hypervisior makes no inspection
> > of the skb after the return from the driver, then you're safe
>
> I believe this is the case, all that is exposed to the backend is the
> pfn, offset and length of the skb->data and frags at the time start_xmit
> was called.
>
Ok, if you're sure, than this can be dropped.
Neil
^ permalink raw reply
* Re: ipv4 udplite broken in >=linux-3.0 ?
From: Hagen Paul Pfeifer @ 2011-11-18 12:04 UTC (permalink / raw)
To: Jinxin Zheng; +Cc: gerrit, linux-kernel, netdev
In-Reply-To: <CABPbr_msepemFt4ezGVRk3QS0MU3F47MKimfV4Y+6jqvUrLFeA@mail.gmail.com>
* Jinxin Zheng | 2011-11-18 12:09:25 [+0800]:
>I don't know how to debug udplite. Can any one of you give me a tip on
>how to get more debug info, then I can do further test and provide
>with it?
net-next works for me:
$ sudo aptitude install netsend
$ sudo tcpdump -n -ttt -vv -i lo > pcap.trace &
$ netsend udplite receive &
$ netsend udplite transmit /etc/fstab 127.0.0.1
$ cat pcap.trace
00:00:00.000000 IP (tos 0x0, ttl 64, id 30602, offset 0, flags [DF], proto unknown (136), length 40) 127.0.0.1 > 127.0.0.1: udplite 20
00:00:00.000074 IP (tos 0x0, ttl 64, id 30603, offset 0, flags [DF], proto unknown (136), length 1125) 127.0.0.1 > 127.0.0.1: udplite 1105
Kernel version? What is the output of strace?
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Markus Trippelsdorf @ 2011-11-18 12:02 UTC (permalink / raw)
To: Alex,Shi
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, Eric Dumazet
In-Reply-To: <20111118085436.GC1615@x4.trippels.de>
On 2011.11.18 at 09:54 +0100, Markus Trippelsdorf wrote:
> On 2011.11.18 at 16:43 +0800, Alex,Shi wrote:
> > > >
> > > > The dirty flag comes from a bunch of unrelated xfs patches from Christoph, that
> > > > I'm testing right now.
> >
> > Where is the xfs patchset? I am wondering if it is due to slub code.
I begin to wonder if this might be the result of a compiler bug.
The kernel in question was compiled with gcc version 4.7.0 20111117. And
there was commit to the gcc repository today that looks suspicious:
http://gcc.gnu.org/viewcvs?view=revision&revision=181466
Will have to dig deeper, but if this turns out to be the cause of the
issue, I apologize for the noise.
--
Markus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] Don't allow sharing of tx skbs on xen-netfront
From: Ian Campbell @ 2011-11-18 11:53 UTC (permalink / raw)
To: Neil Horman
Cc: netdev@vger.kernel.org, David S. Miller, Jeremy Fitzhardinge,
Konrad Rzeszutek Wilk, xen-devel@lists.xensource.com
In-Reply-To: <20111118114839.GA7907@hmsreliant.think-freely.org>
On Fri, 2011-11-18 at 11:48 +0000, Neil Horman wrote:
> On Fri, Nov 18, 2011 at 10:30:13AM +0000, Ian Campbell wrote:
> > On Thu, 2011-11-17 at 20:45 +0000, Neil Horman wrote:
> > > On Thu, Nov 17, 2011 at 08:17:01PM +0000, Ian Campbell wrote:
> > > > On Thu, 2011-11-17 at 19:25 +0000, Neil Horman wrote:
> > > > > On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> > > > > > On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > > > > > > It was pointed out to me recently that the xen-netfront driver can't safely
> > > > > > > support shared skbs on transmit, since, while it doesn't maintain skb state
> > > > > > > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > > > > > > the hypervisor may expect the contents of the skb to remain stable. Clearing
> > > > > > > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> > > > > >
> > > > > > What are the actual constraints here? The skb is used as a handle to the
> > > > > > skb->data and shinfo (frags) and to complete at the end. It's actually
> > > > > > those which are passed to the hypervisor (effectively the same as
> > > > > > passing those addresses to the h/w for DMA).
> > > > > >
> > > > > > Which parts of the skb are expected/allowed to not remain stable?
> > > > > >
> > > > > > (Appologies if the above seems naive, I seem to have missed the
> > > > > > introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> > > > > >
> > > > > Its ok, this is the most accurate description from the previous threads on the
> > > > > subject:
> > > > > 2
> > > > >
> > > > > The basic problem boils down the notion that some drivers, when they receive an
> > > > > skb in their xmit paths, presume to have sole ownership of the skb, and as a
> > > > > result may do things like add the skb to a list, or otherwise store stateful
> > > > > data in the skb. If the skb is shared, thats unsafe to do, as the stack still
> > > > > holds a reference to the skb, and make make changes without serializing them
> > > > > against the driver. So we have to flag those drivers which preform these kinds
> > > > > of actions. xen-netfront doesn't strictly speaking modify any state directly ni
> > > > > an skb, but it does place a pointer to the skb in a data structure here:
> > > > >
> > > > > np->tx_skbs[id].skb = skb;
> > > > >
> > > > > Which then gets handed off to the hypervisior. Since the hypervisor now has
> > > > > access to that skb pointer, and we can't be sure (from the guest perspective),
> > > > > what it does with that information, it would be better to be safe by disallowing
> > > > > shared skbs in this path.
> > > >
> > > > The skb pointer itself doesn't get given to the backend/hypervisor. The
> > > > page which skb->data refers to is granted to the backend domain, as are
> > > > the pages in the frags.
> > > >
> > > > I think we only need to be sure that the frontend doesn't rely on
> > > > anything in the skb itself, right? Does skb->data or shinfo count from
> > > > that perspective?
> > > shinfo is definately a problem, as other devices may make modifications to it.
> > > skb->data is probably safer, but is also potentially suspect (for instance if
> > > another device appends an additional header to the data for instance)
> >
> > A device is allowed to rely on these things being stable while in its
> > start_xmit, right? (otherwise I don't see how any device can ever
> > cope...).
> >
> While the start_xmit routine is executing, yes. Its only after the driver
> returns, that it can have no expectation of an skb's data to remain stable.
>
> > netfront only uses shinfo and ->data during start_xmit in order to
> > create the necessary grant reference (which can be thought of as a DMA
> > address passed to the virtual hardware). The only use of the stashed skb
> > pointer outside of this are to dev_kfree_skb on tx completion (from
> > either tx_buf_gc (normal completion) or release_tx_buf ("hardware"
> > reset).
> >
> Ok, if you're certain you can guarantee that the hypervisior makes no inspection
> of the skb after the return from the driver, then you're safe
I believe this is the case, all that is exposed to the backend is the
pfn, offset and length of the skb->data and frags at the time start_xmit
was called.
> Neil
>
> > Ian.
> >
> >
^ 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