* [PATCH v2.37 1/6] odp: Only pass vlan_tci to commit_vlan_action()
From: Simon Horman @ 2013-08-20 2:15 UTC (permalink / raw)
To: dev, netdev
Cc: Ravi K, Isaku Yamahata, Jesse Gross, Pravin B Shelar,
Joe Stringer
In-Reply-To: <1376964964-18151-1-git-send-email-horms@verge.net.au>
From: Joe Stringer <joe@wand.net.nz>
This allows for future patches to pass different tci values to
commit_vlan_action() without passing an entire flow structure.
Signed-off-by: Joe Stringer <joe@wand.net.nz>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
v2.36 - v2.37
* No change
v2.35
* First post
---
lib/odp-util.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/odp-util.c b/lib/odp-util.c
index a09042e..d0c9bbe 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -3097,10 +3097,10 @@ commit_set_ether_addr_action(const struct flow *flow, struct flow *base,
}
static void
-commit_vlan_action(const struct flow *flow, struct flow *base,
+commit_vlan_action(ovs_be16 vlan_tci, struct flow *base,
struct ofpbuf *odp_actions, struct flow_wildcards *wc)
{
- if (base->vlan_tci == flow->vlan_tci) {
+ if (base->vlan_tci == vlan_tci) {
return;
}
@@ -3110,15 +3110,15 @@ commit_vlan_action(const struct flow *flow, struct flow *base,
nl_msg_put_flag(odp_actions, OVS_ACTION_ATTR_POP_VLAN);
}
- if (flow->vlan_tci & htons(VLAN_CFI)) {
+ if (vlan_tci & htons(VLAN_CFI)) {
struct ovs_action_push_vlan vlan;
vlan.vlan_tpid = htons(ETH_TYPE_VLAN);
- vlan.vlan_tci = flow->vlan_tci;
+ vlan.vlan_tci = vlan_tci;
nl_msg_put_unspec(odp_actions, OVS_ACTION_ATTR_PUSH_VLAN,
&vlan, sizeof vlan);
}
- base->vlan_tci = flow->vlan_tci;
+ base->vlan_tci = vlan_tci;
}
static void
@@ -3330,7 +3330,7 @@ commit_odp_actions(const struct flow *flow, struct flow *base,
struct ofpbuf *odp_actions, struct flow_wildcards *wc)
{
commit_set_ether_addr_action(flow, base, odp_actions, wc);
- commit_vlan_action(flow, base, odp_actions, wc);
+ commit_vlan_action(flow->vlan_tci, base, odp_actions, wc);
commit_set_nw_action(flow, base, odp_actions, wc);
commit_set_port_action(flow, base, odp_actions, wc);
/* Committing MPLS actions should occur after committing nw and port
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] ipv6: handle Redirect ICMP Message with no Redirected Header option
From: Duan Jiong @ 2013-08-20 2:00 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: davem, netdev
In-Reply-To: <52126B54.4080603@cogentembedded.com>
于 2013年08月20日 03:00, Sergei Shtylyov 写道:
> Hello.
>
> On 08/19/2013 02:54 PM, Duan Jiong wrote:
>
>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>
>> rfc 4861 says the Redirected Header option is optional, so
>> the kernel should not drop the Redirect Message that has no
>> Redirected Header option. In this patch, the function
>> ip6_redirect_no_header() is introduced to deal with that
>> condition.
>
>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> [...]
>
>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>> index b70f897..9934b87 100644
>> --- a/net/ipv6/route.c
>> +++ b/net/ipv6/route.c
>> @@ -1178,6 +1178,27 @@ void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark)
>> }
>> EXPORT_SYMBOL_GPL(ip6_redirect);
>>
>> +void ip6_redirect_no_header(struct sk_buff *skb, struct net *net, int oif, u32 mark)
>> +{
>> + const struct ipv6hdr *iph = (struct ipv6hdr *) skb_network_header(skb);
>> + struct rd_msg *msg = (struct rd_msg *)skb_transport_header(skb);
>
> Be consistent please: either put space after a typecast or not.
>
Thanks for you help, i will apply it in next version.
Thanks,
Duan
^ permalink raw reply
* Re: [PATCH] ipv6: handle Redirect ICMP Message with no Redirected Header option
From: Duan Jiong @ 2013-08-20 1:56 UTC (permalink / raw)
To: hannes; +Cc: davem, netdev
In-Reply-To: <20130819115512.GC9414@order.stressinduktion.org>
于 2013年08月19日 19:55, Hannes Frederic Sowa 写道:
> On Mon, Aug 19, 2013 at 06:54:51PM +0800, Duan Jiong wrote:
>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>
>> rfc 4861 says the Redirected Header option is optional, so
>> the kernel should not drop the Redirect Message that has no
>> Redirected Header option. In this patch, the function
>> ip6_redirect_no_header() is introduced to deal with that
>> condition.
>>
>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>> ---
>> include/net/ip6_route.h | 1 +
>> net/ipv6/ndisc.c | 4 +++-
>> net/ipv6/route.c | 21 +++++++++++++++++++++
>> 3 files changed, 25 insertions(+), 1 deletions(-)
>>
>> diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
>> index 260f83f..7966f54 100644
>> --- a/include/net/ip6_route.h
>> +++ b/include/net/ip6_route.h
>> @@ -135,6 +135,7 @@ extern void ip6_update_pmtu(struct sk_buff *skb, struct net *net, __be32 mtu,
>> extern void ip6_sk_update_pmtu(struct sk_buff *skb, struct sock *sk,
>> __be32 mtu);
>> extern void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark);
>> +extern void ip6_redirect_no_header(struct sk_buff *skb, struct net *net, int oif, u32 mark);
>> extern void ip6_sk_redirect(struct sk_buff *skb, struct sock *sk);
>>
>> struct netlink_callback;
>> diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
>> index 79aa965..04d31c2 100644
>> --- a/net/ipv6/ndisc.c
>> +++ b/net/ipv6/ndisc.c
>> @@ -1369,8 +1369,10 @@ static void ndisc_redirect_rcv(struct sk_buff *skb)
>> if (!ndisc_parse_options(msg->opt, ndoptlen, &ndopts))
>> return;
>>
>> - if (!ndopts.nd_opts_rh)
>> + if (!ndopts.nd_opts_rh) {
>> + ip6_redirect_no_header(skb, dev_net(skb->dev), 0, 0);
>> return;
>> + }
>
> Can't we just jump down to icmpv6_notify without introducing
> ip6_redirect_no_header?
>
No, the function icmpv6_notify need the skb->data point the inner IP
packet that triggered the sending of the ICMP Message, so when the
Redirect Message has no Redirected Header option, it should not be
handled in icmpv6_notify.
>>
>> hdr = (u8 *)ndopts.nd_opts_rh;
>> hdr += 8;
>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>> index b70f897..9934b87 100644
>> --- a/net/ipv6/route.c
>> +++ b/net/ipv6/route.c
>> @@ -1178,6 +1178,27 @@ void ip6_redirect(struct sk_buff *skb, struct net *net, int oif, u32 mark)
>> }
>> EXPORT_SYMBOL_GPL(ip6_redirect);
>>
>> +void ip6_redirect_no_header(struct sk_buff *skb, struct net *net, int oif, u32 mark)
>> +{
>> + const struct ipv6hdr *iph = (struct ipv6hdr *) skb_network_header(skb);
>
> const struct ipv6hdr *iph = ipv6_hdr(skb);
>
Thanks for you help, i will apply it in next version.
Thanks,
Duan
^ permalink raw reply
* Re: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was called
From: Fan Du @ 2013-08-20 1:56 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Steffen Klassert, David Miller, Herbert Xu, Daniel Borkmann, LKML,
netdev
In-Reply-To: <alpine.DEB.2.02.1308181102230.4089@ionos.tec.linutronix.de>
On 2013年08月18日 17:05, Thomas Gleixner wrote:
> On Wed, 14 Aug 2013, Fan Du wrote:
>
>> From e3929d4fdfad5b40fd8cad0e217597670d1aef54 Mon Sep 17 00:00:00 2001
>> From: Fan Du<fan.du@windriver.com>
>> Date: Wed, 14 Aug 2013 16:39:23 +0800
>> Subject: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was
>> called
>>
>> When clock_was_set is called in case of system wall time change
>> or host resume from suspend state, use this notifier for places
>> where interested in this action, e.g Ipsec SA lifetime management.
>
> Sigh. These notifiers have been proposed in the past and we always
> rejected them. Why do you need this? There should be nothing except
> the core timekeeping code which needs to know about clock_was_set.
>
> Can you please explain what kind of users you have in mind and WHY
> they need to know about it.
Hi, Thomas
Thanks for your patience. Please let me take a few seconds try to
explain this.
Current xfrm layers has *one* hrtimer to guard Ipsec keys timeout,
The timeout could be measured in either of below two ways:
(1) The timer is started once the keys is created, but this
key is not necessary actually used right now. In detail,
record the get_seconds() when this key is created.
(2) Starting the timer when this key is actually used, e.g when
an IP packet need to be encrypted. In details, recored the
get_seconds() when this key is first used.
So in the hrtimer handler, the code get current get_seconds, and
check against with what saved in (1)or(2), and notify the timeout
up to user land.
So the pitfall is using one hrtimer for two timeout events,
most importantly using get_seconds to check timeout, once system
clock is changed by user intentionally, the key timeout could
misbehave wildly.
A refractor has been proposed to get rid of depending on system wall
clock by cleaning up the hrtimer handler. Unfortunately David frowned
on it in (3), and suggest once system clock is changed, adjust the
timeout of the key.
(3): http://www.spinics.net/lists/netdev/msg245169.html
> Thanks,
>
> tglx
>
--
浮沉随浪只记今朝笑
--fan
^ permalink raw reply
* Re: [PATCH ipsec v2 1/3] ipv6: wire up skb->encapsulation
From: Simon Horman @ 2013-08-20 1:49 UTC (permalink / raw)
To: netdev, steffen.klassert, yoshfuji, nicolas.dichtel, edumazet
In-Reply-To: <20130820003651.GA3938@order.stressinduktion.org>
On Tue, Aug 20, 2013 at 02:36:51AM +0200, Hannes Frederic Sowa wrote:
> On Tue, Aug 20, 2013 at 10:35:46AM +1000, Simon Horman wrote:
> > On Sun, Aug 18, 2013 at 01:46:52PM +0200, Hannes Frederic Sowa wrote:
> > > When pushing a new header before current one call skb_reset_inner_headers
> > > to record the position of the inner headers in the various ipv6 tunnel
> > > protocols.
> > >
> > > We later need this to correctly identify the addresses needed to send
> > > back an error in the xfrm layer.
> > >
> > > This change is safe, because skb->protocol is always checked before
> > > dereferencing data from the inner protocol.
> >
> > It seems that the intention is to only track the inner-most header
> > due to the presence of if (likely(!skb->encapsulation)). Is this the
> > intention?
>
> Ack. Do you see problems with this?
Not if it is intended.
Reviewed-by: Simon Horman <horms@verge.net.au>
^ permalink raw reply
* Re: [PATCH ipsec v2 1/3] ipv6: wire up skb->encapsulation
From: Hannes Frederic Sowa @ 2013-08-20 0:36 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, steffen.klassert, yoshfuji, nicolas.dichtel, edumazet
In-Reply-To: <20130820003546.GA14038@verge.net.au>
On Tue, Aug 20, 2013 at 10:35:46AM +1000, Simon Horman wrote:
> On Sun, Aug 18, 2013 at 01:46:52PM +0200, Hannes Frederic Sowa wrote:
> > When pushing a new header before current one call skb_reset_inner_headers
> > to record the position of the inner headers in the various ipv6 tunnel
> > protocols.
> >
> > We later need this to correctly identify the addresses needed to send
> > back an error in the xfrm layer.
> >
> > This change is safe, because skb->protocol is always checked before
> > dereferencing data from the inner protocol.
>
> It seems that the intention is to only track the inner-most header
> due to the presence of if (likely(!skb->encapsulation)). Is this the
> intention?
Ack. Do you see problems with this?
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH ipsec v2 1/3] ipv6: wire up skb->encapsulation
From: Simon Horman @ 2013-08-20 0:35 UTC (permalink / raw)
To: netdev, steffen.klassert, yoshfuji, nicolas.dichtel, edumazet
In-Reply-To: <20130818114652.GA10192@order.stressinduktion.org>
On Sun, Aug 18, 2013 at 01:46:52PM +0200, Hannes Frederic Sowa wrote:
> When pushing a new header before current one call skb_reset_inner_headers
> to record the position of the inner headers in the various ipv6 tunnel
> protocols.
>
> We later need this to correctly identify the addresses needed to send
> back an error in the xfrm layer.
>
> This change is safe, because skb->protocol is always checked before
> dereferencing data from the inner protocol.
It seems that the intention is to only track the inner-most header
due to the presence of if (likely(!skb->encapsulation)). Is this the
intention?
>
> v2:
> a) unchanged
>
> Cc: Steffen Klassert <steffen.klassert@secunet.com>
> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> Acked-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
>
> This patch is based on Steffen Klassert's ipsec tree.
>
> net/ipv6/ip6_gre.c | 5 +++++
> net/ipv6/ip6_tunnel.c | 6 ++++++
> net/ipv6/sit.c | 5 +++++
> 3 files changed, 16 insertions(+)
>
> diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
> index ecd6073..90747f1 100644
> --- a/net/ipv6/ip6_gre.c
> +++ b/net/ipv6/ip6_gre.c
> @@ -724,6 +724,11 @@ static netdev_tx_t ip6gre_xmit2(struct sk_buff *skb,
> ipv6_push_nfrag_opts(skb, &opt.ops, &proto, NULL);
> }
>
> + if (likely(!skb->encapsulation)) {
> + skb_reset_inner_headers(skb);
> + skb->encapsulation = 1;
> + }
> +
> skb_push(skb, gre_hlen);
> skb_reset_network_header(skb);
> skb_set_transport_header(skb, sizeof(*ipv6h));
> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
> index 1e55866..46ba243 100644
> --- a/net/ipv6/ip6_tunnel.c
> +++ b/net/ipv6/ip6_tunnel.c
> @@ -1027,6 +1027,12 @@ static int ip6_tnl_xmit2(struct sk_buff *skb,
> init_tel_txopt(&opt, encap_limit);
> ipv6_push_nfrag_opts(skb, &opt.ops, &proto, NULL);
> }
> +
> + if (likely(!skb->encapsulation)) {
> + skb_reset_inner_headers(skb);
> + skb->encapsulation = 1;
> + }
> +
> skb_push(skb, sizeof(struct ipv6hdr));
> skb_reset_network_header(skb);
> ipv6h = ipv6_hdr(skb);
> diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
> index a3437a4..fbfc5a8 100644
> --- a/net/ipv6/sit.c
> +++ b/net/ipv6/sit.c
> @@ -888,6 +888,11 @@ static netdev_tx_t ipip6_tunnel_xmit(struct sk_buff *skb,
> ttl = iph6->hop_limit;
> tos = INET_ECN_encapsulate(tos, ipv6_get_dsfield(iph6));
>
> + if (likely(!skb->encapsulation)) {
> + skb_reset_inner_headers(skb);
> + skb->encapsulation = 1;
> + }
> +
> err = iptunnel_xmit(dev_net(dev), rt, skb, fl4.saddr, fl4.daddr,
> IPPROTO_IPV6, tos, ttl, df);
> iptunnel_xmit_stats(err, &dev->stats, dev->tstats);
> --
> 1.8.3.1
>
> --
> 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 net-next v7 8/8] openvswitch: Add vxlan tunneling support.
From: Jesse Gross @ 2013-08-20 0:25 UTC (permalink / raw)
To: Pravin B Shelar; +Cc: netdev, David Miller, Stephen Hemminger
In-Reply-To: <1376936614-25770-1-git-send-email-pshelar@nicira.com>
On Mon, Aug 19, 2013 at 11:23 AM, Pravin B Shelar <pshelar@nicira.com> wrote:
> Following patch adds vxlan vport type for openvswitch using
> vxlan api. So now there is vxlan dependency for openvswitch.
>
> CC: Jesse Gross <jesse@nicira.com>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
^ permalink raw reply
* [PATCH] drivers:net:ifb: Fixed coding style error:assignment in if statement
From: Sanil Kumar D @ 2013-08-19 23:39 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, Sanil Kumar D
Fixed coding style error (assignment within if statement at 2 places in drivers/net/ifb.c)
Signed-off-by: Sanil Kumar D <skd.linux@gmail.com>
---
drivers/net/ifb.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c
index a3bed28..f3fa85a 100644
--- a/drivers/net/ifb.c
+++ b/drivers/net/ifb.c
@@ -68,7 +68,8 @@ static void ri_tasklet(unsigned long dev)
struct sk_buff *skb;
txq = netdev_get_tx_queue(_dev, 0);
- if ((skb = skb_peek(&dp->tq)) == NULL) {
+ skb = skb_peek(&dp->tq);
+ if (skb == NULL) {
if (__netif_tx_trylock(txq)) {
skb_queue_splice_tail_init(&dp->rq, &dp->tq);
__netif_tx_unlock(txq);
@@ -112,7 +113,8 @@ static void ri_tasklet(unsigned long dev)
}
if (__netif_tx_trylock(txq)) {
- if ((skb = skb_peek(&dp->rq)) == NULL) {
+ skb = skb_peek(&dp->rq);
+ if (skb == NULL) {
dp->tasklet_pending = 0;
if (netif_queue_stopped(_dev))
netif_wake_queue(_dev);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] Fix stack corruption on some architectures
From: Daniel Gimpelevich @ 2013-08-19 22:39 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Jan Dumon, Greg Kroah-Hartman, linux-usb, netdev, linux-kernel
In-Reply-To: <52129CD4.1060200@cogentembedded.com>
On Tue, 2013-08-20 at 02:31 +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 08/20/2013 12:37 AM, Daniel Gimpelevich wrote:
>
> > There is no need to get an interface specification if we know it's the
> > wrong one; trivial change.
>
> Is it related to stack corruption? If not, it's asking to be in a separate
> patch.
Perhaps, but I'll leave that up to the maintainer(s). You should be
credited as co-author of the patch.
^ permalink raw reply
* Re: [PATCH] Fix stack corruption on some architectures
From: Sergei Shtylyov @ 2013-08-19 22:31 UTC (permalink / raw)
To: Daniel Gimpelevich
Cc: Jan Dumon, Greg Kroah-Hartman, linux-usb, netdev, linux-kernel
In-Reply-To: <1376944647.5082.12.camel@chimera>
Hello.
On 08/20/2013 12:37 AM, Daniel Gimpelevich wrote:
> There is no need to get an interface specification if we know it's the
> wrong one; trivial change.
Is it related to stack corruption? If not, it's asking to be in a separate
patch.
> The big thing, though, was explained in the
> #mipslinux IRC channel:
> [Mon 2013-08-19 12:28:21 PM PDT] <headless> guys, are you sure it's not "DMA off stack" case?
> [Mon 2013-08-19 12:28:35 PM PDT] <headless> it's a known stack corruptor on non-coherent arches
> [Mon 2013-08-19 12:31:48 PM PDT] <DonkeyHotei> headless: for usb/ehci?
> [Mon 2013-08-19 12:34:11 PM PDT] <DonkeyHotei> headless: explain
> [Mon 2013-08-19 12:35:38 PM PDT] <headless> usb_control_msg() (or other such func) should not use buffer on stack. DMA from/to stack is prohibited
> [Mon 2013-08-19 12:35:58 PM PDT] <headless> and EHCI uses DMA on control xfers (as well as all the others)
That headless was me. :-)
> Signed-off-by: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
WBR, Sergei
^ permalink raw reply
* [patch -next v2] ipip: dereferencing an ERR_PTR in ip_tunnel_init_net()
From: Dan Carpenter @ 2013-08-19 22:23 UTC (permalink / raw)
To: David S. Miller, Nicolas Dichtel
Cc: Alexey Kuznetsov, Eric Dumazet, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, netdev, kernel-janitors
In-Reply-To: <1376917088.4226.50.camel@edumazet-glaptop>
The __ip_tunnel_create() function returns an ERR_PTR on error so we need
to check for that before dereferencing. This bug was added in commit
6c742e714d8c2 ("ipip: add x-netns support").
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
v2: Eric Dumazet said v1 patch looked racy and suggested the v2 fix.
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index a4d9126..830de3f 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -857,13 +857,11 @@ int ip_tunnel_init_net(struct net *net, int ip_tnl_net_id,
/* FB netdevice is special: we have one, and only one per netns.
* Allowing to move it to another netns is clearly unsafe.
*/
- itn->fb_tunnel_dev->features |= NETIF_F_NETNS_LOCAL;
+ if (!IS_ERR(itn->fb_tunnel_dev))
+ itn->fb_tunnel_dev->features |= NETIF_F_NETNS_LOCAL;
rtnl_unlock();
- if (IS_ERR(itn->fb_tunnel_dev))
- return PTR_ERR(itn->fb_tunnel_dev);
-
- return 0;
+ return PTR_RET(itn->fb_tunnel_dev);
}
EXPORT_SYMBOL_GPL(ip_tunnel_init_net);
^ permalink raw reply related
* Re: [PATCH] Fix stack corruption on some architectures
From: Greg Kroah-Hartman @ 2013-08-19 22:23 UTC (permalink / raw)
To: Daniel Gimpelevich; +Cc: Jan Dumon, linux-usb, netdev, linux-kernel
In-Reply-To: <1376944647.5082.12.camel@chimera>
On Mon, Aug 19, 2013 at 01:37:27PM -0700, Daniel Gimpelevich wrote:
> There is no need to get an interface specification if we know it's the
> wrong one; trivial change. The big thing, though, was explained in the
> #mipslinux IRC channel:
> [Mon 2013-08-19 12:28:21 PM PDT] <headless> guys, are you sure it's not "DMA off stack" case?
> [Mon 2013-08-19 12:28:35 PM PDT] <headless> it's a known stack corruptor on non-coherent arches
> [Mon 2013-08-19 12:31:48 PM PDT] <DonkeyHotei> headless: for usb/ehci?
> [Mon 2013-08-19 12:34:11 PM PDT] <DonkeyHotei> headless: explain
> [Mon 2013-08-19 12:35:38 PM PDT] <headless> usb_control_msg() (or other such func) should not use buffer on stack. DMA from/to stack is prohibited
> [Mon 2013-08-19 12:35:58 PM PDT] <headless> and EHCI uses DMA on control xfers (as well as all the others)
>
> Signed-off-by: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Jozsef Kadlecsik @ 2013-08-19 22:07 UTC (permalink / raw)
To: Eric Dumazet
Cc: Christoph Paasch, Corey Hickey, Linux Netdev List,
netfilter-devel
In-Reply-To: <1376946527.4226.80.camel@edumazet-glaptop>
On Mon, 19 Aug 2013, Eric Dumazet wrote:
> On Mon, 2013-08-19 at 22:13 +0200, Jozsef Kadlecsik wrote:
> > On Mon, 19 Aug 2013, Eric Dumazet wrote:
> >
> > > On Mon, 2013-08-19 at 15:49 +0200, Christoph Paasch wrote:
> > >
> > > > It's a TCP-patch, that interprets duplicate-acks with invalid
> > > > SACK-blocks as duplicate acks in tcp_sock->sacked_out.
> > >
> > > Yeah, but here, this is conntrack who is blocking the thing.
> > >
> > > TCP receiver has no chance to 'fix' it.
> > >
> > > See conntrack is one of those buggy middle box as well.
> > >
> > > So if you want to properly handle this mess, you'll also have to fix
> > > conntrack.
> >
> > I beg you pardon: why conntrack should be relaxed, when it is expected
> > to do more strict TCP checkings (RFC5961, Section 5.).
> >
> > Also, it's clearly a broken middle box. Don't shoot the messenger.
>
> Frames are dropped by conntrack, before TCP receiver can even have a
> choice.
>
> So Christoph patch would be of no use for Corey.
Yes, exactly.
> I do not think I shot anyone, only stated the truth.
There's a middlebox in the path wich breaks SACK completely and conntrack
drops (technically marks as INVALID) the packets with bogus SACK options.
It can be fixed by fixing the middlebox, or disabling SACK by the
TCPOPTSTRIP target, or by relaxing conntrack. For the latter, the next
untested patch may be sufficient:
diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
index 7dcc376..8b5d783 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -649,6 +649,11 @@ static bool tcp_in_window(const struct nf_conn *ct,
receiver->td_end, receiver->td_maxend, receiver->td_maxwin,
receiver->td_scale);
+ /* Fall back to ACK when SACK is bogus */
+ if (!(before(sack, receiver->td_end + 1) &&
+ after(sack, receiver->td_end - MAXACKWINDOW(sender) - 1)))
+ sack = ack;
+
pr_debug("tcp_in_window: I=%i II=%i III=%i IV=%i\n",
before(seq, sender->td_maxend + 1),
after(end, sender->td_end - receiver->td_maxwin - 1),
However it is good to cover the issue thus?
> We have workarounds in our stack to 'fix' bugs from others, there
> is no shame in this.
>
> Glad to see you are interested in RFC 5961 support, as conntrack is
> known to break the ACK challenges in response to RST messages (section
> 3)
*Any* netfilter configuration where the non-allowed TCP packets are
dropped and not rejected breaks the ACK challenges. That is why I consider
only section 5 useful from RFC 5961.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply related
* Re: [Patch net-next v3 9/9] selinux: use generic union inet_addr
From: Casey Schaufler @ 2013-08-19 21:42 UTC (permalink / raw)
To: David Miller
Cc: amwang, netdev, james.l.morris, sds, eparis, pmoore, linux-kernel,
linux-security-module
In-Reply-To: <20130819.125026.636442915180863272.davem@davemloft.net>
On 8/19/2013 12:50 PM, David Miller wrote:
> It's so that you can pass a generic ipv4/ipv6 address blob into
> things like printf formatting, and since there is an address family
> member present, it knows what's in there and therefore one printf
> format specifier can handle both ipv4 and ipv6 addresses.
The patch message needs to say that, then.
> Like you, I think these changes a complete waste of time too, I'm just
> relaying what I was told.
Well, they certainly don't appear to add any value on their own.
I also generally oppose doing clever things with data structures.
I recently got bitten by the "obvious" relationships between
sockaddr, sockaddr_in and sockaddr_in6, and I've been doing this
stuff since before ioctl was invented.
^ permalink raw reply
* Re: [RFC 0/2] Account for duplicate ACKs with invalid SACK-blocks
From: Corey Hickey @ 2013-08-19 21:22 UTC (permalink / raw)
To: Christoph Paasch; +Cc: Eric Dumazet, netdev, Phil Oester, Benjamin Hesmans
In-Reply-To: <1376940568-16512-1-git-send-email-christoph.paasch@uclouvain.be>
On 2013-08-19 12:29, Christoph Paasch wrote:
> There exist sequence-number rewriting middleboxes, who do not modify the
> sequence-number in the SACK-blocks.
> Duplicate acknowledgments with these (invalid) SACK-blocks will not be
> accounted in sacked_out, and thus no fast-retransmit will trigger.
> So, the only way to recover from a packet-loss is through an RTO,
> effectively killing the performance of TCP in this case.
>
> Performance-results can be seen here:
> http://tools.ietf.org/agenda/87/slides/slides-87-tcpm-11.pdf
>
> Another solution might be to simply disable SACK, as soon as an invalid
> SACK-block has been received (as suggested by Phil Oester). This however
> might be too aggressive.
>
> Christoph Paasch (2):
> Use acked_out for reno-style ack acounting instead of sacked_out
> Account acked_out in sack, if the sack is invalid
>
> include/linux/tcp.h | 1 +
> include/net/tcp.h | 17 +++++---
> net/ipv4/tcp_input.c | 103 ++++++++++++++++++++++++++++++++---------------
> net/ipv4/tcp_minisocks.c | 1 +
> net/ipv4/tcp_output.c | 6 +--
> net/ipv4/tcp_timer.c | 2 +-
> 6 files changed, 89 insertions(+), 41 deletions(-)
I tested this patchset, and, unfortunately, the behavior seems to be the
same.
I'm still planning on working with the Cisco device, when I can get some
of the network admin's time, but that won't happen immediately.
Thanks,
Corey
^ permalink raw reply
* Re: [PATCH net] packet: restore packet statistics tp_packets to include drops
From: Daniel Borkmann @ 2013-08-19 21:11 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: davem, netdev, sergei.shtylyov
In-Reply-To: <1376944822-30454-1-git-send-email-willemb@google.com>
On 08/19/2013 10:40 PM, Willem de Bruijn wrote:
> getsockopt PACKET_STATISTICS returns tp_packets + tp_drops. Commit
> ee80fbf301 ("packet: account statistics only in tpacket_stats_u")
> cleaned up the getsockopt PACKET_STATISTICS code.
> This also changed semantics. Historically, tp_packets included
> tp_drops on return. The commit removed the line that adds tp_drops
> into tp_packets.
>
> This patch reinstates the old semantics.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Daniel Borkmann <dborkman@redhat.com>
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Eric Dumazet @ 2013-08-19 21:08 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Christoph Paasch, Corey Hickey, Linux Netdev List,
netfilter-devel
In-Reply-To: <alpine.DEB.2.00.1308192207130.27869@blackhole.kfki.hu>
On Mon, 2013-08-19 at 22:13 +0200, Jozsef Kadlecsik wrote:
> On Mon, 19 Aug 2013, Eric Dumazet wrote:
>
> > On Mon, 2013-08-19 at 15:49 +0200, Christoph Paasch wrote:
> >
> > > It's a TCP-patch, that interprets duplicate-acks with invalid SACK-blocks as
> > > duplicate acks in tcp_sock->sacked_out.
> >
> > Yeah, but here, this is conntrack who is blocking the thing.
> >
> > TCP receiver has no chance to 'fix' it.
> >
> > See conntrack is one of those buggy middle box as well.
> >
> > So if you want to properly handle this mess, you'll also have to fix
> > conntrack.
>
> I beg you pardon: why conntrack should be relaxed, when it is expected
> to do more strict TCP checkings (RFC5961, Section 5.).
>
> Also, it's clearly a broken middle box. Don't shoot the messenger.
Frames are dropped by conntrack, before TCP receiver can even have a
choice.
So Christoph patch would be of no use for Corey.
I do not think I shot anyone, only stated the truth.
We have workarounds in our stack to 'fix' bugs from others, there
is no shame in this.
Glad to see you are interested in RFC 5961 support, as conntrack is
known to break the ACK challenges in response to RST messages (section
3)
^ permalink raw reply
* Re: [PATCH] Passing sk_buff metadata information to user space in TUNTAP driver.
From: Maciej Żenczykowski @ 2013-08-19 20:49 UTC (permalink / raw)
To: Valas Valancius
Cc: Valas Valancius, David S. Miller, Eric Dumazet, Linux NetDev
In-Reply-To: <1376944177-20031-1-git-send-email-vytautas.valancius@gmail.com>
Acked-by: Maciej Żenczykowski <maze@google.com>
I've already reviewed / commented on previous versions of this patch
and am hoping for comments from a wider audience.
I'm hoping this relatively generic and easily extensible way of
exposing additional per-packet metadata to userspace catches on.
Something similar would also be useful for tcpdump (ie. raw packet sockets).
- Maciej
^ permalink raw reply
* Re: NAT stops forwarding ACKs after PMTU discovery
From: Christoph Paasch @ 2013-08-19 20:43 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Eric Dumazet, Corey Hickey, Linux Netdev List, netfilter-devel
In-Reply-To: <alpine.DEB.2.00.1308192207130.27869@blackhole.kfki.hu>
On 19/08/13 - 22:13:59, Jozsef Kadlecsik wrote:
> On Mon, 19 Aug 2013, Eric Dumazet wrote:
>
> > On Mon, 2013-08-19 at 15:49 +0200, Christoph Paasch wrote:
> >
> > > It's a TCP-patch, that interprets duplicate-acks with invalid SACK-blocks as
> > > duplicate acks in tcp_sock->sacked_out.
> >
> > Yeah, but here, this is conntrack who is blocking the thing.
> >
> > TCP receiver has no chance to 'fix' it.
> >
> > See conntrack is one of those buggy middle box as well.
> >
> > So if you want to properly handle this mess, you'll also have to fix
> > conntrack.
>
> I beg you pardon: why conntrack should be relaxed, when it is expected
> to do more strict TCP checkings (RFC5961, Section 5.).
There is no mention of SACK in this RFC.
The duplicate ACKs with invalid SACK-blocks are valid with respect to
RFC5961, Section 5.
Actually, no RFC says that dup-ACKs with invalid SACK-blocks should
be discarded.
Cheers,
Christoph
^ permalink raw reply
* Re: [PATCH net-next 3/3] net/mlx4_en: Fix handling of dma_map failure
From: Francois Romieu @ 2013-08-19 20:42 UTC (permalink / raw)
To: Amir Vadai; +Cc: David S. Miller, netdev
In-Reply-To: <1376894542-27854-4-git-send-email-amirv@mellanox.com>
Amir Vadai <amirv@mellanox.com> :
[...]
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> index 157bcd1..92d7097 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> @@ -673,6 +673,64 @@ netdev_tx_t mlx4_en_xmit(struct sk_buff *skb, struct net_device *dev)
> tx_info->skb = skb;
> tx_info->nr_txbb = nr_txbb;
>
> + if (lso_header_size)
> + data = ((void *)&tx_desc->lso + ALIGN(lso_header_size + 4,
> + DS_SIZE));
> + else
> + data = &tx_desc->data;
> +
> + /* valid only for none inline segments */
> + tx_info->data_offset = (void *)data - (void *)tx_desc;
> +
> + tx_info->linear = (lso_header_size < skb_headlen(skb) &&
> + !is_inline(skb, NULL)) ? 1 : 0;
> +
> + data += skb_shinfo(skb)->nr_frags + tx_info->linear - 1;
> +
> + if (is_inline(skb, &fragptr)) {
> + tx_info->inl = 1;
> + } else {
> + /* Map fragments */
> + for (i = skb_shinfo(skb)->nr_frags - 1; i >= 0; i--) {
> + frag = &skb_shinfo(skb)->frags[i];
> + dma = skb_frag_dma_map(priv->ddev, frag,
> + 0, skb_frag_size(frag),
> + DMA_TO_DEVICE);
> + if (dma_mapping_error(priv->ddev, dma)) {
goto err_unmap_frags;
You have a lot of huge scope variables. At least use these to hide
the 80 cols problems.
> + for (i++; i < skb_shinfo(skb)->nr_frags; i++) {
> + frag = &skb_shinfo(skb)->frags[i];
> + en_err(priv, "DMA mapping error\n");
> + dma_unmap_page(priv->ddev,
> + (dma_addr_t) be64_to_cpu(data[i].addr),
> + skb_frag_size(frag), PCI_DMA_TODEVICE);
> + }
> + goto tx_drop;
> + }
> +
> + data->addr = cpu_to_be64(dma);
> + data->lkey = cpu_to_be32(mdev->mr.key);
> + wmb();
> + data->byte_count = cpu_to_be32(skb_frag_size(frag));
> + --data;
> + }
> +
> + /* Map linear part */
> + if (tx_info->linear) {
> + u32 byte_count = skb_headlen(skb) - lso_header_size;
> + dma = dma_map_single(priv->ddev, skb->data +
> + lso_header_size, byte_count,
> + PCI_DMA_TODEVICE);
> + if (dma_mapping_error(priv->ddev, dma))
> + goto tx_drop;
(frags dma leak)
goto err_unmap_frags;
You may consider a local variable for 'priv->ddev' btw.
--
Ueimor
^ permalink raw reply
* [PATCH net] packet: restore packet statistics tp_packets to include drops
From: Willem de Bruijn @ 2013-08-19 20:40 UTC (permalink / raw)
To: davem, dborkman, netdev, sergei.shtylyov; +Cc: Willem de Bruijn
In-Reply-To: <5212625A.1090704@cogentembedded.com>
getsockopt PACKET_STATISTICS returns tp_packets + tp_drops. Commit
ee80fbf301 ("packet: account statistics only in tpacket_stats_u")
cleaned up the getsockopt PACKET_STATISTICS code.
This also changed semantics. Historically, tp_packets included
tp_drops on return. The commit removed the line that adds tp_drops
into tp_packets.
This patch reinstates the old semantics.
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
v2: incorporated commit summary by request. no code changes
---
net/packet/af_packet.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 6c53dd9..1fdf9ab 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -3215,9 +3215,11 @@ static int packet_getsockopt(struct socket *sock, int level, int optname,
if (po->tp_version == TPACKET_V3) {
lv = sizeof(struct tpacket_stats_v3);
+ st.stats3.tp_packets += st.stats3.tp_drops;
data = &st.stats3;
} else {
lv = sizeof(struct tpacket_stats);
+ st.stats1.tp_packets += st.stats1.tp_drops;
data = &st.stats1;
}
--
1.8.3
^ permalink raw reply related
* [PATCH] Fix stack corruption on some architectures
From: Daniel Gimpelevich @ 2013-08-19 20:37 UTC (permalink / raw)
To: Jan Dumon, Greg Kroah-Hartman, linux-usb, netdev, linux-kernel
There is no need to get an interface specification if we know it's the
wrong one; trivial change. The big thing, though, was explained in the
#mipslinux IRC channel:
[Mon 2013-08-19 12:28:21 PM PDT] <headless> guys, are you sure it's not "DMA off stack" case?
[Mon 2013-08-19 12:28:35 PM PDT] <headless> it's a known stack corruptor on non-coherent arches
[Mon 2013-08-19 12:31:48 PM PDT] <DonkeyHotei> headless: for usb/ehci?
[Mon 2013-08-19 12:34:11 PM PDT] <DonkeyHotei> headless: explain
[Mon 2013-08-19 12:35:38 PM PDT] <headless> usb_control_msg() (or other such func) should not use buffer on stack. DMA from/to stack is prohibited
[Mon 2013-08-19 12:35:58 PM PDT] <headless> and EHCI uses DMA on control xfers (as well as all the others)
Signed-off-by: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
---
drivers/net/usb/hso.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index cba1d46..86292e6 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -2816,13 +2816,16 @@ exit:
static int hso_get_config_data(struct usb_interface *interface)
{
struct usb_device *usbdev = interface_to_usbdev(interface);
- u8 config_data[17];
+ u8 *config_data = kmalloc(17, GFP_KERNEL);
u32 if_num = interface->altsetting->desc.bInterfaceNumber;
s32 result;
+ if (!config_data)
+ return -ENOMEM;
if (usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0),
0x86, 0xC0, 0, 0, config_data, 17,
USB_CTRL_SET_TIMEOUT) != 0x11) {
+ kfree(config_data);
return -EIO;
}
@@ -2873,6 +2876,7 @@ static int hso_get_config_data(struct usb_interface *interface)
if (config_data[16] & 0x1)
result |= HSO_INFO_CRC_BUG;
+ kfree(config_data);
return result;
}
@@ -2886,6 +2890,11 @@ static int hso_probe(struct usb_interface *interface,
struct hso_shared_int *shared_int;
struct hso_device *tmp_dev = NULL;
+ if (interface->cur_altsetting->desc.bInterfaceClass != 0xFF) {
+ dev_err(&interface->dev, "Not our interface\n");
+ return -ENODEV;
+ }
+
if_num = interface->altsetting->desc.bInterfaceNumber;
/* Get the interface/port specification from either driver_info or from
@@ -2895,10 +2904,6 @@ static int hso_probe(struct usb_interface *interface,
else
port_spec = hso_get_config_data(interface);
- if (interface->cur_altsetting->desc.bInterfaceClass != 0xFF) {
- dev_err(&interface->dev, "Not our interface\n");
- return -ENODEV;
- }
/* Check if we need to switch to alt interfaces prior to port
* configuration */
if (interface->num_altsetting > 1)
--
1.7.9.5
^ permalink raw reply related
* [PATCH] Passing sk_buff metadata information to user space in TUNTAP driver.
From: Valas Valancius @ 2013-08-19 20:29 UTC (permalink / raw)
To: Valas Valancius, David S. Miller
Cc: Eric Dumazet, Maciej Żenczykowski, netdev
From: Valas Valancius <valas@google.com>
This patch introduces an optional metadata header to TUNTAP driver to pass
sk_buff information to user space. The patch currently enables passing
of skb->mark field and allows for easy expansion to add more sk_buff
fields later.
Tested: Compiled, booted. Process 1: openend TAP interface, enabled metadata
header on that interface. Process 2: opened a socket, set fwmark with SO_MARK
sock option, send packets, observed mark to propagate in Process 1.
Change-Id: I5d00522e9c4d9c1b57b4f4ac55c419a85de35dae
---
drivers/net/tun.c | 64 ++++++++++++++++++++++++++++++++++++++++++++-
include/uapi/linux/if_tun.h | 7 +++++
2 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 978d865..f997d59 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -103,6 +103,15 @@ do { \
#define GOODCOPY_LEN 128
+/* Metadata header structure. */
+struct tun_meta_header {
+ /* struct sk_buff.mark */
+ int mark;
+};
+
+#define TUN_META_HDR_SZ sizeof(struct tun_meta_header)
+#define TUN_META_MARK_OFFSET offsetof(struct tun_meta_header, mark)
+
#define FLT_EXACT_COUNT 8
struct tap_filter {
unsigned int count; /* Number of addrs. Zero means disabled */
@@ -1227,6 +1236,20 @@ static ssize_t tun_put_user(struct tun_struct *tun,
total += tun->vnet_hdr_sz;
}
+ if (tun->flags & TUN_META_HDR) {
+ struct tun_meta_header meta = { 0 };
+ len -= TUN_META_HDR_SZ;
+ if (len < 0)
+ return -EINVAL;
+
+ meta.mark = skb->mark;
+
+ if (unlikely(memcpy_toiovecend(iv, (void *)&meta, total,
+ sizeof(meta))))
+ return -EFAULT;
+ total += TUN_META_HDR_SZ;
+ }
+
if (!vlan_tx_tag_present(skb)) {
len = min_t(int, skb->len, len);
} else {
@@ -1487,6 +1510,9 @@ static int tun_flags(struct tun_struct *tun)
if (tun->flags & TUN_PERSIST)
flags |= IFF_PERSIST;
+ if (tun->flags & TUN_META_HDR)
+ flags |= IFF_META_HDR;
+
return flags;
}
@@ -1666,6 +1692,11 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
else
tun->flags &= ~TUN_TAP_MQ;
+ if (ifr->ifr_flags & IFF_META_HDR)
+ tun->flags |= TUN_META_HDR;
+ else
+ tun->flags &= ~TUN_META_HDR;
+
/* Make sure persistent devices do not get stuck in
* xoff state.
*/
@@ -1815,6 +1846,8 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
kgid_t group;
int sndbuf;
int vnet_hdr_sz;
+ int tun_meta_param;
+ int tun_meta_value;
int ret;
if (cmd == TUNSETIFF || cmd == TUNSETQUEUE || _IOC_TYPE(cmd) == 0x89) {
@@ -1828,7 +1861,7 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
* This is needed because we never checked for invalid flags on
* TUNSETIFF. */
return put_user(IFF_TUN | IFF_TAP | IFF_NO_PI | IFF_ONE_QUEUE |
- IFF_VNET_HDR | IFF_MULTI_QUEUE,
+ IFF_VNET_HDR | IFF_MULTI_QUEUE | IFF_META_HDR,
(unsigned int __user*)argp);
} else if (cmd == TUNSETQUEUE)
return tun_set_queue(file, &ifr);
@@ -1996,6 +2029,35 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
tun->vnet_hdr_sz = vnet_hdr_sz;
break;
+ case TUNGETMETAPARAM:
+ if (copy_from_user(&tun_meta_param, argp,
+ sizeof(tun_meta_param))) {
+ ret = -EFAULT;
+ break;
+ }
+
+ ret = 0;
+ switch (tun_meta_param) {
+ case TUN_GET_META_HDR_SZ:
+ tun_meta_value = TUN_META_HDR_SZ;
+ break;
+
+ case TUN_GET_META_MARK_OFFSET:
+ tun_meta_value = TUN_META_MARK_OFFSET;
+ break;
+
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ if (!ret)
+ if (copy_to_user(argp, &tun_meta_value,
+ sizeof(tun_meta_value)))
+ ret = -EFAULT;
+ break;
+
+
case TUNATTACHFILTER:
/* Can be set only for TAPs */
ret = -EINVAL;
diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
index 1870ee2..26e6c9e 100644
--- a/include/uapi/linux/if_tun.h
+++ b/include/uapi/linux/if_tun.h
@@ -36,6 +36,7 @@
#define TUN_PERSIST 0x0100
#define TUN_VNET_HDR 0x0200
#define TUN_TAP_MQ 0x0400
+#define TUN_META_HDR 0x0800
/* Ioctl defines */
#define TUNSETNOCSUM _IOW('T', 200, int)
@@ -56,10 +57,12 @@
#define TUNGETVNETHDRSZ _IOR('T', 215, int)
#define TUNSETVNETHDRSZ _IOW('T', 216, int)
#define TUNSETQUEUE _IOW('T', 217, int)
+#define TUNGETMETAPARAM _IOR('T', 218, int)
/* TUNSETIFF ifr flags */
#define IFF_TUN 0x0001
#define IFF_TAP 0x0002
+#define IFF_META_HDR 0x0004
#define IFF_NO_PI 0x1000
/* This flag has no real effect */
#define IFF_ONE_QUEUE 0x2000
@@ -103,4 +106,8 @@ struct tun_filter {
__u8 addr[0][ETH_ALEN];
};
+/* TUNGETMETAPARAM metadata header request types. */
+#define TUN_GET_META_HDR_SZ 0
+#define TUN_GET_META_MARK_OFFSET 1
+
#endif /* _UAPI__IF_TUN_H */
--
1.8.3
^ permalink raw reply related
* Re: [PATCHv2] net: cpsw: Add support for wake-on-lan for cpsw
From: Francois Romieu @ 2013-08-19 20:15 UTC (permalink / raw)
To: ujhelyi.m; +Cc: davem, mugunthanvnm, netdev, linux-kernel
In-Reply-To: <1376910358-19882-1-git-send-email-ujhelyi.m@gmail.com>
ujhelyi.m@gmail.com <ujhelyi.m@gmail.com> :
[...]
> Some phy's can be configured to enable wake on lan (e.g. at803x or marvell 88E1318S).
> There is no way how to enable wol on CPSW with such connected phys. This patch
> adds this support. It is provided by calling the phy's related code.
>
> Tested on board with at8030x connected phy. Wol interrupt line is
> connected to GPIO0 on am335x.
This patch adds a feature. It isn't a bugfix. It should thus target
'net-next', not 'net' (it does not apply to net-next as of 2ff1cf12c9 btw).
>
> Signed-off-by: Matus Ujhelyi <ujhelyi.m@gmail.com>
> ---
> drivers/net/ethernet/ti/cpsw.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index 22a7a43..fe8d973 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -1416,6 +1416,27 @@ static int cpsw_set_settings(struct net_device *ndev, struct ethtool_cmd *ecmd)
> return -EOPNOTSUPP;
> }
>
> +static void cpsw_get_wol(struct net_device *ndev, struct ethtool_wolinfo *wol)
> +{
> + struct cpsw_priv *priv = netdev_priv(ndev);
> + int slave_no = cpsw_slave_index(priv);
> + wol->supported = 0;
Variable declarations and code should be separated: please add an empty
line.
> + wol->wolopts = 0;
> + if (priv->slaves[slave_no].phy)
> + phy_ethtool_get_wol(priv->slaves[slave_no].phy, wol);
> +
> +}
Useless empty line.
> +
> +static int cpsw_set_wol(struct net_device *ndev, struct ethtool_wolinfo *wol)
> +{
> + struct cpsw_priv *priv = netdev_priv(ndev);
> + int slave_no = cpsw_slave_index(priv);
> + if (priv->slaves[slave_no].phy)
Variable declarations and code should be separated: please add an empty
line.
> + return phy_ethtool_set_wol(priv->slaves[slave_no].phy, wol);
> + else
> + return -EOPNOTSUPP;
> +}
> +
> static const struct ethtool_ops cpsw_ethtool_ops = {
> .get_drvinfo = cpsw_get_drvinfo,
> .get_msglevel = cpsw_get_msglevel,
> @@ -1426,6 +1447,8 @@ static const struct ethtool_ops cpsw_ethtool_ops = {
> .set_settings = cpsw_set_settings,
> .get_coalesce = cpsw_get_coalesce,
^^^ tab
> .set_coalesce = cpsw_set_coalesce,
^^^ tab
> + .get_wol = cpsw_get_wol,
^^^^^^^^ spaces, please use tabs.
> + .set_wol = cpsw_set_wol,
^^^^^^^^ spaces, please use tabs.
--
Ueimor
^ 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