* [PATCH 3/3] IPv6: Generic TTL Security Mechanism (unified version)
From: Stephen Hemminger @ 2010-04-03 23:21 UTC (permalink / raw)
To: davem, Pekka Savola, YOSHIFUJI Hideaki, Nick Hilliard; +Cc: netdev
In-Reply-To: <20100403232103.923025940@vyatta.com>
[-- Attachment #1: gtsm-ipv6.diff --]
[-- Type: text/plain, Size: 3126 bytes --]
This patch is one alternative IPv6 support for RFC5082 Generalized TTL
Security Mechanism.
This version takes a simplest (but least pure) approach.
It uses the same socket option for IPv6 as IPv4 because
the TCP code has to deal with mapped addresses already.
With this method, the server doesn't have to deal with both IPv4 and IPv6
socket options. But the client still does have to handle the different
options.
On client:
int ttl = 255;
getaddrinfo(argv[1], argv[2], &hint, &result);
for (rp = result; rp != NULL; rp = rp->ai_next) {
s = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
if (s < 0) continue;
if (rp->ai_family == AF_INET) {
setsockopt(s, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl));
} else if (rp->ai_family == AF_INET6) {
setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
&ttl, sizeof(ttl)))
}
if (connect(s, rp->ai_addr, rp->ai_addrlen) == 0) {
...
On server:
unsigned char minttl = 255 - maxhops;
getaddrinfo(NULL, port, &hints, &result);
for (rp = result; rp != NULL; rp = rp->ai_next) {
s = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
if (s < 0) continue;
setsockopt(s, IPPROTO_IP, IP_MINTTL, &minttl, sizeof(minttl));
if (bind(s, rp->ai_addr, rp->ai_addrlen) == 0)
break
..
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
net/ipv4/tcp_ipv4.c | 15 +++++++++++----
net/ipv6/tcp_ipv6.c | 10 ++++++++++
2 files changed, 21 insertions(+), 4 deletions(-)
--- a/net/ipv6/tcp_ipv6.c 2010-04-02 21:19:39.692013672 -0700
+++ b/net/ipv6/tcp_ipv6.c 2010-04-03 15:55:43.778224848 -0700
@@ -349,6 +349,11 @@ static void tcp_v6_err(struct sk_buff *s
if (sk->sk_state == TCP_CLOSE)
goto out;
+ if (ipv6_hdr(skb)->hop_limit < inet_sk(sk)->min_ttl) {
+ NET_INC_STATS_BH(net, LINUX_MIB_TCPMINTTLDROP);
+ goto out;
+ }
+
tp = tcp_sk(sk);
seq = ntohl(th->seq);
if (sk->sk_state != TCP_LISTEN &&
@@ -1717,6 +1722,11 @@ process:
if (sk->sk_state == TCP_TIME_WAIT)
goto do_time_wait;
+ if (ipv6_hdr(skb)->hop_limit < inet_sk(sk)->min_ttl) {
+ NET_INC_STATS_BH(net, LINUX_MIB_TCPMINTTLDROP);
+ goto discard_and_relse;
+ }
+
if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb))
goto discard_and_relse;
--- a/net/ipv4/tcp_ipv4.c 2010-04-02 21:19:39.682014278 -0700
+++ b/net/ipv4/tcp_ipv4.c 2010-04-02 21:20:25.571077252 -0700
@@ -1660,10 +1660,14 @@ process:
if (sk->sk_state == TCP_TIME_WAIT)
goto do_time_wait;
- if (unlikely(iph->ttl < inet_sk(sk)->min_ttl)) {
- NET_INC_STATS_BH(net, LINUX_MIB_TCPMINTTLDROP);
- goto discard_and_relse;
- }
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+ if (skb->protocol == htons(ETH_P_IPV6)) {
+ if (ipv6_hdr(skb)->hop_limit < inet_sk(sk)->min_ttl)
+ goto min_ttl_discard;
+ } else
+#endif
+ if (iph->ttl < inet_sk(sk)->min_ttl)
+ goto min_ttl_discard;
if (!xfrm4_policy_check(sk, XFRM_POLICY_IN, skb))
goto discard_and_relse;
@@ -1716,6 +1720,9 @@ discard_it:
kfree_skb(skb);
return 0;
+min_ttl_discard:
+ NET_INC_STATS_BH(net, LINUX_MIB_TCPMINTTLDROP);
+
discard_and_relse:
sock_put(sk);
goto discard_it;
--
^ permalink raw reply
* [PATCH 2/3] IPv6: Generic TTL Security Mechanism (alternate version)
From: Stephen Hemminger @ 2010-04-03 23:21 UTC (permalink / raw)
To: davem, Pekka Savola, YOSHIFUJI Hideaki, Nick Hilliard; +Cc: netdev
In-Reply-To: <20100403232103.923025940@vyatta.com>
[-- Attachment #1: gtsm-ipv6-ipv4-1a.diff --]
[-- Type: text/plain, Size: 4615 bytes --]
This patch adds IPv6 support for RFC5082 Generalized TTL
Security Mechanism.
Very similar to original proposed code; the IPV6 and IPV4
socket options are seperate, but the setting the IPV6 min hopcount
also sets IPV4 min ttl. This makes for less possible errors by the
programmer when using IPV4 mapped addresses.
With this method, the server does have to deal with both IPv4 and IPv6
socket options and the client has to handle the different for each
family.
On client:
int ttl = 255;
getaddrinfo(argv[1], argv[2], &hint, &result);
for (rp = result; rp != NULL; rp = rp->ai_next) {
s = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
if (s < 0) continue;
if (rp->ai_family == AF_INET) {
setsockopt(s, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl));
} else if (rp->ai_family == AF_INET6) {
setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
&ttl, sizeof(ttl)))
}
if (connect(s, rp->ai_addr, rp->ai_addrlen) == 0) {
...
On server:
int minttl = 255 - maxhops;
getaddrinfo(NULL, port, &hints, &result);
for (rp = result; rp != NULL; rp = rp->ai_next) {
s = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
if (s < 0) continue;
if (rp->ai_family == AF_INET6)
setsockopt(s, IPPROTO_IPV6, IPV6_MINHOPCOUNT,
&minttl, sizeof(minttl));
else
setsockopt(s, IPPROTO_IP, IP_MINTTL,
&minttl, sizeof(minttl));
if (bind(s, rp->ai_addr, rp->ai_addrlen) == 0)
break
..
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
include/linux/in6.h | 3 +++
include/linux/ipv6.h | 1 +
net/ipv6/ipv6_sockglue.c | 13 +++++++++++++
net/ipv6/tcp_ipv6.c | 14 +++++++++++++-
4 files changed, 30 insertions(+), 1 deletion(-)
--- a/net/ipv6/tcp_ipv6.c 2010-04-03 16:13:50.450038495 -0700
+++ b/net/ipv6/tcp_ipv6.c 2010-04-03 16:14:58.579101059 -0700
@@ -349,6 +349,11 @@ static void tcp_v6_err(struct sk_buff *s
if (sk->sk_state == TCP_CLOSE)
goto out;
+ if (ipv6_hdr(skb)->hop_limit < inet6_sk(sk)->min_hopcount) {
+ NET_INC_STATS_BH(net, LINUX_MIB_TCPMINTTLDROP);
+ goto out;
+ }
+
tp = tcp_sk(sk);
seq = ntohl(th->seq);
if (sk->sk_state != TCP_LISTEN &&
@@ -1675,6 +1680,7 @@ ipv6_pktoptions:
static int tcp_v6_rcv(struct sk_buff *skb)
{
struct tcphdr *th;
+ struct ipv6hdr *hdr;
struct sock *sk;
int ret;
struct net *net = dev_net(skb->dev);
@@ -1701,12 +1707,13 @@ static int tcp_v6_rcv(struct sk_buff *sk
goto bad_packet;
th = tcp_hdr(skb);
+ hdr = ipv6_hdr(skb);
TCP_SKB_CB(skb)->seq = ntohl(th->seq);
TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th->syn + th->fin +
skb->len - th->doff*4);
TCP_SKB_CB(skb)->ack_seq = ntohl(th->ack_seq);
TCP_SKB_CB(skb)->when = 0;
- TCP_SKB_CB(skb)->flags = ipv6_get_dsfield(ipv6_hdr(skb));
+ TCP_SKB_CB(skb)->flags = ipv6_get_dsfield(hdr);
TCP_SKB_CB(skb)->sacked = 0;
sk = __inet6_lookup_skb(&tcp_hashinfo, skb, th->source, th->dest);
@@ -1717,6 +1724,11 @@ process:
if (sk->sk_state == TCP_TIME_WAIT)
goto do_time_wait;
+ if (hdr->hop_limit < inet6_sk(sk)->min_hopcount) {
+ NET_INC_STATS_BH(net, LINUX_MIB_TCPMINTTLDROP);
+ goto discard_and_relse;
+ }
+
if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb))
goto discard_and_relse;
--- a/include/linux/in6.h 2010-04-03 16:13:50.460038505 -0700
+++ b/include/linux/in6.h 2010-04-03 16:14:58.579101059 -0700
@@ -265,6 +265,9 @@ struct in6_flowlabel_req {
#define IPV6_PREFER_SRC_CGA 0x0008
#define IPV6_PREFER_SRC_NONCGA 0x0800
+/* RFC5082: Generalized Ttl Security Mechanism */
+#define IPV6_MINHOPCOUNT 73
+
/*
* Multicast Routing:
* see include/linux/mroute6.h.
--- a/include/linux/ipv6.h 2010-04-03 16:13:50.470038394 -0700
+++ b/include/linux/ipv6.h 2010-04-03 16:14:58.579101059 -0700
@@ -348,6 +348,7 @@ struct ipv6_pinfo {
* 010: prefer public address
* 100: prefer care-of address
*/
+ __u8 min_hopcount;
__u8 tclass;
__u32 dst_cookie;
--- a/net/ipv6/ipv6_sockglue.c 2010-04-03 16:13:50.440037810 -0700
+++ b/net/ipv6/ipv6_sockglue.c 2010-04-03 16:16:45.973137844 -0700
@@ -766,6 +766,15 @@ pref_skip_coa:
break;
}
+ case IPV6_MINHOPCOUNT:
+ if (optlen < sizeof(int))
+ goto e_inval;
+ if (val < 0 || val > 255)
+ goto e_inval;
+ np->min_hopcount = val;
+ inet_sk(sk)->min_ttl = val;
+ retv = 0;
+ break;
}
release_sock(sk);
@@ -1114,6 +1123,10 @@ static int do_ipv6_getsockopt(struct soc
val |= IPV6_PREFER_SRC_HOME;
break;
+ case IPV6_MINHOPCOUNT:
+ val = np->min_hopcount;
+ break;
+
default:
return -ENOPROTOOPT;
}
--
^ permalink raw reply
* [PATCH 1/3] IPv6: Generic TTL Security Mechanism (original version)
From: Stephen Hemminger @ 2010-04-03 23:21 UTC (permalink / raw)
To: davem, Pekka Savola, YOSHIFUJI Hideaki, Nick Hilliard; +Cc: netdev
In-Reply-To: <20100403232103.923025940@vyatta.com>
[-- Attachment #1: gtsm-ipv6-ipv4-1.diff --]
[-- Type: text/plain, Size: 4384 bytes --]
This patch adds IPv6 support for RFC5082 Generalized TTL
Security Mechanism.
The original proposed code; the IPV6 and IPV4 socket options are seperate.
With this method, the server does have to deal with both IPv4 and IPv6
socket options and the client has to handle the different for each
family.
On client:
int ttl = 255;
getaddrinfo(argv[1], argv[2], &hint, &result);
for (rp = result; rp != NULL; rp = rp->ai_next) {
s = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
if (s < 0) continue;
if (rp->ai_family == AF_INET) {
setsockopt(s, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl));
} else if (rp->ai_family == AF_INET6) {
setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
&ttl, sizeof(ttl)))
}
if (connect(s, rp->ai_addr, rp->ai_addrlen) == 0) {
...
On server:
int minttl = 255 - maxhops;
getaddrinfo(NULL, port, &hints, &result);
for (rp = result; rp != NULL; rp = rp->ai_next) {
s = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
if (s < 0) continue;
if (rp->ai_family == AF_INET6)
setsockopt(s, IPPROTO_IPV6, IPV6_MINHOPCOUNT,
&minttl, sizeof(minttl));
setsockopt(s, IPPROTO_IP, IP_MINTTL, &minttl, sizeof(minttl));
if (bind(s, rp->ai_addr, rp->ai_addrlen) == 0)
break
..
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
include/linux/in6.h | 3 +++
include/linux/ipv6.h | 1 +
net/ipv6/ipv6_sockglue.c | 12 ++++++++++++
net/ipv6/tcp_ipv6.c | 14 +++++++++++++-
4 files changed, 29 insertions(+), 1 deletion(-)
--- a/net/ipv6/tcp_ipv6.c 2010-04-03 16:04:01.159412921 -0700
+++ b/net/ipv6/tcp_ipv6.c 2010-04-03 16:05:15.749413056 -0700
@@ -349,6 +349,11 @@ static void tcp_v6_err(struct sk_buff *s
if (sk->sk_state == TCP_CLOSE)
goto out;
+ if (ipv6_hdr(skb)->hop_limit < inet6_sk(sk)->min_hopcount) {
+ NET_INC_STATS_BH(net, LINUX_MIB_TCPMINTTLDROP);
+ goto out;
+ }
+
tp = tcp_sk(sk);
seq = ntohl(th->seq);
if (sk->sk_state != TCP_LISTEN &&
@@ -1675,6 +1680,7 @@ ipv6_pktoptions:
static int tcp_v6_rcv(struct sk_buff *skb)
{
struct tcphdr *th;
+ struct ipv6hdr *hdr;
struct sock *sk;
int ret;
struct net *net = dev_net(skb->dev);
@@ -1701,12 +1707,13 @@ static int tcp_v6_rcv(struct sk_buff *sk
goto bad_packet;
th = tcp_hdr(skb);
+ hdr = ipv6_hdr(skb);
TCP_SKB_CB(skb)->seq = ntohl(th->seq);
TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th->syn + th->fin +
skb->len - th->doff*4);
TCP_SKB_CB(skb)->ack_seq = ntohl(th->ack_seq);
TCP_SKB_CB(skb)->when = 0;
- TCP_SKB_CB(skb)->flags = ipv6_get_dsfield(ipv6_hdr(skb));
+ TCP_SKB_CB(skb)->flags = ipv6_get_dsfield(hdr);
TCP_SKB_CB(skb)->sacked = 0;
sk = __inet6_lookup_skb(&tcp_hashinfo, skb, th->source, th->dest);
@@ -1717,6 +1724,11 @@ process:
if (sk->sk_state == TCP_TIME_WAIT)
goto do_time_wait;
+ if (hdr->hop_limit < inet6_sk(sk)->min_hopcount) {
+ NET_INC_STATS_BH(net, LINUX_MIB_TCPMINTTLDROP);
+ goto discard_and_relse;
+ }
+
if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb))
goto discard_and_relse;
--- a/include/linux/in6.h 2010-04-02 21:16:07.461701802 -0700
+++ b/include/linux/in6.h 2010-04-03 16:05:15.749413056 -0700
@@ -265,6 +265,9 @@ struct in6_flowlabel_req {
#define IPV6_PREFER_SRC_CGA 0x0008
#define IPV6_PREFER_SRC_NONCGA 0x0800
+/* RFC5082: Generalized Ttl Security Mechanism */
+#define IPV6_MINHOPCOUNT 73
+
/*
* Multicast Routing:
* see include/linux/mroute6.h.
--- a/include/linux/ipv6.h 2010-04-02 21:16:04.122638936 -0700
+++ b/include/linux/ipv6.h 2010-04-03 16:05:15.769412669 -0700
@@ -348,6 +348,7 @@ struct ipv6_pinfo {
* 010: prefer public address
* 100: prefer care-of address
*/
+ __u8 min_hopcount;
__u8 tclass;
__u32 dst_cookie;
--- a/net/ipv6/ipv6_sockglue.c 2010-04-02 21:15:26.071389733 -0700
+++ b/net/ipv6/ipv6_sockglue.c 2010-04-03 16:05:15.789412706 -0700
@@ -766,6 +766,14 @@ pref_skip_coa:
break;
}
+ case IPV6_MINHOPCOUNT:
+ if (optlen < sizeof(int))
+ goto e_inval;
+ if (val < 0 || val > 255)
+ goto e_inval;
+ np->min_hopcount = val;
+ retv = 0;
+ break;
}
release_sock(sk);
@@ -1114,6 +1122,10 @@ static int do_ipv6_getsockopt(struct soc
val |= IPV6_PREFER_SRC_HOME;
break;
+ case IPV6_MINHOPCOUNT:
+ val = np->min_hopcount;
+ break;
+
default:
return -ENOPROTOOPT;
}
--
^ permalink raw reply
* [PATCH 0/3] GTSM support for IPv6 three alternatives
From: Stephen Hemminger @ 2010-04-03 23:21 UTC (permalink / raw)
To: davem, Pekka Savola, YOSHIFUJI Hideaki, Nick Hilliard; +Cc: netdev
I have tested three alternative versions of this patch and can't
reach a diffinitive conclusion. I favor the unified version (simplest API),
but need more opinions. It would not be good if Linux implements
one option and BSD choose the other! That is why the original
BSD developer and the quagga patch author are receiving this.
In case it is not obvious, only one of these choices should be
applied!
--
^ permalink raw reply
* Re: [PATCH net-next-2.6] icmp: Account for ICMP out errors
From: David Miller @ 2010-04-03 22:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: afleming, netdev
In-Reply-To: <1270192174.1936.33.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 02 Apr 2010 09:09:34 +0200
> [PATCH net-next-2.6] icmp: Account for ICMP out errors
>
> When ip_append() fails because of socket limit or memory shortage,
> increment ICMP_MIB_OUTERRORS counter, so that "netstat -s" can report
> these errors.
>
> LANG=C netstat -s | grep "ICMP messages failed"
> 0 ICMP messages failed
>
> For IPV6, implement ICMP6_MIB_OUTERRORS counter as well.
>
> # grep Icmp6OutErrors /proc/net/dev_snmp6/*
> /proc/net/dev_snmp6/eth0:Icmp6OutErrors 0
> /proc/net/dev_snmp6/lo:Icmp6OutErrors 0
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH kernel 2.6.34-rc3] smc91c92_cs: fix the problem of "Unable to find hardware address"
From: David Miller @ 2010-04-03 22:07 UTC (permalink / raw)
To: ken_kawasaki; +Cc: netdev
In-Reply-To: <20100404061434.eb98ef3e.ken_kawasaki@spring.nifty.jp>
From: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Date: Sun, 4 Apr 2010 06:14:34 +0900
>
> smc91c92_cs:
> *cvt_ascii_address returns 0, if success.
> *call free_netdev, if we can't find hardware address.
>
> Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Applied, thanks.
^ permalink raw reply
* [PATCH 2/2] l2tp: Fix L2TP_DEBUGFS ifdef tests.
From: David Miller @ 2010-04-03 22:04 UTC (permalink / raw)
To: jchapman; +Cc: netdev
We have to check CONFIG_L2TP_DEBUGFS_MODULE as well as
CONFIG_L2TP_DEBUGFS.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/l2tp/l2tp_core.h | 2 +-
net/l2tp/l2tp_eth.c | 4 ++--
net/l2tp/l2tp_ppp.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/l2tp/l2tp_core.h b/net/l2tp/l2tp_core.h
index a961c77..91b1b9c 100644
--- a/net/l2tp/l2tp_core.h
+++ b/net/l2tp/l2tp_core.h
@@ -133,7 +133,7 @@ struct l2tp_session {
void (*session_close)(struct l2tp_session *session);
void (*ref)(struct l2tp_session *session);
void (*deref)(struct l2tp_session *session);
-#ifdef CONFIG_L2TP_DEBUGFS
+#if defined(CONFIG_L2TP_DEBUGFS) || defined(CONFIG_L2TP_DEBUGFS_MODULE)
void (*show)(struct seq_file *m, void *priv);
#endif
uint8_t priv[0]; /* private data */
diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 9848faa..ca1164a 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -172,7 +172,7 @@ static void l2tp_eth_delete(struct l2tp_session *session)
}
}
-#ifdef CONFIG_L2TP_DEBUGFS
+#if defined(CONFIG_L2TP_DEBUGFS) || defined(CONFIG_L2TP_DEBUGFS_MODULE)
static void l2tp_eth_show(struct seq_file *m, void *arg)
{
struct l2tp_session *session = arg;
@@ -244,7 +244,7 @@ static int l2tp_eth_create(struct net *net, u32 tunnel_id, u32 session_id, u32 p
priv->tunnel_sock = tunnel->sock;
session->recv_skb = l2tp_eth_dev_recv;
session->session_close = l2tp_eth_delete;
-#ifdef CONFIG_L2TP_DEBUGFS
+#if defined(CONFIG_L2TP_DEBUGFS) || defined(CONFIG_L2TP_DEBUGFS_MODULE)
session->show = l2tp_eth_show;
#endif
diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
index 1ef10e4..90d82b3 100644
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -597,7 +597,7 @@ out:
return error;
}
-#ifdef CONFIG_L2TP_DEBUGFS
+#if defined(CONFIG_L2TP_DEBUGFS) || defined(CONFIG_L2TP_DEBUGFS_MODULE)
static void pppol2tp_show(struct seq_file *m, void *arg)
{
struct l2tp_session *session = arg;
@@ -748,7 +748,7 @@ static int pppol2tp_connect(struct socket *sock, struct sockaddr *uservaddr,
session->recv_skb = pppol2tp_recv;
session->session_close = pppol2tp_session_close;
-#ifdef CONFIG_L2TP_DEBUGFS
+#if defined(CONFIG_L2TP_DEBUGFS) || defined(CONFIG_L2TP_DEBUGFS_MODULE)
session->show = pppol2tp_show;
#endif
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] l2tp: Add missing semicolon to MODULE_ALIAS() in l2tp_netlink.c
From: David Miller @ 2010-04-03 22:04 UTC (permalink / raw)
To: jchapman; +Cc: netdev
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/l2tp/l2tp_netlink.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/l2tp/l2tp_netlink.c b/net/l2tp/l2tp_netlink.c
index 12341a6..4c1e540 100644
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -837,4 +837,4 @@ MODULE_DESCRIPTION("L2TP netlink");
MODULE_LICENSE("GPL");
MODULE_VERSION("1.0");
MODULE_ALIAS("net-pf-" __stringify(PF_NETLINK) "-proto-" \
- __stringify(NETLINK_GENERIC) "-type-" "l2tp")
+ __stringify(NETLINK_GENERIC) "-type-" "l2tp");
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH net-next-2.6 v4 00/14] l2tp: Introduce L2TPv3 support
From: David Miller @ 2010-04-03 22:04 UTC (permalink / raw)
To: jchapman; +Cc: netdev
In-Reply-To: <20100403.142522.01040744.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sat, 03 Apr 2010 14:25:22 -0700 (PDT)
> From: James Chapman <jchapman@katalix.com>
> Date: Fri, 02 Apr 2010 17:18:23 +0100
>
>> This patch series adds L2TPv3 support. It splits the existing pppol2tp
>> driver to separate its L2TP and PPP parts, then adds new L2TPv3
>> functionality. The patches implement a new socket family for L2TPv3 IP
>> encapsulation, expose virtual netdevices for each L2TPv3 ethernet
>> pseudowire and add a netlink interface.
>
> Ok I'm going to toss this into net-next-2.6, we have time to
> fixup any remaining issues people might discover.
This needed several build fixes which I'll post next.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v4 00/14] l2tp: Introduce L2TPv3 support
From: David Miller @ 2010-04-03 21:25 UTC (permalink / raw)
To: jchapman; +Cc: netdev
In-Reply-To: <20100402161822.11367.70454.stgit@bert.katalix.com>
From: James Chapman <jchapman@katalix.com>
Date: Fri, 02 Apr 2010 17:18:23 +0100
> This patch series adds L2TPv3 support. It splits the existing pppol2tp
> driver to separate its L2TP and PPP parts, then adds new L2TPv3
> functionality. The patches implement a new socket family for L2TPv3 IP
> encapsulation, expose virtual netdevices for each L2TPv3 ethernet
> pseudowire and add a netlink interface.
Ok I'm going to toss this into net-next-2.6, we have time to
fixup any remaining issues people might discover.
Thanks James.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/2] net: finalize multicast list conversion
From: David Miller @ 2010-04-03 21:23 UTC (permalink / raw)
To: jpirko; +Cc: netdev
In-Reply-To: <20100402072126.GA3100@psychotron.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Fri, 2 Apr 2010 09:21:27 +0200
> This patchset finalizes the conversion of multicast list to list_head. It also
> moves the code manipulating all address lists to it's own file.
Both applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCHv1 0/9]qlcnic: fix diagnostic tools access
From: David Miller @ 2010-04-03 21:19 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman
In-Reply-To: <1270184496-18985-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Thu, 1 Apr 2010 22:01:27 -0700
> David,
> Series of 9 patches to fix diagnostic tools access and fixing
> ethtool msg level as per your comments.
> This is v1 series and this also include endianness fix.
> Please apply them on net-next branch.
Applied, thank you.
^ permalink raw reply
* [PATCH kernel 2.6.34-rc3] smc91c92_cs: fix the problem of "Unable to find hardware address"
From: Ken Kawasaki @ 2010-04-03 21:14 UTC (permalink / raw)
To: netdev; +Cc: ken_kawasaki
In-Reply-To: <20100328055537.13ef6c01.ken_kawasaki@spring.nifty.jp>
smc91c92_cs:
*cvt_ascii_address returns 0, if success.
*call free_netdev, if we can't find hardware address.
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
---
--- linux-2.6.34-rc3/drivers/net/pcmcia/smc91c92_cs.c.orig 2010-04-03 09:41:20.000000000 +0900
+++ linux-2.6.34-rc3/drivers/net/pcmcia/smc91c92_cs.c 2010-04-03 20:34:06.000000000 +0900
@@ -493,13 +493,14 @@ static int pcmcia_get_versmac(struct pcm
{
struct net_device *dev = priv;
cisparse_t parse;
+ u8 *buf;
if (pcmcia_parse_tuple(tuple, &parse))
return -EINVAL;
- if ((parse.version_1.ns > 3) &&
- (cvt_ascii_address(dev,
- (parse.version_1.str + parse.version_1.ofs[3]))))
+ buf = parse.version_1.str + parse.version_1.ofs[3];
+
+ if ((parse.version_1.ns > 3) && (cvt_ascii_address(dev, buf) == 0))
return 0;
return -EINVAL;
@@ -528,7 +529,7 @@ static int mhz_setup(struct pcmcia_devic
len = pcmcia_get_tuple(link, 0x81, &buf);
if (buf && len >= 13) {
buf[12] = '\0';
- if (cvt_ascii_address(dev, buf))
+ if (cvt_ascii_address(dev, buf) == 0)
rc = 0;
}
kfree(buf);
@@ -910,7 +911,7 @@ static int smc91c92_config(struct pcmcia
if (i != 0) {
printk(KERN_NOTICE "smc91c92_cs: Unable to find hardware address.\n");
- goto config_undo;
+ goto config_failed;
}
smc->duplex = 0;
@@ -998,6 +999,7 @@ config_undo:
unregister_netdev(dev);
config_failed:
smc91c92_release(link);
+ free_netdev(dev);
return -ENODEV;
} /* smc91c92_config */
^ permalink raw reply
* Re: [PATCH 1/4] flow: virtualize flow cache entry methods
From: Timo Teräs @ 2010-04-03 20:19 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100403155353.GA5618@gondor.apana.org.au>
Herbert Xu wrote:
> On Sat, Apr 03, 2010 at 05:26:00PM +0300, Timo Teräs wrote:
>> Why would this block? The device down hook calls flow cache
>> flush. On flush all bundles with non-up devices get pruned
>> immediately (via stale_bundle check).
>
> Perhaps I missed something in your patch, but the flush that
> we currently perform is limited to the bundles from hashed policies.
> So if a policy has just recently been removed, then its bundles
> won't be flushed.
If a policy is removed, policy->genid is incremented invalidating
the bundles. Those bundles get freed when:
- specific flow gets hit
- cache is flushed due to GC call, or interface going down
- flow cache randomization
If someone is then removing a net driver, we still execute
flush on the 'device down' hook, and all stale bundles
get flushed.
But yes, this means that xfrm_policy struct can now be held
allocated up to ten extra minutes. But it's only memory that
it's holding, not any extra refs. And it's still reclaimable
by the GC.
If this feels troublesome, we could add asynchronous flush
request that would be called on policy removal. Or even stick
to the synchronous one.
^ permalink raw reply
* Re: [PATCH 0/6] tagged sysfs support
From: Kay Sievers @ 2010-04-03 16:35 UTC (permalink / raw)
To: Ben Hutchings
Cc: Eric W. Biederman, Greg Kroah-Hartman, Greg KH, linux-kernel,
Tejun Heo, Cornelia Huck, linux-fsdevel, Eric Dumazet,
Benjamin LaHaise, Serge Hallyn, netdev
In-Reply-To: <1270310756.12516.308.camel@localhost>
On Sat, Apr 3, 2010 at 18:05, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Sat, 2010-04-03 at 10:35 +0200, Kay Sievers wrote:
>> On Sat, Apr 3, 2010 at 02:58, Ben Hutchings <ben@decadent.org.uk> wrote:
>> > On Wed, 2010-03-31 at 07:51 +0200, Kay Sievers wrote:
>> >> Yeah, /sys/bus/, which is the only sane layout of the needlessly
>> >> different 3 versions of the same thing (bus, class, block).
>> > [...]
>> >
>> > block vs class/block is arguable,
>>
>> That's already done long ago.
>>
>> > but as for abstracting the difference
>> > between bus and class... why?
>>
>> There is absolutely no need to needlessly export two versions of the
>> same thing. These directories serve no other purpose than to collect
>> all devices of the same subsystem. There is no useful information that
>> belongs to the type class or bus, they are both the same. Like
>> "inputX" is implemented as a class, but is much more like a bus.
>
> Really, how do you enumerate 'input' buses?
The current inputX devices, unlike eventX and mouseX, are like "bus devices".
>> And "usb" are devices, which are more a class of devices, and the
>> interfaces and contollers belong to a bus.
>
> What common higher-level functionality do USB devices provide?
A device file per example, which can do anything to the device. :)
>> There is really no point to make userspace needlessly complicated to
>> distinguish the both.
>>
>> We also have already a buch of subsystems which moved from class to
>> bus because they needed to express hierarchy between the same devices.
>> So the goal is to have only one type of subsystem to solve these
>> problems.
>
> That's interesting. Which were those?
i2c, iio, and a few which have been out-of-tree and got changed before
the merge, because we knew they would not work as class devices, cause
of the need to have childs, or the need to add additional properties
at the subsystem directory level, just like pci, which has a "slots"
directory at the pci subsystem directory, such stuff is not possible
with the too simple class layout.
> [...]
>> > So while buses and classes both define device interfaces, they are
>> > fundamentally different types of interface.
>>
>> No, they are not. They are just "devices". There is no useful
>> difference these two different types expose. And the class layout is
>> fundamentally broken, and not extendable. Peole mix lists of devices
>> with custom subsystem-wide attributes, which we need to stop from
>> doing this. The bus layout can carry custom directories, which is why
>> we want that by default for all "classifications".
> [...]
>
> I understand that you want to clean up a mess, but how do you know
> you're not going to break user-space that depends on some of this mess?
Just like /sys/block is doing it, /sys/class, /sys/bus will stay as
symlinks, and not go away.
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" 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: [RFC][PATCH v2 0/3] Provide a zero-copy method on KVM virtio-net.
From: Avi Kivity @ 2010-04-03 16:32 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: xiaohui.xin, netdev, kvm, linux-kernel, mingo, mst, jdike, davem
In-Reply-To: <1270252268.13897.14.camel@w-sridhar.beaverton.ibm.com>
On 04/03/2010 02:51 AM, Sridhar Samudrala wrote:
> On Fri, 2010-04-02 at 15:25 +0800, xiaohui.xin@intel.com wrote:
>
>> The idea is simple, just to pin the guest VM user space and then
>> let host NIC driver has the chance to directly DMA to it.
>> The patches are based on vhost-net backend driver. We add a device
>> which provides proto_ops as sendmsg/recvmsg to vhost-net to
>> send/recv directly to/from the NIC driver. KVM guest who use the
>> vhost-net backend may bind any ethX interface in the host side to
>> get copyless data transfer thru guest virtio-net frontend.
>>
> What is the advantage of this approach compared to PCI-passthrough
> of the host NIC to the guest?
>
swapping/ksm/etc
independence from host hardware
live migration
> Does this require pinning of the entire guest memory? Or only the
> send/receive buffers?
>
If done correctly, just the send/receive buffers.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply
* Re: [PATCH 0/6] tagged sysfs support
From: Ben Hutchings @ 2010-04-03 16:05 UTC (permalink / raw)
To: Kay Sievers
Cc: Eric W. Biederman, Greg Kroah-Hartman, Greg KH, linux-kernel,
Tejun Heo, Cornelia Huck, linux-fsdevel, Eric Dumazet,
Benjamin LaHaise, Serge Hallyn, netdev
In-Reply-To: <h2gac3eb2511004030135q2a2f5002z912974c1d2ab8853@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]
On Sat, 2010-04-03 at 10:35 +0200, Kay Sievers wrote:
> On Sat, Apr 3, 2010 at 02:58, Ben Hutchings <ben@decadent.org.uk> wrote:
> > On Wed, 2010-03-31 at 07:51 +0200, Kay Sievers wrote:
> >> Yeah, /sys/bus/, which is the only sane layout of the needlessly
> >> different 3 versions of the same thing (bus, class, block).
> > [...]
> >
> > block vs class/block is arguable,
>
> That's already done long ago.
>
> > but as for abstracting the difference
> > between bus and class... why?
>
> There is absolutely no need to needlessly export two versions of the
> same thing. These directories serve no other purpose than to collect
> all devices of the same subsystem. There is no useful information that
> belongs to the type class or bus, they are both the same. Like
> "inputX" is implemented as a class, but is much more like a bus.
Really, how do you enumerate 'input' buses?
> And "usb" are devices, which are more a class of devices, and the
> interfaces and contollers belong to a bus.
What common higher-level functionality do USB devices provide?
> There is really no point to make userspace needlessly complicated to
> distinguish the both.
>
> We also have already a buch of subsystems which moved from class to
> bus because they needed to express hierarchy between the same devices.
> So the goal is to have only one type of subsystem to solve these
> problems.
That's interesting. Which were those?
[...]
> > So while buses and classes both define device interfaces, they are
> > fundamentally different types of interface.
>
> No, they are not. They are just "devices". There is no useful
> difference these two different types expose. And the class layout is
> fundamentally broken, and not extendable. Peole mix lists of devices
> with custom subsystem-wide attributes, which we need to stop from
> doing this. The bus layout can carry custom directories, which is why
> we want that by default for all "classifications".
[...]
I understand that you want to clean up a mess, but how do you know
you're not going to break user-space that depends on some of this mess?
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] flow: virtualize flow cache entry methods
From: Herbert Xu @ 2010-04-03 15:53 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <4BB74FF8.2020303@iki.fi>
On Sat, Apr 03, 2010 at 05:26:00PM +0300, Timo Teräs wrote:
>
> Why would this block? The device down hook calls flow cache
> flush. On flush all bundles with non-up devices get pruned
> immediately (via stale_bundle check).
Perhaps I missed something in your patch, but the flush that
we currently perform is limited to the bundles from hashed policies.
So if a policy has just recently been removed, then its bundles
won't be flushed.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/4] flow: virtualize flow cache entry methods
From: Timo Teräs @ 2010-04-03 14:26 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100403141709.GA5165@gondor.apana.org.au>
Herbert Xu wrote:
> On Sat, Apr 03, 2010 at 04:50:08PM +0300, Timo Teräs wrote:
>> The flow cache is randomized every ten minutes. Thus all flow
>> cache entries get recreated regularly.
>
> Having rmmod <netdrv> block for up to ten minutes is hardly
> ideal.
Why would this block? The device down hook calls flow cache
flush. On flush all bundles with non-up devices get pruned
immediately (via stale_bundle check).
> Besides, in future we may want to get rid of the regular reseeding
> just like we did for IPv4 routes.
Right. It certainly sounds good. And needs a separate change
then.
If this is done, we will need to still have some sort of
periodic gc for flow cache, just like ipv4 routes have. The
gc would on each tick scan just some of the flow cache hash
chains.
^ permalink raw reply
* Re: [PATCH 1/4] flow: virtualize flow cache entry methods
From: Herbert Xu @ 2010-04-03 14:17 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <4BB74790.7070109@iki.fi>
On Sat, Apr 03, 2010 at 04:50:08PM +0300, Timo Teräs wrote:
>
> The flow cache is randomized every ten minutes. Thus all flow
> cache entries get recreated regularly.
Having rmmod <netdrv> block for up to ten minutes is hardly
ideal.
Besides, in future we may want to get rid of the regular reseeding
just like we did for IPv4 routes.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/4] flow: virtualize flow cache entry methods
From: Timo Teräs @ 2010-04-03 13:50 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20100403083609.GA3654@gondor.apana.org.au>
Herbert Xu wrote:
> With repsect to removing the cache flush upon policy removal,
> what takes care of the timely purging of the corresponding cache
> entries if no new traffic comes through?
>
> The concern is that if they're not purged in the absence of new
> traffic, then we may hold references on all sorts of objects,
> leading to consequences such as the inability to unregister net
> devices.
The flow cache is randomized every ten minutes. Thus all flow
cache entries get recreated regularly.
> On Sat, Apr 03, 2010 at 11:38:57AM +0800, Herbert Xu wrote:
>> With repsect to removing the cache flush upon policy removal,
>> what takes care of the timely purging of the corresponding cache
>> entries if no new traffic comes through?
>
> In fact this change would seem to render the existing bundle
> pruning mechanism when devices are unregistered ineffective.
>
> xfrm_prune_bundles walks through active policy lists to find
> the bundles to purge. However, if a policy has been deleted
> while a bundle referencing it is still in the cache, that bundle
> will not be pruned.
When policy is killed, the policy->genid is incremented which
makes xfrm_bundle_ok check fail and the bundle to get pruned
immediately on flush.
^ permalink raw reply
* Re: [PATCH 1/4] flow: virtualize flow cache entry methods
From: Herbert Xu @ 2010-04-03 8:36 UTC (permalink / raw)
To: Timo Teras; +Cc: netdev
In-Reply-To: <20100403033857.GA2205@gondor.apana.org.au>
On Sat, Apr 03, 2010 at 11:38:57AM +0800, Herbert Xu wrote:
>
> With repsect to removing the cache flush upon policy removal,
> what takes care of the timely purging of the corresponding cache
> entries if no new traffic comes through?
In fact this change would seem to render the existing bundle
pruning mechanism when devices are unregistered ineffective.
xfrm_prune_bundles walks through active policy lists to find
the bundles to purge. However, if a policy has been deleted
while a bundle referencing it is still in the cache, that bundle
will not be pruned.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 0/6] tagged sysfs support
From: Kay Sievers @ 2010-04-03 8:35 UTC (permalink / raw)
To: Ben Hutchings
Cc: Eric W. Biederman, Greg Kroah-Hartman, Greg KH, linux-kernel,
Tejun Heo, Cornelia Huck, linux-fsdevel, Eric Dumazet,
Benjamin LaHaise, Serge Hallyn, netdev
In-Reply-To: <1270256303.12516.234.camel@localhost>
On Sat, Apr 3, 2010 at 02:58, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Wed, 2010-03-31 at 07:51 +0200, Kay Sievers wrote:
>> Yeah, /sys/bus/, which is the only sane layout of the needlessly
>> different 3 versions of the same thing (bus, class, block).
> [...]
>
> block vs class/block is arguable,
That's already done long ago.
> but as for abstracting the difference
> between bus and class... why?
There is absolutely no need to needlessly export two versions of the
same thing. These directories serve no other purpose than to collect
all devices of the same subsystem. There is no useful information that
belongs to the type class or bus, they are both the same. Like
"inputX" is implemented as a class, but is much more like a bus. And
"usb" are devices, which are more a class of devices, and the
interfaces and contollers belong to a bus.
There is really no point to make userspace needlessly complicated to
distinguish the both.
We also have already a buch of subsystems which moved from class to
bus because they needed to express hierarchy between the same devices.
So the goal is to have only one type of subsystem to solve these
problems.
> Each bus defines a device interface covering enumeration,
> identification, power management and various aspects of their connection
> to the host. This interface is implemented by the bus driver.
Sure, but that does not mean that class is a useful layout, or that
class devices can not do the same.
> Each class defines a device interface covering functionality provided to
> user-space or higher level kernel components (block interface to
> filesystems, net driver interface to the networking core, etc). This
> interface is implemented by multiple device-specific drivers.
That's absolutely wrong. Classes are just too simple uses of the same
thing. We have many class devices which are not "interfaces", and we
have bus devices which are interfaces.
> So while buses and classes both define device interfaces, they are
> fundamentally different types of interface.
No, they are not. They are just "devices". There is no useful
difference these two different types expose. And the class layout is
fundamentally broken, and not extendable. Peole mix lists of devices
with custom subsystem-wide attributes, which we need to stop from
doing this. The bus layout can carry custom directories, which is why
we want that by default for all "classifications".
> And there are 'subsystems'
> that don't have devices at all (time, RCU, perf, ...). If you're going
> to expose the set of subsystems, don't they belong in there?
> But then,
We are talking about the current users in /sys, and the difference in
the sysfs export between /sys/bus and /sys/class.
> what would you put in their directories?
We are not talking about anything not in /sys currently.
Kay
^ permalink raw reply
* Re: [PATCH] ethtool: add names of newer Marvell chips
From: Mark Ryden @ 2010-04-03 7:20 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jeff Garzik, netdev
In-Reply-To: <20100402081632.5401cf2f@nehalam>
Hi,
> + case 0xba: printf("Yukon Ultra 2"); break;
> + case 0xbc: printf("Yukon Optima"); break;
What about 0xbb?
Is there ant reason for not using 0xbb for Yukon Optima?
Is it something with blackberry (bb)? :-)
Mark
On Fri, Apr 2, 2010 at 6:16 PM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> Fill in names of newer chips.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
>
> diff --git a/marvell.c b/marvell.c
> index 6696e0a..af38c21 100644
> --- a/marvell.c
> +++ b/marvell.c
> @@ -184,6 +184,9 @@ static void dump_mac(const u8 *r)
> case 0xb6: printf("Yukon-2 EC"); break;
> case 0xb7: printf("Yukon-2 FE"); break;
> case 0xb8: printf("Yukon-2 FE Plus"); break;
> + case 0xb9: printf("Yukon Supreme"); break;
> + case 0xba: printf("Yukon Ultra 2"); break;
> + case 0xbc: printf("Yukon Optima"); break;
> default: printf("(Unknown)"); break;
> }
>
> --
> 1.6.3.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 1/4] flow: virtualize flow cache entry methods
From: Herbert Xu @ 2010-04-03 3:38 UTC (permalink / raw)
To: Timo Teras; +Cc: netdev
In-Reply-To: <1270126340-30181-2-git-send-email-timo.teras@iki.fi>
On Thu, Apr 01, 2010 at 03:52:17PM +0300, Timo Teras wrote:
> This allows to validate the cached object before returning it.
> It also allows to destruct object properly, if the last reference
> was held in flow cache. This is also a prepartion for caching
> bundles in the flow cache.
>
> In return for virtualizing the methods, we save on:
> - not having to regenerate the whole flow cache on policy removal:
> each flow matching a killed policy gets refreshed as the getter
> function notices it smartly.
> - we do not have to call flow_cache_flush from policy gc, since the
> flow cache now properly deletes the object if it had any references
>
> Signed-off-by: Timo Teras <timo.teras@iki.fi>
With repsect to removing the cache flush upon policy removal,
what takes care of the timely purging of the corresponding cache
entries if no new traffic comes through?
The concern is that if they're not purged in the absence of new
traffic, then we may hold references on all sorts of objects,
leading to consequences such as the inability to unregister net
devices.
> struct flow_cache_entry {
> - struct flow_cache_entry *next;
> - u16 family;
> - u8 dir;
> - u32 genid;
> - struct flowi key;
> - void *object;
> - atomic_t *object_ref;
> + struct flow_cache_entry * next;
Please follow the existing coding style.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
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