* (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
* [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
* [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 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 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 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 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
* 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
* 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
* 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: 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: 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
* 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: 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
* 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: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
* [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
* [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] 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
* 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
* Re: [PATCH] xen-netback: use correct index for invalidation in netbk_tx_check_mop()
From: Ian Campbell @ 2011-11-18 15:38 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: stable, xen-devel@lists.xensource.com, Jan Beulich
In-Reply-To: <1321628966.3664.363.camel@zakaz.uk.xensource.com>
On Fri, 2011-11-18 at 15:09 +0000, Ian Campbell wrote:
> 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.
I also neglected to change the subject line to the correct upstream
function name. Please ignore this patch, I'll try again...
Ian.
>
> > ---
> > 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);
> > }
> >
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: PROBLEM: pppol2tp over pppoe NULL pointer dereference
From: Окунев Дмитрий Юрьевич @ 2011-11-18 15:35 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hello.
I just want to notify, that patch in the subject works well. Panics disappeared.
Best regards, Dmitry.
^ permalink raw reply
* Re: [RFC] [ver3 PATCH 3/6] virtio_net: virtio_net driver changes
From: Ben Hutchings @ 2011-11-18 15:40 UTC (permalink / raw)
To: Sasha Levin; +Cc: Krishna Kumar, rusty, mst, netdev, kvm, davem, virtualization
In-Reply-To: <1321597481.8010.19.camel@lappy>
On Fri, 2011-11-18 at 08:24 +0200, Sasha Levin wrote:
> On Fri, 2011-11-18 at 01:08 +0000, Ben Hutchings wrote:
> > On Fri, 2011-11-11 at 18:34 +0530, Krishna Kumar wrote:
> > > Changes for multiqueue virtio_net driver.
> > [...]
> > > @@ -677,25 +730,35 @@ static struct rtnl_link_stats64 *virtnet
> > > {
> > > struct virtnet_info *vi = netdev_priv(dev);
> > > int cpu;
> > > - unsigned int start;
> > >
> > > for_each_possible_cpu(cpu) {
> > > - struct virtnet_stats __percpu *stats
> > > - = per_cpu_ptr(vi->stats, cpu);
> > > - u64 tpackets, tbytes, rpackets, rbytes;
> > > -
> > > - do {
> > > - start = u64_stats_fetch_begin(&stats->syncp);
> > > - tpackets = stats->tx_packets;
> > > - tbytes = stats->tx_bytes;
> > > - rpackets = stats->rx_packets;
> > > - rbytes = stats->rx_bytes;
> > > - } while (u64_stats_fetch_retry(&stats->syncp, start));
> > > -
> > > - tot->rx_packets += rpackets;
> > > - tot->tx_packets += tpackets;
> > > - tot->rx_bytes += rbytes;
> > > - tot->tx_bytes += tbytes;
> > > + int qpair;
> > > +
> > > + for (qpair = 0; qpair < vi->num_queue_pairs; qpair++) {
> > > + struct virtnet_send_stats __percpu *tx_stat;
> > > + struct virtnet_recv_stats __percpu *rx_stat;
> >
> > While you're at it, you can drop the per-CPU stats and make them only
> > per-queue. There is unlikely to be any benefit in maintaining them
> > per-CPU while receive and transmit processing is serialised per-queue.
>
> It allows you to update stats without a lock.
But you'll already be holding a lock related to the queue.
> Whats the benefit of having them per queue?
It should save some memory (and a little time when summing stats, though
that's unlikely to matter much).
The important thing is that splitting up stats per-CPU *and* per-queue
is a waste.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] xen-netback: use correct index for invalidation in xen_netbk_tx_check_gop()
From: Ian Campbell @ 2011-11-18 15:42 UTC (permalink / raw)
To: netdev; +Cc: xen-devel, Jan Beulich, Jan Beulich, Ian Campbell, stable
From: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: stable@vger.kernel.org
---
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: [PATCH] ethtool: Use kmemdup rather than duplicating its implementation
From: Ben Hutchings @ 2011-11-18 15:47 UTC (permalink / raw)
To: Thomas Meyer; +Cc: netdev, linux-kernel
In-Reply-To: <1321571135.1624.313.camel@localhost.localdomain>
On Fri, 2011-11-18 at 00:05 +0100, Thomas Meyer wrote:
> The semantic patch that makes this change is available
> in scripts/coccinelle/api/memdup.cocci.
>
> Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
> ---
The one-line description should refer to 'gianfar', not 'ethtool'.
(I expect David will fix this up.)
Ben.
> diff -u -p a/drivers/net/ethernet/freescale/gianfar_ethtool.c b/drivers/net/ethernet/freescale/gianfar_ethtool.c
> --- a/drivers/net/ethernet/freescale/gianfar_ethtool.c 2011-11-07 19:37:57.036756543 +0100
> +++ b/drivers/net/ethernet/freescale/gianfar_ethtool.c 2011-11-08 10:42:14.842512269 +0100
> @@ -1410,10 +1410,9 @@ static int gfar_optimize_filer_masks(str
>
> /* We need a copy of the filer table because
> * we want to change its order */
> - temp_table = kmalloc(sizeof(*temp_table), GFP_KERNEL);
> + temp_table = kmemdup(tab, sizeof(*temp_table), GFP_KERNEL);
> if (temp_table == NULL)
> return -ENOMEM;
> - memcpy(temp_table, tab, sizeof(*temp_table));
>
> mask_table = kcalloc(MAX_FILER_CACHE_IDX / 2 + 1,
> sizeof(struct gfar_mask_entry), GFP_KERNEL);
>
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ 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