* Re: [patch net-next v5 05/11] sch: make htb_rate_cfg and functions around that generic
From: David Miller @ 2013-02-13 0:00 UTC (permalink / raw)
To: jiri; +Cc: netdev, edumazet, jhs, kuznet, j.vimal
In-Reply-To: <1360663929-1023-6-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 12 Feb 2013 11:12:03 +0100
> As it is going to be used in tbf as well, push these to generic code.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [patch net-next v5 04/11] htb: initialize cl->tokens and cl->ctokens correctly
From: David Miller @ 2013-02-13 0:00 UTC (permalink / raw)
To: jiri; +Cc: netdev, edumazet, jhs, kuznet, j.vimal
In-Reply-To: <1360663929-1023-5-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 12 Feb 2013 11:12:02 +0100
> These are in ns so convert from ticks to ns.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [patch net-next v5 03/11] htb: remove pointless first initialization of buffer and cbuffer
From: David Miller @ 2013-02-13 0:00 UTC (permalink / raw)
To: jiri; +Cc: netdev, edumazet, jhs, kuznet, j.vimal
In-Reply-To: <1360663929-1023-4-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 12 Feb 2013 11:12:01 +0100
> these are initialized correctly couple of lines later in the function.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [patch net-next v5 01/11] htb: use PSCHED_TICKS2NS()
From: David Miller @ 2013-02-13 0:00 UTC (permalink / raw)
To: jiri; +Cc: netdev, edumazet, jhs, kuznet, j.vimal
In-Reply-To: <1360663929-1023-2-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 12 Feb 2013 11:11:59 +0100
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [patch net-next v5 02/11] htb: fix values in opt dump
From: David Miller @ 2013-02-12 23:51 UTC (permalink / raw)
To: jiri; +Cc: netdev, edumazet, jhs, kuznet, j.vimal
In-Reply-To: <1360663929-1023-3-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 12 Feb 2013 11:12:00 +0100
> in htb_change_class() cl->buffer and cl->buffer are stored in ns.
> So in dump, convert them back to psched ticks.
>
> Note this was introduced by:
> commit 56b765b79e9a78dc7d3f8850ba5e5567205a3ecd
> htb: improved accuracy at high rates
>
> Please consider this for -net/-stable.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied to 'net' and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] net: ethernet: ti: remove redundant NULL check.
From: David Miller @ 2013-02-12 23:48 UTC (permalink / raw)
To: tipecaml
Cc: linux-kernel, kernel-janitors, mugunthanvnm, zonque, hotforest,
Julia.Lawall, netdev
In-Reply-To: <511AC831.80704@gmail.com>
From: Cyril Roelandt <tipecaml@gmail.com>
Date: Tue, 12 Feb 2013 23:54:41 +0100
> Ok, I resent, though I forgot to add "v2".
Don't worry about that.
^ permalink raw reply
* how to handle bonding failover when using a bridge over the bond?
From: Chris Friesen @ 2013-02-12 23:19 UTC (permalink / raw)
To: bonding-devel, Jay Vosburgh, netdev
I've got a scenario that seems to be not well handled with the current
bonding code in linux, but maybe I'm missing something.
I have a physical host with two ethernet links that are bonded together
(active/backup). Each link is connected to a separate L2 switch, which
are in turn connected with a crosslink for redundancy.
The physical host is running multiple virtual machines each with a
virtual adapter. The virtual adapters and the bond are all bridged
together to allow communication between the virtual machines, the host,
and the outside world.
Now suppose one of the slave links fails. The bond device will failover
to the other slave and send out a gratuitous arp on the newly active
slave. This will cause the L2 switches to update their lookup tables
for the MAC address associated with the bond (so it now points to the
newly active slave), but doesn't update the MAC addresses associated
with the various virtual machines. If someone on the network sends a
packet to one of the virtual machines, the switch will try to send it
over the failed slave.
What's the recommended solution for this? The logical solution would
seem to be to have something issue GARPs for each virtual machine when
the bond device fails over, but there doesn't seem to be any way to
register for notification (via rtnetlink for instance) when the bond
fails over. I could monitor for carrier loss, but that wouldn't work
for the case where bonding is using arp monitoring.
Any suggestions?
Thanks,
Chris
^ permalink raw reply
* Re: [PATCH] net: ethernet: ti: remove redundant NULL check.
From: Cyril Roelandt @ 2013-02-12 22:54 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, kernel-janitors, mugunthanvnm, zonque, hotforest,
Julia.Lawall, netdev
In-Reply-To: <20130212.170650.89534546100043269.davem@davemloft.net>
On 02/12/2013 11:06 PM, David Miller wrote:
> From: Cyril Roelandt<tipecaml@gmail.com>
> Date: Tue, 12 Feb 2013 22:54:46 +0100
>
>> cpdma_chan_destroy() on a NULL pointer is a no-op, so the NULL check in
>> cpdma_ctlr_destroy() can safely be removed.
>>
>> Signed-off-by: Cyril Roelandt<tipecaml@gmail.com>
> ...
>> @@ -450,8 +450,7 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
>> cpdma_ctlr_stop(ctlr);
>>
>> for (i = 0; i< ARRAY_SIZE(ctlr->channels); i++) {
>> - if (ctlr->channels[i])
>> - cpdma_chan_destroy(ctlr->channels[i]);
>> + cpdma_chan_destroy(ctlr->channels[i]);
>> }
>
> SInce this is now a single statement basic block, remove the
> surrounding braces.
Ok, I resent, though I forgot to add "v2".
Regards,
Cyril Roelandt.
^ permalink raw reply
* [PATCH] net: ethernet: ti: remove redundant NULL check.
From: Cyril Roelandt @ 2013-02-12 22:52 UTC (permalink / raw)
To: davem
Cc: linux-kernel, kernel-janitors, mugunthanvnm, zonque, hotforest,
Julia.Lawall, netdev, Cyril Roelandt
In-Reply-To: <20130212.170650.89534546100043269.davem@davemloft.net>
cpdma_chan_destroy() on a NULL pointer is a no-op, so the NULL check in
cpdma_ctlr_destroy() can safely be removed.
Signed-off-by: Cyril Roelandt <tipecaml@gmail.com>
---
drivers/net/ethernet/ti/davinci_cpdma.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index f862918..1c4b0aa 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -449,10 +449,8 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
if (ctlr->state != CPDMA_STATE_IDLE)
cpdma_ctlr_stop(ctlr);
- for (i = 0; i < ARRAY_SIZE(ctlr->channels); i++) {
- if (ctlr->channels[i])
- cpdma_chan_destroy(ctlr->channels[i]);
- }
+ for (i = 0; i < ARRAY_SIZE(ctlr->channels); i++)
+ cpdma_chan_destroy(ctlr->channels[i]);
cpdma_desc_pool_destroy(ctlr->pool);
spin_unlock_irqrestore(&ctlr->lock, flags);
--
1.7.10.4
^ permalink raw reply related
* [PATCH net-next 3/3] ipv6: stop multicast forwarding to process reserved/interface/link scoped addresses
From: Hannes Frederic Sowa @ 2013-02-12 22:16 UTC (permalink / raw)
To: netdev; +Cc: yoshfuji
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/ipv6/ip6_input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 5b10414..7cae63ad 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -279,7 +279,7 @@ int ip6_mc_input(struct sk_buff *skb)
* IPv6 multicast router mode is now supported ;)
*/
if (dev_net(skb->dev)->ipv6.devconf_all->mc_forwarding &&
- !(ipv6_addr_type(&hdr->daddr) & IPV6_ADDR_LINKLOCAL) &&
+ !__ipv6_addr_needs_scope_id(__ipv6_addr_type(&hdr->daddr)) &&
likely(!(IP6CB(skb)->flags & IP6SKB_FORWARDED))) {
/*
* Okay, we try to forward - split and duplicate
--
1.8.1.2
^ permalink raw reply related
* [PATCH net-next 2/3] ipv6: use newly introduced __ipv6_addr_needs_scope_id and ipv6_iface_scope_id
From: Hannes Frederic Sowa @ 2013-02-12 22:16 UTC (permalink / raw)
To: netdev; +Cc: yoshfuji
This patch requires multicast interface-scoped addresses to supply a
sin6_scope_id. Because the sin6_scope_id is now also correctly used
in case of interface-scoped multicast traffic this enables one to use
interface scoped addresses over interfaces which are not targeted by the
default multicast route (the route has to be put there manually, though).
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/ipv6/af_inet6.c | 6 +++---
net/ipv6/datagram.c | 18 ++++++++++--------
net/ipv6/icmp.c | 2 +-
net/ipv6/inet6_connection_sock.c | 6 ++----
net/ipv6/raw.c | 9 ++++-----
net/ipv6/udp.c | 14 ++++++++------
6 files changed, 28 insertions(+), 27 deletions(-)
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index 6b793bf..f56277f 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -323,7 +323,7 @@ int inet6_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
struct net_device *dev = NULL;
rcu_read_lock();
- if (addr_type & IPV6_ADDR_LINKLOCAL) {
+ if (__ipv6_addr_needs_scope_id(addr_type)) {
if (addr_len >= sizeof(struct sockaddr_in6) &&
addr->sin6_scope_id) {
/* Override any existing binding, if another one
@@ -471,8 +471,8 @@ int inet6_getname(struct socket *sock, struct sockaddr *uaddr,
sin->sin6_port = inet->inet_sport;
}
- if (ipv6_addr_type(&sin->sin6_addr) & IPV6_ADDR_LINKLOCAL)
- sin->sin6_scope_id = sk->sk_bound_dev_if;
+ sin->sin6_scope_id = ipv6_iface_scope_id(&sin->sin6_addr,
+ sk->sk_bound_dev_if);
*uaddr_len = sizeof(*sin);
return 0;
}
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index f5a5478..e356022 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -124,7 +124,7 @@ ipv4_connected:
goto out;
}
- if (addr_type&IPV6_ADDR_LINKLOCAL) {
+ if (__ipv6_addr_needs_scope_id(addr_type)) {
if (addr_len >= sizeof(struct sockaddr_in6) &&
usin->sin6_scope_id) {
if (sk->sk_bound_dev_if &&
@@ -355,18 +355,19 @@ int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len)
sin->sin6_family = AF_INET6;
sin->sin6_flowinfo = 0;
sin->sin6_port = serr->port;
- sin->sin6_scope_id = 0;
if (skb->protocol == htons(ETH_P_IPV6)) {
const struct ipv6hdr *ip6h = container_of((struct in6_addr *)(nh + serr->addr_offset),
struct ipv6hdr, daddr);
sin->sin6_addr = ip6h->daddr;
if (np->sndflow)
sin->sin6_flowinfo = ip6_flowinfo(ip6h);
- if (ipv6_addr_type(&sin->sin6_addr) & IPV6_ADDR_LINKLOCAL)
- sin->sin6_scope_id = IP6CB(skb)->iif;
+ sin->sin6_scope_id =
+ ipv6_iface_scope_id(&sin->sin6_addr,
+ IP6CB(skb)->iif);
} else {
ipv6_addr_set_v4mapped(*(__be32 *)(nh + serr->addr_offset),
&sin->sin6_addr);
+ sin->sin6_scope_id = 0;
}
}
@@ -376,18 +377,19 @@ int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len)
if (serr->ee.ee_origin != SO_EE_ORIGIN_LOCAL) {
sin->sin6_family = AF_INET6;
sin->sin6_flowinfo = 0;
- sin->sin6_scope_id = 0;
if (skb->protocol == htons(ETH_P_IPV6)) {
sin->sin6_addr = ipv6_hdr(skb)->saddr;
if (np->rxopt.all)
ip6_datagram_recv_ctl(sk, msg, skb);
- if (ipv6_addr_type(&sin->sin6_addr) & IPV6_ADDR_LINKLOCAL)
- sin->sin6_scope_id = IP6CB(skb)->iif;
+ sin->sin6_scope_id =
+ ipv6_iface_scope_id(&sin->sin6_addr,
+ IP6CB(skb)->iif);
} else {
struct inet_sock *inet = inet_sk(sk);
ipv6_addr_set_v4mapped(ip_hdr(skb)->saddr,
&sin->sin6_addr);
+ sin->sin6_scope_id = 0;
if (inet->cmsg_flags)
ip_cmsg_recv(msg, skb);
}
@@ -653,7 +655,7 @@ int ip6_datagram_send_ctl(struct net *net, struct sock *sk,
rcu_read_unlock();
return -ENODEV;
}
- } else if (addr_type & IPV6_ADDR_LINKLOCAL) {
+ } else if (__ipv6_addr_needs_scope_id(addr_type)) {
rcu_read_unlock();
return -EINVAL;
}
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index fff5bdd..71b900c 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -434,7 +434,7 @@ void icmpv6_send(struct sk_buff *skb, u8 type, u8 code, __u32 info)
* Source addr check
*/
- if (addr_type & IPV6_ADDR_LINKLOCAL)
+ if (__ipv6_addr_needs_scope_id(addr_type))
iif = skb->dev->ifindex;
/*
diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c
index b386a2c..9f1020b 100644
--- a/net/ipv6/inet6_connection_sock.c
+++ b/net/ipv6/inet6_connection_sock.c
@@ -170,10 +170,8 @@ void inet6_csk_addr2sockaddr(struct sock *sk, struct sockaddr * uaddr)
sin6->sin6_port = inet_sk(sk)->inet_dport;
/* We do not store received flowlabel for TCP */
sin6->sin6_flowinfo = 0;
- sin6->sin6_scope_id = 0;
- if (sk->sk_bound_dev_if &&
- ipv6_addr_type(&sin6->sin6_addr) & IPV6_ADDR_LINKLOCAL)
- sin6->sin6_scope_id = sk->sk_bound_dev_if;
+ sin6->sin6_scope_id = ipv6_iface_scope_id(&sin6->sin6_addr,
+ sk->sk_bound_dev_if);
}
EXPORT_SYMBOL_GPL(inet6_csk_addr2sockaddr);
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 70fa814..0a540f2 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -264,7 +264,7 @@ static int rawv6_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len)
if (addr_type != IPV6_ADDR_ANY) {
struct net_device *dev = NULL;
- if (addr_type & IPV6_ADDR_LINKLOCAL) {
+ if (__ipv6_addr_needs_scope_id(addr_type)) {
if (addr_len >= sizeof(struct sockaddr_in6) &&
addr->sin6_scope_id) {
/* Override any existing binding, if another
@@ -499,9 +499,8 @@ static int rawv6_recvmsg(struct kiocb *iocb, struct sock *sk,
sin6->sin6_port = 0;
sin6->sin6_addr = ipv6_hdr(skb)->saddr;
sin6->sin6_flowinfo = 0;
- sin6->sin6_scope_id = 0;
- if (ipv6_addr_type(&sin6->sin6_addr) & IPV6_ADDR_LINKLOCAL)
- sin6->sin6_scope_id = IP6CB(skb)->iif;
+ sin6->sin6_scope_id = ipv6_iface_scope_id(&sin6->sin6_addr,
+ IP6CB(skb)->iif);
}
sock_recv_ts_and_drops(msg, sk, skb);
@@ -803,7 +802,7 @@ static int rawv6_sendmsg(struct kiocb *iocb, struct sock *sk,
if (addr_len >= sizeof(struct sockaddr_in6) &&
sin6->sin6_scope_id &&
- ipv6_addr_type(daddr)&IPV6_ADDR_LINKLOCAL)
+ __ipv6_addr_needs_scope_id(ipv6_addr_scope(daddr)))
fl6.flowi6_oif = sin6->sin6_scope_id;
} else {
if (sk->sk_state != TCP_ESTABLISHED)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 599e1ba6..ba739d9 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -450,15 +450,16 @@ try_again:
sin6->sin6_family = AF_INET6;
sin6->sin6_port = udp_hdr(skb)->source;
sin6->sin6_flowinfo = 0;
- sin6->sin6_scope_id = 0;
- if (is_udp4)
+ if (is_udp4) {
ipv6_addr_set_v4mapped(ip_hdr(skb)->saddr,
&sin6->sin6_addr);
- else {
+ sin6->sin6_scope_id = 0;
+ } else {
sin6->sin6_addr = ipv6_hdr(skb)->saddr;
- if (ipv6_addr_type(&sin6->sin6_addr) & IPV6_ADDR_LINKLOCAL)
- sin6->sin6_scope_id = IP6CB(skb)->iif;
+ sin6->sin6_scope_id =
+ ipv6_iface_scope_id(&sin6->sin6_addr,
+ IP6CB(skb)->iif);
}
}
@@ -1118,7 +1119,8 @@ do_udp_sendmsg:
if (addr_len >= sizeof(struct sockaddr_in6) &&
sin6->sin6_scope_id &&
- ipv6_addr_type(daddr)&IPV6_ADDR_LINKLOCAL)
+ __ipv6_addr_needs_scope_id(
+ ipv6_addr_scope(&sin6->sin6_addr)))
fl6.flowi6_oif = sin6->sin6_scope_id;
} else {
if (sk->sk_state != TCP_ESTABLISHED)
--
1.8.1.2
^ permalink raw reply related
* [PATCH net-next 1/3] ipv6: introdcue __ipv6_addr_needs_scope_id and ipv6_iface_scope_id helper functions
From: Hannes Frederic Sowa @ 2013-02-12 22:16 UTC (permalink / raw)
To: netdev; +Cc: yoshfuji
Suggested-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/net/ipv6.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 851d541..8188d27 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -319,6 +319,18 @@ static inline int ipv6_addr_src_scope(const struct in6_addr *addr)
return __ipv6_addr_src_scope(__ipv6_addr_type(addr));
}
+static inline bool __ipv6_addr_needs_scope_id(int type)
+{
+ return type & IPV6_ADDR_LINKLOCAL ||
+ (type & IPV6_ADDR_MULTICAST &&
+ __ipv6_addr_src_scope(type) <= IPV6_ADDR_SCOPE_LINKLOCAL);
+}
+
+static inline __u32 ipv6_iface_scope_id(const struct in6_addr *addr, int iface)
+{
+ return __ipv6_addr_needs_scope_id(__ipv6_addr_type(addr)) ? iface : 0;
+}
+
static inline int ipv6_addr_cmp(const struct in6_addr *a1, const struct in6_addr *a2)
{
return memcmp(a1, a2, sizeof(struct in6_addr));
--
1.8.1.2
^ permalink raw reply related
* PROBLEM: decnet: /proc/sys/net/decnet sysctl entries disappear (2.6.27 through 3.3.x)
From: Larry Baker @ 2013-02-12 22:13 UTC (permalink / raw)
To: netdev
In-Reply-To: <FAAC90D7-8126-44CA-AACF-A5F8237C1A8E@usgs.gov>
PROBLEM
decnet: /proc/sys/net/decnet sysctl entries disappear (2.6.27 through 3.3.x)
DESCRIPTION
The decnet kernel module is configured using entries under /proc/sys/net/decnet. There are DECnet executor (host) node settings in /proc/sys/net/decnet, template network device settings in /proc/sys/net/decnet/conf/{ddcmp,ethernet,ipgre,loopback}, and active network device settings for DECnet devices in /proc/sys/net/decnet/conf/{lo,eth0,...}. The normal sequence is to load the decnet module, configure the module, then load a deamon to handle remote file access requests.
When I load the decnet module and configure it on the latest Arch Linux ARM kernel (3.1.10-15-ARCH), most of the /proc/sys/net/decnet sysctl entries disappear. I found the same behavior when I tested the decnet module on the latest CentOS (Red Hat) 6.3 x86_64 kernel (2.6.32-279.19.1.el6.x86_64). The latest CentOS 5.9 i386 kernel (2.6.18-348.1.1.el5) does not exhibit this behavior; the CentOS 6.0 i386 kernel (2.6.32-71.el6.i686) is the earliest CentOS kernel that exhibits this behavior.
This is the expected behavior (CentOS 5.9 i386):
> # modprobe decnet <--- load the decnet kernel module
> # ls /proc/sys/net/decnet <--- there are static sysctl entries in /proc/sys/net/decnet
> conf decnet_rmem di_count dst_gc_interval no_fc_max_cwnd
> debug decnet_wmem dn_count node_address time_wait
> decnet_mem default_device dr_count node_name
> # ls /proc/sys/net/decnet/conf <--- there are both static and dynamic (eth0 and lo) sysctl entries in /proc/sys/net/decnet/conf
> ddcmp eth0 ethernet ipgre lo loopback
> # echo 0.0 >/proc/sys/net/decnet/node_address <--- set the DECnet node address (the number does not matter)
> # ls /proc/sys/net/decnet <--- the sysctl entries in /proc/sys/net/decnet are still there
> conf decnet_rmem di_count dst_gc_interval no_fc_max_cwnd
> debug decnet_wmem dn_count node_address time_wait
> decnet_mem default_device dr_count node_name
> # ls /proc/sys/net/decnet/conf <--- so are the sysctl entries in /proc/sys/net/decnet/conf
> ddcmp eth0 ethernet ipgre lo loopback
This is the aberrant behavior (CentOS 6.0 i386):
> # modprobe decnet
> # ls /proc/sys/net/decnet
> conf decnet_rmem di_count dst_gc_interval no_fc_max_cwnd
> debug decnet_wmem dn_count node_address time_wait
> decnet_mem default_device dr_count node_name
> # ls /proc/sys/net/decnet/conf
> ddcmp eth0 ethernet ipgre lo loopback
> # echo 0.0 >/proc/sys/net/decnet/node_address
> # ls /proc/sys/net/decnet <--- after writing to/proc/sys/net/decnet/node_address, all the static sysctl entries in /proc/sys/net/decnet are gone
> conf
> # ls /proc/sys/net/decnet/conf <--- so are all the static sysctl entries in /proc/sys/net/decnet/conf (because only the dynamic entries have been reregistered)
> eth0 lo
DIAGNOSIS
I found that the disappearance of the decnet /proc/sys/net/decnet sysctl entries coincided with a change in the sysctl subsystem from using a list to a tree for the ctl_table data structures. I corresponded with Eric Biederman, the maintainer of sysctl, and described the change in behavior and my diagnosis that the sysctl changes were suspect. Eric described what was likely the source of the problem:
> Looking into the git history it looks like the last substantive change
> to 2.6.32 was Al Viro's sysctl optimization that avoided walking the
> entire sysctl structure on look ups. Unfortunately it made the
> assumption that there would always be an empty directory created if
> there were multiple children registered in that that directory. The
> common sysctls the few places this wasn't true were fixed rather
> quickly. Apparently for decnet no one noticed.
>
> The good news is that my latest rework of the sysctls made a verifiable
> set of assumptions. So it will probably just work although there is a
> slight chance the modern code will error out with sensible error
> message.
SOLUTION
Eric was also kind enough to verify that his later rewrite of the sysctl code cured the problem:
> My rewrite to remove the silly assumption
> and to make sysctl even more scalable was merged in 3.4-rc1. So
> anything 3.4 based or later should work.
and
> I have confirmed in the lastest kernel I can set the decnet node address
> without all of the sysctl files going away. So it looks like I fixed
> the bug you are running into.
PATCHES
I still care about running DECnet on CentOS and Arch Linux ARM. Following Eric's guidance, I rearranged the order that the /proc/sys/net/decnet sysctl entries are created and I added an empty /proc/sys/net/decnet/conf sysctl entry to workaround the sysctl tree walking bug. I made three sets of patches that cover the changes to the sysctl API over time:
. Kernels 2.6.27 through 2.6.32 (tree-structured sysctl, struct ctl_path includes .ctl_name) - e.g., for the current CentOS (Red Hat)
. Kernels 2.6.33 through 3.4.x (struct ctl_path no longer includes .ctl_name, rtnl_register() adds rtnl_calcit_func calcit) - e.g., for the current Arch Linux ARM
. Kernels 3.5 and later (register_net_sysctl()/unregister_net_sysctl_table() in place of register_sysctl_paths()/unregister_sysctl_table()) - for the current trunk
As I described in my earlier post (11 February 2013 4:26:00 PM PST), my patches include more than just this fix, so they are not yet ready to submit. However, I am using the first two in my application systems, so I am confident they work and there is no need for anyone else to work on a fix.
My questions for this forum are:
. Which patches (if any) should be submitted to netdev@vger.kernel.org?
. Which patches (if any) should be submitted to stable@vger.kernel.org?
. Should I prepare be a patch file for every kernel major.minor version?
. If not, which kernel major.minor versions should I create a patch file for?
. How should they be labeled to indicate they are related but distinct?
. The decnet dmesg banner is stale -- it has not changed in years. Should that be changed? To what? What's the numbering scheme? By me? By the maintainer?
Larry Baker
US Geological Survey
650-329-5608
baker@usgs.gov
^ permalink raw reply
* Re: [PATCH] net: ethernet: ti: remove redundant NULL check.
From: David Miller @ 2013-02-12 22:06 UTC (permalink / raw)
To: tipecaml
Cc: linux-kernel, kernel-janitors, mugunthanvnm, zonque, hotforest,
Julia.Lawall, netdev
In-Reply-To: <1360706086-31506-1-git-send-email-tipecaml@gmail.com>
From: Cyril Roelandt <tipecaml@gmail.com>
Date: Tue, 12 Feb 2013 22:54:46 +0100
> cpdma_chan_destroy() on a NULL pointer is a no-op, so the NULL check in
> cpdma_ctlr_destroy() can safely be removed.
>
> Signed-off-by: Cyril Roelandt <tipecaml@gmail.com>
...
> @@ -450,8 +450,7 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
> cpdma_ctlr_stop(ctlr);
>
> for (i = 0; i < ARRAY_SIZE(ctlr->channels); i++) {
> - if (ctlr->channels[i])
> - cpdma_chan_destroy(ctlr->channels[i]);
> + cpdma_chan_destroy(ctlr->channels[i]);
> }
SInce this is now a single statement basic block, remove the
surrounding braces.
^ permalink raw reply
* [PATCH] net: ethernet: ti: remove redundant NULL check.
From: Cyril Roelandt @ 2013-02-12 21:54 UTC (permalink / raw)
To: davem
Cc: linux-kernel, kernel-janitors, mugunthanvnm, zonque, hotforest,
Julia.Lawall, netdev, Cyril Roelandt
cpdma_chan_destroy() on a NULL pointer is a no-op, so the NULL check in
cpdma_ctlr_destroy() can safely be removed.
Signed-off-by: Cyril Roelandt <tipecaml@gmail.com>
---
drivers/net/ethernet/ti/davinci_cpdma.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index f862918..aba787b 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -450,8 +450,7 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
cpdma_ctlr_stop(ctlr);
for (i = 0; i < ARRAY_SIZE(ctlr->channels); i++) {
- if (ctlr->channels[i])
- cpdma_chan_destroy(ctlr->channels[i]);
+ cpdma_chan_destroy(ctlr->channels[i]);
}
cpdma_desc_pool_destroy(ctlr->pool);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] ip.7: Improve explanation about calling listen or connect
From: Michael Kerrisk (man-pages) @ 2013-02-12 21:48 UTC (permalink / raw)
To: Michael Kerrisk (man-pages), Peter Schiffer,
linux-man-u79uwXL29TY76Z2rM5mHXA, netdev
In-Reply-To: <20130211175000.GG31579-8Luz0qD3JK/tRgLqZ5aouw@public.gmane.org>
Hi Flavio,
On Mon, Feb 11, 2013 at 6:50 PM, Flavio Leitner <fbl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Sun, Feb 10, 2013 at 03:00:03AM +0100, Michael Kerrisk (man-pages) wrote:
>> On Wed, Jun 6, 2012 at 4:44 PM, Flavio Leitner <fbl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> >
>> > Hi,
>> >
>> > Could someone tell me what's the patch current state?
>> > It has been a month already with no feedback.
>> > thanks,
>> > fbl
>>
>> Following up, long after the fact.
>>
>> Flavio, I had no time pack then to review this patch... One problem
>> is, you never gave any rationle for the change ("Improve explanation
>> of..." is not a rationale -- I need to know *why* you think the
>> changes are needed.)
>
> Because the current explanation is not detailed enough and/or the way
> it is written may lead to a wrong interpretation, specially for non-English
> users. Therefore, it should be improved adding supporting details
> and a better writing to clarify each case.
>
> The patch adds the missing details and clarifies each use case.
>
> Thanks,
> fbl
Peter sent me some supporting technical info that you'd supplied
elsewhere. I've applied your patch now.
Thanks!
Michael
>> > On Fri, 25 May 2012 13:02:48 +0200
>> > Peter Schiffer <pschiffe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> >
>> >> Hi Michael,
>> >>
>> >> do you have any comments for this update? Or do you need some supporting
>> >> info?
>> >>
>> >> peter
>> >>
>> >> On 05/09/2012 02:30 PM, Flavio Leitner wrote:
>> >> > Signed-off-by: Flavio Leitner<fbl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> >> > ---
>> >> > man7/ip.7 | 15 +++++++++------
>> >> > 1 files changed, 9 insertions(+), 6 deletions(-)
>> >> >
>> >> > diff --git a/man7/ip.7 b/man7/ip.7
>> >> > index 9f560df..84fe32d 100644
>> >> > --- a/man7/ip.7
>> >> > +++ b/man7/ip.7
>> >> > @@ -69,12 +69,11 @@ For
>> >> > you may specify a valid IANA IP protocol defined in
>> >> > RFC\ 1700 assigned numbers.
>> >> > .PP
>> >> > -.\" FIXME ip current does an autobind in listen, but I'm not sure
>> >> > -.\" if that should be documented.
>> >> > When a process wants to receive new incoming packets or connections, it
>> >> > should bind a socket to a local interface address using
>> >> > .BR bind (2).
>> >> > -Only one IP socket may be bound to any given local (address, port) pair.
>> >> > +In this case, only one IP socket may be bound to any given local
>> >> > +(address, port) pair.
>> >> > When
>> >> > .B INADDR_ANY
>> >> > is specified in the bind call, the socket will be bound to
>> >> > @@ -82,10 +81,14 @@ is specified in the bind call, the socket will be bound to
>> >> > local interfaces.
>> >> > When
>> >> > .BR listen (2)
>> >> > -or
>> >> > +is called on an unbound socket, the socket is automatically bound
>> >> > +to a random free port with the local address set to
>> >> > +.BR INADDR_ANY .
>> >> > +When
>> >> > .BR connect (2)
>> >> > -are called on an unbound socket, it is automatically bound to a
>> >> > -random free port with the local address set to
>> >> > +is called on an unbound socket, the socket is automatically bound
>> >> > +to a random free port or an usable shared port with the local address
>> >> > +set to
>> >> > .BR INADDR_ANY .
>> >> >
>> >> > A TCP local socket address that has been bound is unavailable for
>> >
>>
>>
>>
>> --
>> Michael Kerrisk
>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>> Author of "The Linux Programming Interface"; http://man7.org/tlpi/
>>
>
> --
> fbl
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] ixgbe: Only set gso_type to SKB_GSO_TCPV4 as RSC does not support IPv6
From: Alexander Duyck @ 2013-02-12 21:39 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, jeffrey.t.kirsher, davem
In-Reply-To: <20130212205151.GC6972@redhat.com>
On 02/12/2013 12:51 PM, Michael S. Tsirkin wrote:
> On Tue, Feb 12, 2013 at 11:45:44AM -0800, Alexander Duyck wrote:
>> The original fix that was applied for setting gso_type required more change
>> than necessary because it was assumed ixgbe does RSC on IPv6 frames and this
>> is not correct. RSC is only supported with IPv4/TCP frames only. As such we
>> can simplify the fix and avoid the unnecessary move of eth_type_trans.
>>
>> The previous patch "ixgbe: fix gso type" and this patch reduce the entire fix
>> to one line that sets gso_type to TCPV4 if the frame is RSC.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Is this architectural? Is it safe to assume there won't be an update
> that does RSC on IPv6?
If there is an update at some point in the future we could address it
then. I just wanted to keep changes to net minimal to avoid a possible
regression, and this patch does that. No point in future proofing it
for features we may or may not implement at some point in the future.
If we were to add IPv6 support to RSC it would be a serious rewrite of
the feature anyway. This code would hopefully be refactored as a part
of that rewrite since we would want the hardware to give us the MSS
instead of making us have to approximate it.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH v3] net: fec_mpc52xx: Read MAC address from device-tree
From: David Miller @ 2013-02-12 21:16 UTC (permalink / raw)
To: sr; +Cc: netdev, linuxppc-dev, agust
In-Reply-To: <1360674338-12776-1-git-send-email-sr@denx.de>
From: Stefan Roese <sr@denx.de>
Date: Tue, 12 Feb 2013 14:05:38 +0100
> v3:
> - Use of_get_mac_address() instead of of_get_property()
Just to clarify, I applied this version (v3), not v2 (which I
just replied to with "applied").
^ permalink raw reply
* Re: [PATCH net-next] cxgb4vf: Fix VLAN extraction counter increment
From: David Miller @ 2013-02-12 21:15 UTC (permalink / raw)
To: vipul; +Cc: netdev, divy, dm, leedom, abhishek, santosh
In-Reply-To: <1360665381-17033-1-git-send-email-vipul@chelsio.com>
From: Vipul Pandya <vipul@chelsio.com>
Date: Tue, 12 Feb 2013 16:06:21 +0530
> Signed-off-by: Santosh Rastapur <santosh@chelsio.com>
> Signed-off-by: Vipul Pandya <vipul@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/3] Dual EMAC mode implementation of CPSW
From: David Miller @ 2013-02-12 21:15 UTC (permalink / raw)
To: mugunthanvnm; +Cc: netdev, linux-arm-kernel, linux-omap
In-Reply-To: <1360612340-9266-1-git-send-email-mugunthanvnm@ti.com>
From: Mugunthan V N <mugunthanvnm@ti.com>
Date: Tue, 12 Feb 2013 01:22:17 +0530
> This patch series implements Dual EMAC mode implementation of CPSW
> which acts as two standalone EMAC by segregating the switch using VIDs
> and port VLAN
>
> Mugunthan V N (3):
> driver: net: ethernet: davinci_cpdma: add support for directed packet
> and source port detection
> driver: net: ethernet: cpsw: make cpts as pointer
> driver: net: ethernet: cpsw: dual emac interface implementation
Series applied.
^ permalink raw reply
* Re: [PATCH v2] net: fec_mpc52xx: Read MAC address from device-tree
From: David Miller @ 2013-02-12 21:15 UTC (permalink / raw)
To: sr; +Cc: netdev, linuxppc-dev, agust
In-Reply-To: <1360660088-27464-1-git-send-email-sr@denx.de>
From: Stefan Roese <sr@denx.de>
Date: Tue, 12 Feb 2013 10:08:08 +0100
> Until now, the MPC5200 FEC ethernet driver relied upon the bootloader
> (U-Boot) to write the MAC address into the ethernet controller
> registers. The Linux driver should not rely on such a thing. So
> lets read the MAC address from the DT as it should be done here.
>
> The following priority is now used to read the MAC address:
>
> 1) First, try OF node MAC address, if not present or invalid, then:
>
> 2) Read from MAC address registers, if invalid, then:
>
> 3) Log a warning message, and choose a random MAC address.
>
> This fixes a problem with a MPC5200 board that uses the SPL U-Boot
> version without FEC initialization before Linux booting for
> boot speedup.
>
> Additionally a status line is now be printed upon successful
> driver probing, also displaying this MAC address.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
Applied.
^ permalink raw reply
* Re: pull request: wireless 2013-02-12
From: David Miller @ 2013-02-12 21:13 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20130212160316.GA2086@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 12 Feb 2013 11:03:16 -0500
> Here is another handful of late-breaking fixes intended for the 3.8
> stream... Hopefully the will still make it! :-)
>
> There are three mac80211 fixes pulled from Johannes:
>
> "Here are three fixes still for the 3.8 stream, the fix from Cong Ding
> for the bad sizeof (Stephen Hemminger had pointed it out before but I'd
> promptly forgotten), a mac80211 managed-mode channel context usage fix
> where a downgrade would never stop until reaching non-HT and a bug in
> the channel determination that could cause invalid channels like HT40+
> on channel 11 to be used."
>
> Also included is a mwl8k fix that avoids an oops when using mwl8k
> devices that only support the 5 GHz band.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: bridge interface initial carrier state
From: David Miller @ 2013-02-12 21:10 UTC (permalink / raw)
To: jiri; +Cc: stephen, dcbw, netdev
In-Reply-To: <20130212210605.GA28929@minipsycho.orion>
From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 12 Feb 2013 22:06:05 +0100
> Mon, Feb 11, 2013 at 10:58:36PM CET, stephen@networkplumber.org wrote:
>>On Mon, 11 Feb 2013 14:01:55 -0600
>>Dan Williams <dcbw@redhat.com> wrote:
>>
>>> Hi,
>>>
>>> I'm wondering if the initial carrier state of 'on' is intentional for a
>>> bridge without ports; immediately after adding ports, the carrier is
>>> recalculated and depends on the combined state of each port's carrier
>>> and STP forwarding state. So a userspace program attempting to decide
>>> whether the bridge was usable or not has to look at both (a) how many
>>> ports are available and (b) bridge carrier state, instead of just
>>> looking at the bridge carrier state.
>>>
>>> Dan
>>
>>It really should be off when no ports are present, but some initial startup
>>scripts broke when it was that way.
>
> How so? Can you give me an example of that script?
> I think that any script should be able to handle a situation when carrier
> of some device is down...
These are scripts that are looking for interfaces that are "active".
The definition of this for layered and software devices is very
ambiguous, therefore the only sane thing to do is to default to
having the carrier on by default.
^ permalink raw reply
* Re: [PATCH net] ixgbe: Only set gso_type to SKB_GSO_TCPV4 as RSC does not support IPv6
From: David Miller @ 2013-02-12 21:07 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev, jeffrey.t.kirsher, mst
In-Reply-To: <20130212193624.17818.13843.stgit@ahduyck-cp1.jf.intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Tue, 12 Feb 2013 11:45:44 -0800
> The original fix that was applied for setting gso_type required more change
> than necessary because it was assumed ixgbe does RSC on IPv6 frames and this
> is not correct. RSC is only supported with IPv4/TCP frames only. As such we
> can simplify the fix and avoid the unnecessary move of eth_type_trans.
>
> The previous patch "ixgbe: fix gso type" and this patch reduce the entire fix
> to one line that sets gso_type to TCPV4 if the frame is RSC.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: fix infinite loop in __skb_recv_datagram()
From: David Miller @ 2013-02-12 21:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: tt.rantala, netdev, davej, xemul
In-Reply-To: <1360685813.13993.12.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 12 Feb 2013 08:16:53 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Tommi was fuzzing with trinity and reported the following problem :
>
> commit 3f518bf745 (datagram: Add offset argument to __skb_recv_datagram)
> missed that a raw socket receive queue can contain skbs with no payload.
>
> We can loop in __skb_recv_datagram() with MSG_PEEK mode, because
> wait_for_packet() is not prepared to skip these skbs.
...
> Reported-by: Tommi Rantala <tt.rantala@gmail.com>
> Tested-by: Tommi Rantala <tt.rantala@gmail.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
^ 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