* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Hannes Frederic Sowa @ 2013-10-06 15:13 UTC (permalink / raw)
To: Oussama Ghorbel
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <CABfLueFYZkzpEpDJ7YcHJaXfm-=QcgnL3-Es8gybea2cAacQQw@mail.gmail.com>
On Sun, Oct 06, 2013 at 03:42:15PM +0100, Oussama Ghorbel wrote:
> The initialization in ip6gre_tnl_link_config is done as the following:
> static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
> {
> ...
> int addend = sizeof(struct ipv6hdr) + 4;
> ...
> /* Precalculate GRE options length */
> if (t->parms.o_flags&(GRE_CSUM|GRE_KEY|GRE_SEQ)) {
> if (t->parms.o_flags&GRE_CSUM)
> addend += 4;
> if (t->parms.o_flags&GRE_KEY)
> addend += 4;
> if (t->parms.o_flags&GRE_SEQ)
> addend += 4;
> }
> ...
> dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
> ...
> t->hlen = addend;
> ..
> }
>
> Unless they are other reasons, the hard_header_len is taken into
> account the GRE_KEY, GRE_SEQ ..
But only if a new route is found. The hard_header_len reinitialization is
guarded by a (rt == NULL). We may have not found one on boot up.
> > To make this correct we would have to refactor the usage of the variables a
> > bit as is done in ipv4/ip_tunnel.c. The safest thing would be to leave this
> > check as-is currently although we exclude some allowed mtus.
> >
> > Perhaps you want to take a look how to achieve that? ;)
> >
> Why not, consistency is good ...
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Oussama Ghorbel @ 2013-10-06 15:36 UTC (permalink / raw)
To: Oussama Ghorbel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <20131006151351.GB9295@order.stressinduktion.org>
On Sun, Oct 6, 2013 at 4:13 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Sun, Oct 06, 2013 at 03:42:15PM +0100, Oussama Ghorbel wrote:
>> The initialization in ip6gre_tnl_link_config is done as the following:
>> static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
>> {
>> ...
>> int addend = sizeof(struct ipv6hdr) + 4;
>> ...
>> /* Precalculate GRE options length */
>> if (t->parms.o_flags&(GRE_CSUM|GRE_KEY|GRE_SEQ)) {
>> if (t->parms.o_flags&GRE_CSUM)
>> addend += 4;
>> if (t->parms.o_flags&GRE_KEY)
>> addend += 4;
>> if (t->parms.o_flags&GRE_SEQ)
>> addend += 4;
>> }
>> ...
>> dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
>> ...
>> t->hlen = addend;
>> ..
>> }
>>
>> Unless they are other reasons, the hard_header_len is taken into
>> account the GRE_KEY, GRE_SEQ ..
>
> But only if a new route is found. The hard_header_len reinitialization is
> guarded by a (rt == NULL). We may have not found one on boot up.
>
In that case the function will make a return and hlen will be zero.
Subtracting hlen in ip6gre_tunnel_change_mtu has no effect ...
>> > To make this correct we would have to refactor the usage of the variables a
>> > bit as is done in ipv4/ip_tunnel.c. The safest thing would be to leave this
>> > check as-is currently although we exclude some allowed mtus.
>> >
>> > Perhaps you want to take a look how to achieve that? ;)
>> >
>> Why not, consistency is good ...
>
> Thanks,
>
> Hannes
>
Thanks,
Oussama
^ permalink raw reply
* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Hannes Frederic Sowa @ 2013-10-06 16:19 UTC (permalink / raw)
To: Oussama Ghorbel
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <CABfLueGefWM6m6h44yAMBo7=BMUcA=OvcFVYka06QvsxXUAJtw@mail.gmail.com>
On Sun, Oct 06, 2013 at 04:36:56PM +0100, Oussama Ghorbel wrote:
> On Sun, Oct 6, 2013 at 4:13 PM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > On Sun, Oct 06, 2013 at 03:42:15PM +0100, Oussama Ghorbel wrote:
> >> The initialization in ip6gre_tnl_link_config is done as the following:
> >> static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
> >> {
> >> ...
> >> int addend = sizeof(struct ipv6hdr) + 4;
> >> ...
> >> /* Precalculate GRE options length */
> >> if (t->parms.o_flags&(GRE_CSUM|GRE_KEY|GRE_SEQ)) {
> >> if (t->parms.o_flags&GRE_CSUM)
> >> addend += 4;
> >> if (t->parms.o_flags&GRE_KEY)
> >> addend += 4;
> >> if (t->parms.o_flags&GRE_SEQ)
> >> addend += 4;
> >> }
> >> ...
> >> dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
> >> ...
> >> t->hlen = addend;
> >> ..
> >> }
> >>
> >> Unless they are other reasons, the hard_header_len is taken into
> >> account the GRE_KEY, GRE_SEQ ..
> >
> > But only if a new route is found. The hard_header_len reinitialization is
> > guarded by a (rt == NULL). We may have not found one on boot up.
> >
> In that case the function will make a return and hlen will be zero.
> Subtracting hlen in ip6gre_tunnel_change_mtu has no effect ...
Oh yes, somehow I missed that.
We depend on t->hlen when pushing the gre header onto the skb. t->hlen == 0
should never be the case because we assume t->hlen > sizeof(struct ipv6_hdr).
^ permalink raw reply
* Re: [PATCH] net: secure_seq: Move net_secret_init() definition into CONFIG_IPV6 if block
From: Fabio Estevam @ 2013-10-06 16:29 UTC (permalink / raw)
To: Olof Johansson
Cc: David Miller, edumazet, hannes, Network Development,
Fabio Estevam
In-Reply-To: <CAOesGMi6LuP7uVJnHOgpG2RK2Q0R3bJ4kG1ZY3=b-W3k0YhnBg@mail.gmail.com>
Hi Olof,
On Sun, Oct 6, 2013 at 2:25 AM, Olof Johansson <olof@lixom.net> wrote:
> You get it if you have CONFIG_NET enabled, but CONFIG_INET off. We
> seem to have a few defconfigs on arm that has that setting, likely
> because they lack native network interfaces but need local unix
> sockets. Or whatever. But that's how you hit it.
>
> Steps to reproduce, even with ARCH=sparc:
>
> make allnoconfig
> edit .config, set CONFIG_NET=y
> yes "" | make oldconfig
> make
Yes, I fixed the commit log and patch in v2.
Regards,
Fabio Estevam
^ permalink raw reply
* Re: [PATCH v4 net-next] fix unsafe set_memory_rw from softirq
From: Eric Dumazet @ 2013-10-06 16:56 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, Daniel Borkmann, Eric Dumazet, Heiko Carstens,
linux-arm-kernel, linuxppc-dev, linux-s390, netdev
In-Reply-To: <1380870846-3357-1-git-send-email-ast@plumgrid.com>
On Fri, 2013-10-04 at 00:14 -0700, Alexei Starovoitov wrote:
> on x86 system with net.core.bpf_jit_enable = 1
> cannot reuse jited filter memory, since it's readonly,
> so use original bpf insns memory to hold work_struct
>
> defer kfree of sk_filter until jit completed freeing
>
> tested on x86_64 and i386
>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next] net: Separate the close_list and the unreg_list
From: Francesco Ruggeri @ 2013-10-06 17:13 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: netdev
>
> Can you verify this incremental change fixes it for you?
>
Sure, I will.
Thanks,
Francesco
^ permalink raw reply
* Re: [PATCH] usbnet: smsc95xx: Add device tree input for MAC address
From: Dan Murphy @ 2013-10-06 17:31 UTC (permalink / raw)
To: Ming Lei
Cc: Steve Glendinning, Network Development, Linux Kernel Mailing List,
linux-usb, mugunthanvnm-l0cyMroinI0
In-Reply-To: <CACVXFVOVMvP=3y9h2Jrqn2sBQdKOZtrhQDAFYkdHKXFgQj=d0Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 10/06/2013 10:05 AM, Ming Lei wrote:
> On Sat, Oct 5, 2013 at 2:25 AM, Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org> wrote:
>> If the smsc95xx does not have a valid MAC address stored within
>> the eeprom then a random number is generated. The MAC can also
>> be set by uBoot but the smsc95xx does not have a way to read this.
>>
>> Create the binding for the smsc95xx so that uBoot can set the MAC
>> and the code can retrieve the MAC from the modified DTB file.
> Suppose there are two smsc95xx usbnet devices connected to usb bus, and
> one is built-in, another is hotplug device, can your patch handle the situation
> correctly?
Look at this line in the patch below
sprintf(of_name, "%s%i", SMSC95XX_OF_NAME, dev->udev->dev.id);
I am appending the dev ID of the device to the of_name here. As long as init_mac_address is called, the dev.id and the uBoot
entry match then yes.
>> Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/net/smsc95xx.txt | 17 ++++++++++++++
>> drivers/net/usb/smsc95xx.c | 24 ++++++++++++++++++++
>> 2 files changed, 41 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/smsc95xx.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/smsc95xx.txt b/Documentation/devicetree/bindings/net/smsc95xx.txt
>> new file mode 100644
>> index 0000000..4c37280
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/smsc95xx.txt
>> @@ -0,0 +1,17 @@
>> +* Smart Mixed-Signal Connectivity (SMSC) 95xx Controller
>> +
>> +Required properties:
>> +None
>> +
>> +Optional properties:
>> +- mac-address - Read the mac address that was stored by uBoot
>> +- local-address - Read the mac address that was stored by uBoot
>> +- address - Read the mac address that was stored by uBoot
>> +
>> +Examples:
>> +
>> +smsc0: smsc95xx@0 {
>> + /* Filled in by U-Boot */
>> + mac-address = [ 00 00 00 00 00 00 ];
>> +};
>> +
>> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
>> index 3f38ba8..baee0bd 100644
>> --- a/drivers/net/usb/smsc95xx.c
>> +++ b/drivers/net/usb/smsc95xx.c
>> @@ -31,6 +31,9 @@
>> #include <linux/crc32.h>
>> #include <linux/usb/usbnet.h>
>> #include <linux/slab.h>
>> +#include <linux/of.h>
>> +#include <linux/of_net.h>
>> +
>> #include "smsc95xx.h"
>>
>> #define SMSC_CHIPNAME "smsc95xx"
>> @@ -62,6 +65,8 @@
>> #define SUSPEND_ALLMODES (SUSPEND_SUSPEND0 | SUSPEND_SUSPEND1 | \
>> SUSPEND_SUSPEND2 | SUSPEND_SUSPEND3)
>>
>> +#define SMSC95XX_OF_NAME "/smsc95xx@"
>> +
>> struct smsc95xx_priv {
>> u32 mac_cr;
>> u32 hash_hi;
>> @@ -767,6 +772,25 @@ static int smsc95xx_ioctl(struct net_device *netdev, struct ifreq *rq, int cmd)
>>
>> static void smsc95xx_init_mac_address(struct usbnet *dev)
>> {
>> +
>> +#ifdef CONFIG_OF
>> + struct device_node *ap;
>> + const char *mac = NULL;
>> + char *of_name = SMSC95XX_OF_NAME;
>> +
>> + sprintf(of_name, "%s%i", SMSC95XX_OF_NAME, dev->udev->dev.id);
>> + ap = of_find_node_by_path(of_name);
>> + if (ap) {
>> + mac = of_get_mac_address(ap);
>> + if (is_valid_ether_addr(mac)) {
>> + /* Device tree has a mac for this so use that */
>> + memcpy(dev->net->dev_addr, mac, ETH_ALEN);
>> + netif_dbg(dev, ifup, dev->net, "MAC address read from DTB\n");
>> + return;
>> + }
>> + }
>> +#endif
>> +
>> /* try reading mac address from EEPROM */
>> if (smsc95xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
>> dev->net->dev_addr) == 0) {
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
> Thanks,
--
------------------
Dan Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* [PATCH] tun: don't look at current when non-blocking
From: Michael S. Tsirkin @ 2013-10-06 18:25 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: David S. Miller, Jason Wang, Eric Dumazet, Pavel Emelyanov
We play with a wait queue even if socket is
non blocking. This is an obvious waste.
Besides, it will prevent calling the non blocking
variant when current is not valid.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
drivers/net/tun.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 807815f..7cb105c 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1293,7 +1293,8 @@ static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
if (unlikely(!noblock))
add_wait_queue(&tfile->wq.wait, &wait);
while (len) {
- current->state = TASK_INTERRUPTIBLE;
+ if (unlikely(!noblock))
+ current->state = TASK_INTERRUPTIBLE;
/* Read frames from the queue */
if (!(skb = skb_dequeue(&tfile->socket.sk->sk_receive_queue))) {
@@ -1320,9 +1321,10 @@ static ssize_t tun_do_read(struct tun_struct *tun, struct tun_file *tfile,
break;
}
- current->state = TASK_RUNNING;
- if (unlikely(!noblock))
+ if (unlikely(!noblock)) {
+ current->state = TASK_RUNNING;
remove_wait_queue(&tfile->wq.wait, &wait);
+ }
return ret;
}
--
MST
^ permalink raw reply related
* [PATCH] static_key: WARN on usage before jump_label_init was called
From: Hannes Frederic Sowa @ 2013-10-06 18:29 UTC (permalink / raw)
To: Steven Rostedt, netdev, linux-kernel, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Jason Baron, Peter Zijlstra,
Eric Dumazet, andi @ firstfloor. org David S. Miller, x86
In-Reply-To: <20131006001247.GB25076@order.stressinduktion.org>
On Sun, Oct 06, 2013 at 02:12:47AM +0200, Hannes Frederic Sowa wrote:
> On Sat, Oct 05, 2013 at 08:05:58PM -0400, Steven Rostedt wrote:
> > > if (type == JUMP_LABEL_ENABLE) {
> > > - /*
> > > - * We are enabling this jump label. If it is not a nop
> > > - * then something must have gone wrong.
> > > - */
> > > - if (unlikely(memcmp((void *)entry->code, ideal_nop, 5) != 0))
> > > - bug_at((void *)entry->code, __LINE__);
> > > + if (init) {
> > > + /*
> > > + * Jump label is enabled for the first time.
> > > + * So we expect a default_nop...
> > > + */
> > > + if (unlikely(memcmp((void *)entry->code, default_nop, 5)
> > > + != 0))
> > > + bug_at((void *)entry->code, __LINE__);
> > > + } else {
> > > + /*
> > > + * ...otherwise expect an ideal_nop. Otherwise
> > > + * something went horribly wrong.
> > > + */
> > > + if (unlikely(memcmp((void *)entry->code, ideal_nop, 5)
> > > + != 0))
> > > + bug_at((void *)entry->code, __LINE__);
> > > + }
> >
> > I don't know if I like this change. This is similar to a bug we had
> > with the Xen folks, where they didn't realize that jump labels are not
> > suppose to be used (or set) before jump_label_init() is called.
> >
> > I'll have to take a deeper look at this on Monday.
>
> Yes, I understand and saw the commit to call jump_label_init
> earlier. Maybe the default could be to insert illegal instructions by
> default if we try to replace them with nops or branches afterwards anyway.
This would not help, but maybe someting like this patch. Andi Kleen
also recently posted something similar, I cleaned it up a bit.
[PATCH] static_key: WARN on usage before jump_label_init was called
Based on a patch from Andi Kleen.
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/linux/jump_label.h | 11 +++++++++++
include/linux/jump_label_ratelimit.h | 2 ++
kernel/jump_label.c | 5 +++++
lib/Makefile | 2 +-
lib/jump_label_initialized.c | 6 ++++++
5 files changed, 25 insertions(+), 1 deletion(-)
create mode 100644 lib/jump_label_initialized.c
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index a507907..ed3a4bd 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -48,6 +48,14 @@
#include <linux/types.h>
#include <linux/compiler.h>
+#include <linux/bug.h>
+
+extern bool static_key_initialized;
+
+#define STATIC_KEY_CHECK_USE() do { \
+ WARN(!static_key_initialized, "%s used before call to jump_label_init", \
+ __func__); \
+} while (0)
#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
@@ -128,6 +136,7 @@ struct static_key {
static __always_inline void jump_label_init(void)
{
+ static_key_initialized = true;
}
static __always_inline bool static_key_false(struct static_key *key)
@@ -146,11 +155,13 @@ static __always_inline bool static_key_true(struct static_key *key)
static inline void static_key_slow_inc(struct static_key *key)
{
+ STATIC_KEY_CHECK_USE();
atomic_inc(&key->enabled);
}
static inline void static_key_slow_dec(struct static_key *key)
{
+ STATIC_KEY_CHECK_USE();
atomic_dec(&key->enabled);
}
diff --git a/include/linux/jump_label_ratelimit.h b/include/linux/jump_label_ratelimit.h
index 1137883..089f70f 100644
--- a/include/linux/jump_label_ratelimit.h
+++ b/include/linux/jump_label_ratelimit.h
@@ -23,12 +23,14 @@ struct static_key_deferred {
};
static inline void static_key_slow_dec_deferred(struct static_key_deferred *key)
{
+ STATIC_KEY_CHECK_USE();
static_key_slow_dec(&key->key);
}
static inline void
jump_label_rate_limit(struct static_key_deferred *key,
unsigned long rl)
{
+ STATIC_KEY_CHECK_USE();
}
#endif /* HAVE_JUMP_LABEL */
#endif /* _LINUX_JUMP_LABEL_RATELIMIT_H */
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 297a924..9019f15 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -58,6 +58,7 @@ static void jump_label_update(struct static_key *key, int enable);
void static_key_slow_inc(struct static_key *key)
{
+ STATIC_KEY_CHECK_USE();
if (atomic_inc_not_zero(&key->enabled))
return;
@@ -103,12 +104,14 @@ static void jump_label_update_timeout(struct work_struct *work)
void static_key_slow_dec(struct static_key *key)
{
+ STATIC_KEY_CHECK_USE();
__static_key_slow_dec(key, 0, NULL);
}
EXPORT_SYMBOL_GPL(static_key_slow_dec);
void static_key_slow_dec_deferred(struct static_key_deferred *key)
{
+ STATIC_KEY_CHECK_USE();
__static_key_slow_dec(&key->key, key->timeout, &key->work);
}
EXPORT_SYMBOL_GPL(static_key_slow_dec_deferred);
@@ -116,6 +119,7 @@ EXPORT_SYMBOL_GPL(static_key_slow_dec_deferred);
void jump_label_rate_limit(struct static_key_deferred *key,
unsigned long rl)
{
+ STATIC_KEY_CHECK_USE();
key->timeout = rl;
INIT_DELAYED_WORK(&key->work, jump_label_update_timeout);
}
@@ -212,6 +216,7 @@ void __init jump_label_init(void)
key->next = NULL;
#endif
}
+ static_key_initialized = true;
jump_label_unlock();
}
diff --git a/lib/Makefile b/lib/Makefile
index f3bb2cb..7f48ddc 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -26,7 +26,7 @@ obj-y += bcd.o div64.o sort.o parser.o halfmd4.o debug_locks.o random32.o \
bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \
gcd.o lcm.o list_sort.o uuid.o flex_array.o iovec.o clz_ctz.o \
bsearch.o find_last_bit.o find_next_bit.o llist.o memweight.o kfifo.o \
- percpu_ida.o
+ percpu_ida.o jump_label_initialized.o
obj-y += string_helpers.o
obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o
obj-y += kstrtox.o
diff --git a/lib/jump_label_initialized.c b/lib/jump_label_initialized.c
new file mode 100644
index 0000000..a668a40
--- /dev/null
+++ b/lib/jump_label_initialized.c
@@ -0,0 +1,6 @@
+#include <linux/types.h>
+#include <linux/cache.h>
+
+bool static_key_initialized __read_mostly = false;
+EXPORT_SYMBOL_GPL(static_key_initialized);
+
--
1.8.3.1
^ permalink raw reply related
* CONTACT FEDEX EXPRESS COURIER SERVICE FOR YOUR PACKAGE
From: 019 @ 2013-10-06 18:52 UTC (permalink / raw)
To: Recipients
Dear Friend,
I cashed your shell oil company's compensation check of $1.5Million USD which has been with me for a very long time to avoid expiration,contact fedex Courier service with the below info for your fund consignment delivery,Note that security and insurance fees has been paid,all you will pay them is their delivery fees 150 USD only,
Director:Dr.Dennis Meijs,
E-mail ( fedexcourierserviii@yahoo.fr )
Tel: +9178-3835-5947
Please make sure you send this needed info to the Director Dr.Dennis Meijs
with the E-mail given to you to avoid wrong delivery of your consignment
Full Name.....................
Country...............
Home address.................
Home & Mobile phone numbers......
Your picture..........
Call Dr Dennis Meijs on phone Tel:+9178-3835-5947 as soon as you send email to him because your call would facilitate the immediate attention to you due to his tight delivery schedule.
I waiting for your urgent response
Remain blessed
Best Regards.
Barrister.Don Philip
^ permalink raw reply
* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Oussama Ghorbel @ 2013-10-06 19:18 UTC (permalink / raw)
To: Oussama Ghorbel, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <20131006161910.GC9295@order.stressinduktion.org>
Yes, to summarize, the idea of this patch was to fix the incoherence
in the condition of ip6gre_tunnel_change_mtu function
if (new_mtu < 68 ||
new_mtu > 0xFFF8 - dev->hard_header_len - tunnel->hlen)
>From the ip6gre_tnl_link_config function we can see that:
The variable addend is equal the ipv6 header + gre header (including
the gre options)
On the other hand hard_header_len equal to the header of the lower
layer + addend.
So the quantity - (dev->hard_header_len + tunnel->hlen) equals - (eth
header + ipv6 header + gre header + ipv6 header + gre header) which by
no means this would represent anything! (I've just taken ipv6 over
ethernet as example)
As we have seen there is another approach to fix this issue is to
re-factor the hlen to hold only the length of gre as it's done for
ipv4 gre, however the solution provided in the patch seems to be
regression risk-less.
Although the value hold by hlen is not coherent with the variable name
nor with ipv4, I think there is an advantage of the current approach
of ipv6 hlen over ipv4 hlen, because we save the calculation of ipv6
header each time. Ex:
In ipv4 gre and in the function ipgre_header:
iph = (struct iphdr *)skb_push(skb, t->hlen + sizeof(*iph));
In ipv6 and in the function ip6gre_header
ipv6h = (struct ipv6hdr *)skb_push(skb, t->hlen);
Thanks,
Oussama
On Sun, Oct 6, 2013 at 5:19 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Sun, Oct 06, 2013 at 04:36:56PM +0100, Oussama Ghorbel wrote:
>> On Sun, Oct 6, 2013 at 4:13 PM, Hannes Frederic Sowa
>> <hannes@stressinduktion.org> wrote:
>> > On Sun, Oct 06, 2013 at 03:42:15PM +0100, Oussama Ghorbel wrote:
>> >> The initialization in ip6gre_tnl_link_config is done as the following:
>> >> static void ip6gre_tnl_link_config(struct ip6_tnl *t, int set_mtu)
>> >> {
>> >> ...
>> >> int addend = sizeof(struct ipv6hdr) + 4;
>> >> ...
>> >> /* Precalculate GRE options length */
>> >> if (t->parms.o_flags&(GRE_CSUM|GRE_KEY|GRE_SEQ)) {
>> >> if (t->parms.o_flags&GRE_CSUM)
>> >> addend += 4;
>> >> if (t->parms.o_flags&GRE_KEY)
>> >> addend += 4;
>> >> if (t->parms.o_flags&GRE_SEQ)
>> >> addend += 4;
>> >> }
>> >> ...
>> >> dev->hard_header_len = rt->dst.dev->hard_header_len + addend;
>> >> ...
>> >> t->hlen = addend;
>> >> ..
>> >> }
>> >>
>> >> Unless they are other reasons, the hard_header_len is taken into
>> >> account the GRE_KEY, GRE_SEQ ..
>> >
>> > But only if a new route is found. The hard_header_len reinitialization is
>> > guarded by a (rt == NULL). We may have not found one on boot up.
>> >
>> In that case the function will make a return and hlen will be zero.
>> Subtracting hlen in ip6gre_tunnel_change_mtu has no effect ...
>
> Oh yes, somehow I missed that.
>
> We depend on t->hlen when pushing the gre header onto the skb. t->hlen == 0
> should never be the case because we assume t->hlen > sizeof(struct ipv6_hdr).
>
^ permalink raw reply
* VERY URGENT..!
From: Mr. M. Barlow @ 2013-10-06 20:30 UTC (permalink / raw)
To: Recipients
Hello, I am Mr. M. Barlow from Paris, France. I have been advised to contact you regarding my business investment in your country. For urgent response and more details, kindly get back to me via this E-mail: bc82022@gmail.com or Telephone number below. Thank you as I wait for your response.
Mr. M. Barlow.
+33-753-194-496
Sent from Orange Wireless BlackBerry Smartphone, France.
^ permalink raw reply
* Re: [PATCH 0/4] connector fixes
From: Рустафа Джамурахметов @ 2013-10-06 20:46 UTC (permalink / raw)
To: David Miller, minipli@googlemail.com; +Cc: netdev@vger.kernel.org
In-Reply-To: <20131002.160430.1701387005902696709.davem@davemloft.net>
03.10.2013, 00:04, "David Miller" <davem@davemloft.net>:
> From: Mathias Krause <minipli@googlemail.com>
> Date: Mon, 30 Sep 2013 22:03:05 +0200
>
>> This series fixes a few netlink related issues of the connector interface.
>>
>> The first two patches are bug fixes. The last two are cleanups.
>>
>> Please apply!
>
> Series applied and first two patches queued up for -stable, thanks.
Thank you.
^ permalink raw reply
* [PATCH] net: af802154: Fix wrong structure declaration
From: Guenter Roeck @ 2013-10-06 21:44 UTC (permalink / raw)
To: Alexander Smirnov, Dmitry Eremin-Solenikov
Cc: David S. Miller, netdev, linux-zigbee-devel, Guenter Roeck
net_devce doesn't exist.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
net/ieee802154/af802154.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ieee802154/af802154.h b/net/ieee802154/af802154.h
index b1ec525..62f5f63 100644
--- a/net/ieee802154/af802154.h
+++ b/net/ieee802154/af802154.h
@@ -25,7 +25,7 @@
#define AF802154_H
struct sk_buff;
-struct net_devce;
+struct net_device;
extern struct proto ieee802154_raw_prot;
extern struct proto ieee802154_dgram_prot;
void ieee802154_raw_deliver(struct net_device *dev, struct sk_buff *skb);
--
1.7.9.7
^ permalink raw reply related
* Re: [PATCH] net: af802154: Fix wrong structure declaration
From: Joe Perches @ 2013-10-06 22:20 UTC (permalink / raw)
To: Guenter Roeck
Cc: Dmitry, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
David S. Miller
In-Reply-To: <1381095841-15031-1-git-send-email-linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
On Sun, 2013-10-06 at 14:44 -0700, Guenter Roeck wrote:
> net_devce doesn't exist.
[]
> diff --git a/net/ieee802154/af802154.h b/net/ieee802154/af802154.h
[]
> @@ -25,7 +25,7 @@
> #define AF802154_H
>
> struct sk_buff;
> -struct net_devce;
> +struct net_device;
That argues more for deletion than correction.
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
^ permalink raw reply
* Re: [PATCH] net: af802154: Fix wrong structure declaration
From: Guenter Roeck @ 2013-10-06 23:18 UTC (permalink / raw)
To: Joe Perches
Cc: Alexander Smirnov, Dmitry Eremin-Solenikov, David S. Miller,
netdev, linux-zigbee-devel
In-Reply-To: <1381098047.2081.169.camel@joe-AO722>
On 10/06/2013 03:20 PM, Joe Perches wrote:
> On Sun, 2013-10-06 at 14:44 -0700, Guenter Roeck wrote:
>> net_devce doesn't exist.
> []
>> diff --git a/net/ieee802154/af802154.h b/net/ieee802154/af802154.h
> []
>> @@ -25,7 +25,7 @@
>> #define AF802154_H
>>
>> struct sk_buff;
>> -struct net_devce;
>> +struct net_device;
>
> That argues more for deletion than correction.
>
I thought the idea was to ensure that every structure is declared.
In this case it appears that the structure happens to be declared
in other include files, so we are lucky. On the other side, if so,
"struct proto", "struct net" and "struct ieee802154_addr" should
probably be declared as well ...
Ultimately, I don't really care one way or another. I just happened
to stumble over it. Fine with me to remove it. Maybe the maintainers
should decide what if anything to do.
Guenter
^ permalink raw reply
* Re: [PATCH net-next] xen-netback: fix xenvif_count_skb_slots()
From: Matt Wilson @ 2013-10-07 0:06 UTC (permalink / raw)
To: Paul Durrant
Cc: xen-devel, netdev, Xi Xiong, Matt Wilson, Annie Li, Wei Liu,
Ian Campbell, Simon Graham
In-Reply-To: <1380903983-27429-1-git-send-email-paul.durrant@citrix.com>
On Fri, Oct 04, 2013 at 05:26:23PM +0100, Paul Durrant wrote:
> Commit 4f0581d25827d5e864bcf07b05d73d0d12a20a5c introduced an error into
> xenvif_count_skb_slots() for skbs with a linear area spanning a page
> boundary. The alignment of skb->data needs to be taken into account, not
> just the head length. This patch fixes the issue by dry-running the code
> from xenvif_gop_skb() (and adjusting the comment above the function to note
> that).
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> Cc: Xi Xiong <xixiong@amazon.com>
> Cc: Matt Wilson <msw@amazon.com>
> Cc: Annie Li <annie.li@oracle.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <Ian.Campbell@citrix.com>
Paul, can you reconcile this change with the one made by Simon in cs
8f985b4f7a5394c8f8725a5109451a541ddb9eea?
--msw
> ---
> drivers/net/xen-netback/netback.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index d0b0feb..6f680f4 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -223,15 +223,28 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
> /*
> * Figure out how many ring slots we're going to need to send @skb to
> * the guest. This function is essentially a dry run of
> - * xenvif_gop_frag_copy.
> + * xenvif_gop_skb.
> */
> unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
> {
> + unsigned char *data;
> unsigned int count;
> int i, copy_off;
> struct skb_cb_overlay *sco;
>
> - count = DIV_ROUND_UP(skb_headlen(skb), PAGE_SIZE);
> + count = 0;
> +
> + data = skb->data;
> + while (data < skb_tail_pointer(skb)) {
> + unsigned int offset = offset_in_page(data);
> + unsigned int len = PAGE_SIZE - offset;
> +
> + if (data + len > skb_tail_pointer(skb))
> + len = skb_tail_pointer(skb) - data;
> +
> + count++;
> + data += len;
> + }
>
> copy_off = skb_headlen(skb) % PAGE_SIZE;
>
^ permalink raw reply
* Re: [PATCH net-next] xen-netback: fix xenvif_count_skb_slots()
From: Matt Wilson @ 2013-10-07 0:07 UTC (permalink / raw)
To: Paul Durrant
Cc: xen-devel, netdev, Xi Xiong, Matt Wilson, Annie Li, Wei Liu,
Ian Campbell, Simon Graham
In-Reply-To: <20131007000652.GA5970@u109add4315675089e695.ant.amazon.com>
On Sun, Oct 06, 2013 at 05:06:52PM -0700, Matt Wilson wrote:
> On Fri, Oct 04, 2013 at 05:26:23PM +0100, Paul Durrant wrote:
> > Commit 4f0581d25827d5e864bcf07b05d73d0d12a20a5c introduced an error into
> > xenvif_count_skb_slots() for skbs with a linear area spanning a page
> > boundary. The alignment of skb->data needs to be taken into account, not
> > just the head length. This patch fixes the issue by dry-running the code
> > from xenvif_gop_skb() (and adjusting the comment above the function to note
> > that).
> >
> > Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> > Cc: Xi Xiong <xixiong@amazon.com>
> > Cc: Matt Wilson <msw@amazon.com>
> > Cc: Annie Li <annie.li@oracle.com>
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > Cc: Ian Campbell <Ian.Campbell@citrix.com>
>
> Paul, can you reconcile this change with the one made by Simon in cs
> 8f985b4f7a5394c8f8725a5109451a541ddb9eea?
Correction: e26b203ede31fffd52571a5ba607a26c79dc5c0d
> --msw
>
> > ---
> > drivers/net/xen-netback/netback.c | 17 +++++++++++++++--
> > 1 file changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> > index d0b0feb..6f680f4 100644
> > --- a/drivers/net/xen-netback/netback.c
> > +++ b/drivers/net/xen-netback/netback.c
> > @@ -223,15 +223,28 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
> > /*
> > * Figure out how many ring slots we're going to need to send @skb to
> > * the guest. This function is essentially a dry run of
> > - * xenvif_gop_frag_copy.
> > + * xenvif_gop_skb.
> > */
> > unsigned int xenvif_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
> > {
> > + unsigned char *data;
> > unsigned int count;
> > int i, copy_off;
> > struct skb_cb_overlay *sco;
> >
> > - count = DIV_ROUND_UP(skb_headlen(skb), PAGE_SIZE);
> > + count = 0;
> > +
> > + data = skb->data;
> > + while (data < skb_tail_pointer(skb)) {
> > + unsigned int offset = offset_in_page(data);
> > + unsigned int len = PAGE_SIZE - offset;
> > +
> > + if (data + len > skb_tail_pointer(skb))
> > + len = skb_tail_pointer(skb) - data;
> > +
> > + count++;
> > + data += len;
> > + }
> >
> > copy_off = skb_headlen(skb) % PAGE_SIZE;
> >
^ permalink raw reply
* Re: IPv6 path MTU discovery broken
From: Hannes Frederic Sowa @ 2013-10-07 1:52 UTC (permalink / raw)
To: Steinar H. Gunderson; +Cc: netdev, edumazet, fan.du
In-Reply-To: <20131006120612.GA27852@sesse.net>
On Sun, Oct 06, 2013 at 02:06:12PM +0200, Steinar H. Gunderson wrote:
> On Sat, Sep 28, 2013 at 10:33:18PM +0200, Hannes Frederic Sowa wrote:
> >> So the “packet too big” packets really look like they're being ignored.
> >> However, they _do_ reach the kernel somehow, since Icmp6InPktTooBigs
> >> seems to increase.
> >>
> >> Could this be related somehow to the packets coming from 2001:67c:29f4::31,
> >> while the default route is to a link-local address? (An RPF issue?) This used
> >> to work (although it was often flaky for me) in 3.10 and before. I can't
> >> easily bisect, though, as I don't boot this machine too often.
> > This looks like a bug and should definitely get fixed. There should be
> > no RPF issue. May I have a look at your /proc/net/ipv6_route?
>
> It started again, so now I could capture what you asked for:
>
> pannekake:~> cat /proc/net/ipv6_route
> 2001067c00a400037c4d9ae8ab73230f 80 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000000 00000001 00000137 01000023 eth0
This one does look like the most probable route which could have the problem.
It has a RTF_MODIFIED flag indicating it received a pmtu update.
Did you take the snapshot while the tcp connection was hanging? We normally
take 2 references to the rt6_info while the tcp connection is running, this
oddly only has one (but got used a lot). But doing a judgement on the
reference count is imprecise.
If you write that this got worse in recent kernels I suspect commit
commit ca4c3fc24e293719fe7410c4e63da9b6bc633b83
Author: fan.du <fan.du@windriver.com>
Date: Tue Jul 30 08:33:53 2013 +0800
net: split rt_genid for ipv4 and ipv6
The commit itself is fine, we may have a problem in our dst check logic
or do not bump rt6_genid at some point? If this is the case I might have
an idea how to reproduce the problem.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH] Fix the upper MTU limit in ipv6 GRE tunnel
From: Hannes Frederic Sowa @ 2013-10-07 2:02 UTC (permalink / raw)
To: Oussama Ghorbel
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <CABfLueGW34XnTEJWsb5FA=pWfwwKqTTj31xCZyr78CNtTZWx6Q@mail.gmail.com>
On Sun, Oct 06, 2013 at 08:18:15PM +0100, Oussama Ghorbel wrote:
> Yes, to summarize, the idea of this patch was to fix the incoherence
> in the condition of ip6gre_tunnel_change_mtu function
>
> if (new_mtu < 68 ||
> new_mtu > 0xFFF8 - dev->hard_header_len - tunnel->hlen)
>
> From the ip6gre_tnl_link_config function we can see that:
> The variable addend is equal the ipv6 header + gre header (including
> the gre options)
> On the other hand hard_header_len equal to the header of the lower
> layer + addend.
> So the quantity - (dev->hard_header_len + tunnel->hlen) equals - (eth
> header + ipv6 header + gre header + ipv6 header + gre header) which by
> no means this would represent anything! (I've just taken ipv6 over
> ethernet as example)
>
> As we have seen there is another approach to fix this issue is to
> re-factor the hlen to hold only the length of gre as it's done for
> ipv4 gre, however the solution provided in the patch seems to be
> regression risk-less.
I agree, it actually does not worsen the situation:
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Although the value hold by hlen is not coherent with the variable name
> nor with ipv4, I think there is an advantage of the current approach
> of ipv6 hlen over ipv4 hlen, because we save the calculation of ipv6
> header each time. Ex:
> In ipv4 gre and in the function ipgre_header:
> iph = (struct iphdr *)skb_push(skb, t->hlen + sizeof(*iph));
> In ipv6 and in the function ip6gre_header
> ipv6h = (struct ipv6hdr *)skb_push(skb, t->hlen);
I see your point. But we should take care that t->hlen is always initialized,
regardless if we got a route and outgoing device or not.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH nf-next] netfilter: xtables: lightweight process control group matching
From: Gao feng @ 2013-10-07 3:07 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: pablo, netfilter-devel, netdev, Tejun Heo, cgroups
In-Reply-To: <1380910855-12325-1-git-send-email-dborkman@redhat.com>
On 10/05/2013 02:20 AM, Daniel Borkmann wrote:
> +static void cgroup_attach(struct cgroup_subsys_state *css,
> + struct cgroup_taskset *tset)
> +{
> + struct task_struct *p;
> + void *v;
> +
> + cgroup_taskset_for_each(p, css, tset) {
> + task_lock(p);
> + v = (void *)(unsigned long) task_fwid(p);
Shouldn't v be css_nf_state(css)->fwid?
> + iterate_fd(p->files, 0, cgroup_fwid_update, v);
> + task_unlock(p);
> + }
> +}
^ permalink raw reply
* Re: IPv6 path MTU discovery broken
From: Hannes Frederic Sowa @ 2013-10-07 3:09 UTC (permalink / raw)
To: Steinar H. Gunderson, netdev, edumazet, fan.du
In-Reply-To: <20131007015252.GE9295@order.stressinduktion.org>
On Mon, Oct 07, 2013 at 03:52:52AM +0200, Hannes Frederic Sowa wrote:
> On Sun, Oct 06, 2013 at 02:06:12PM +0200, Steinar H. Gunderson wrote:
> > On Sat, Sep 28, 2013 at 10:33:18PM +0200, Hannes Frederic Sowa wrote:
> > >> So the “packet too big” packets really look like they're being ignored.
> > >> However, they _do_ reach the kernel somehow, since Icmp6InPktTooBigs
> > >> seems to increase.
> > >>
> > >> Could this be related somehow to the packets coming from 2001:67c:29f4::31,
> > >> while the default route is to a link-local address? (An RPF issue?) This used
> > >> to work (although it was often flaky for me) in 3.10 and before. I can't
> > >> easily bisect, though, as I don't boot this machine too often.
> > > This looks like a bug and should definitely get fixed. There should be
> > > no RPF issue. May I have a look at your /proc/net/ipv6_route?
> >
> > It started again, so now I could capture what you asked for:
> >
> > pannekake:~> cat /proc/net/ipv6_route
> > 2001067c00a400037c4d9ae8ab73230f 80 00000000000000000000000000000000 00 fe80000000000000023048fffe555743 00000000 00000001 00000137 01000023 eth0
>
> This one does look like the most probable route which could have the problem.
> It has a RTF_MODIFIED flag indicating it received a pmtu update.
>
> Did you take the snapshot while the tcp connection was hanging? We normally
> take 2 references to the rt6_info while the tcp connection is running, this
> oddly only has one (but got used a lot). But doing a judgement on the
> reference count is imprecise.
>
> If you write that this got worse in recent kernels I suspect commit
>
> commit ca4c3fc24e293719fe7410c4e63da9b6bc633b83
> Author: fan.du <fan.du@windriver.com>
> Date: Tue Jul 30 08:33:53 2013 +0800
>
> net: split rt_genid for ipv4 and ipv6
>
Hm, this actually went in in 3.12, so a bit too late for things to start
failing in 3.11.
> The commit itself is fine, we may have a problem in our dst check logic
> or do not bump rt6_genid at some point? If this is the case I might have
> an idea how to reproduce the problem.
Seems fine.
Could you try to check (with e.g. nstat) if any of the following counters
change if the icmp messages hit the host?
TcpExtOutOfWindowIcmps
Icmp6InErrors
TcpExtTCPMinTTLDrop
TcpExtListenDrops
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH v2.42 2/5] ofp-actions: Add separate OpenFlow 1.3 action parser
From: Simon Horman @ 2013-10-07 6:25 UTC (permalink / raw)
To: Ben Pfaff
Cc: dev, netdev, Jesse Gross, Pravin B Shelar, Ravi K, Isaku Yamahata,
Joe Stringer
In-Reply-To: <20131004163105.GH29572@nicira.com>
On Fri, Oct 04, 2013 at 09:31:05AM -0700, Ben Pfaff wrote:
> On Fri, Oct 04, 2013 at 05:09:57PM +0900, Simon Horman wrote:
> > From: Joe Stringer <joe@wand.net.nz>
> >
> > This patch adds new ofpact_from_openflow13() and
> > ofpacts_from_openflow13() functions parallel to the existing ofpact
> > handling code. In the OpenFlow 1.3 version, push_mpls is handled
> > differently, but all other actions are handled by the existing code.
> >
> > In the case of push_mpls for OpenFlow 1.3 the new mpls_before_vlan field of
> > struct ofpact_push_mpls is set to true. This will be used by a subsequent
> > patch to allow allow the correct VLAN+MPLS datapath behaviour to be
> > determined at odp translation time.
> >
> > Signed-off-by: Joe Stringer <joe@wand.net.nz>
> > Signed-off-by: Simon Horman <horms@verge.net.au>
>
> The need for a huge comment on mpls_before_vlan suggests to me that
> breaking it out as a separate type would be helpful. How about this:
>
> /* The position in the packet at which to insert an MPLS header.
> *
> * Used NXAST_PUSH_MPLS, OFPAT11_PUSH_MPLS. */
> enum ofpact_mpls_position {
> /* Add the MPLS LSE after the Ethernet header but before any VLAN tags.
> * OpenFlow 1.3+ requires this behavior. */
> OFPACT_MPLS_BEFORE_VLAN,
>
> /* Add the MPLS LSE after the Ethernet header and any VLAN tags.
> * OpenFlow 1.1 and 1.2 require this behavior. */
> OFPACT_MPLS_AFTER_VLAN
> };
>
> /* OFPACT_PUSH_VLAN/MPLS/PBB
> *
> * Used for NXAST_PUSH_MPLS, OFPAT11_PUSH_MPLS. */
> struct ofpact_push_mpls {
> struct ofpact ofpact;
> ovs_be16 ethertype;
> enum ofpact_mpls_position position;
> };
Hi Ben,
thanks, that looks very nice.
I will incorporate it in the next revision of the patchset.
^ permalink raw reply
* Re: [PATCH v2.42 1/5] odp: Allow VLAN actions after MPLS actions
From: Simon Horman @ 2013-10-07 6:34 UTC (permalink / raw)
To: Ben Pfaff
Cc: dev, netdev, Jesse Gross, Pravin B Shelar, Ravi K, Isaku Yamahata,
Joe Stringer
In-Reply-To: <20131004162133.GG29572@nicira.com>
On Fri, Oct 04, 2013 at 09:21:33AM -0700, Ben Pfaff wrote:
> On Fri, Oct 04, 2013 at 05:09:56PM +0900, Simon Horman wrote:
> > From: Joe Stringer <joe@wand.net.nz>
> >
> > OpenFlow 1.1 and 1.2, and 1.3 differ in their handling of MPLS actions in the
> > presence of VLAN tags. To allow correct behaviour to be committed in
> > each situation, this patch adds a second round of VLAN tag action
> > handling to commit_odp_actions(), which occurs after MPLS actions. This
> > is implemented with a new field in 'struct xlate_in' called 'vlan_tci'.
> >
> > When an push_mpls action is composed, the flow's current VLAN state is
> > stored into xin->vlan_tci, and flow->vlan_tci is set to 0 (pop_vlan). If
> > a VLAN tag is present, it is stripped; if not, then there is no change.
> > Any later modifications to the VLAN state is written to xin->vlan_tci.
> > When committing the actions, flow->vlan_tci is used before MPLS actions,
> > and xin->vlan_tci is used afterwards. This retains the current datapath
> > behaviour, but allows VLAN actions to be applied in a more flexible
> > manner.
> >
> > Both before and after this patch MPLS LSEs are pushed onto a packet after
> > any VLAN tags that may be present. This is the behaviour described in
> > OpenFlow 1.1 and 1.2. OpenFlow 1.3 specifies that MPLS LSEs should be
> > pushed onto a packet before any VLAN tags that are present. Support
> > for this will be added by a subsequent patch that makes use of
> > the infrastructure added by this patch.
> >
> > Signed-off-by: Joe Stringer <joe@wand.net.nz>
> > Signed-off-by: Simon Horman <horms@verge.net.au>
>
> I noticed a couple more minor points.
>
> First, it seems to me that the "vlan_tci" member that this adds to
> xlate_in could go in xlate_ctx just as well. I would prefer that,
> because (as far as I can tell) there is no reason for the client to use
> any value other than flow->vlan_tci here, and putting it in xlate_ctx
> hides it from the client.
Thanks. Yes I agree that is a good idea.
> Thanks for rearranging the code and updating the comment in
> do_xlate_actions(). It makes the operation clearer. But now that it's
> clear I have an additional question. Does it really make sense to have
> 'vlan_tci' as only a local variable in do_xlate_actions()? Presumably,
> MPLS and VLANs should interact the same way regardless of whether they
> are separated by resubmits or goto_tables. That is, I suspect that this
> is xlate_ctx state, not local state.
Agreed.
What I have done is to make an incremental patch which:
1. Moves the 'vlan_tci' member of strict xlate_in to
be the 'final_vlan_tci' member of struct xlate_ctx.
2. Moves the 'vlan_tci' local variable of do_xlate_actions()
to be the 'next_vlan_tci' member of struct xlate_ctx.
3. Restructures the comments surrounding the logic of the vlan_tci
code that this patch adds mostly as comments for the new
members of struct xlate_ctx. I hope things are (still?) clear.
For reference, the incremental patch I have so far is as follows.
I will squash it into this patch before reposting this series.
commit d57735cec0d3e53c7479725ae1cf825563902c30
Author: Simon Horman <horms@verge.net.au>
Date: Mon Oct 7 14:30:28 2013 +0900
Move vlan state into struct xlate_ctx
1. Add final_vlan_tci member to struct xlate_ctx instead of vlan_tci member
struct xlate_xin. This seems to be a better palace for it as it does
not need to be accessible from the caller.
2. Move local vlan_tci variable of do_xlate_actions() to be the
next_vlan_tci member of strict xlate_ctx. This allows for it to work
across resubmit actions and goto table instructions.
As suggested by Ben Pfaff
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 2afd760..845c6fe 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -172,6 +172,37 @@ struct xlate_ctx {
odp_port_t sflow_odp_port; /* Output port for composing sFlow action. */
uint16_t user_cookie_offset;/* Used for user_action_cookie fixup. */
bool exit; /* No further actions should be processed. */
+
+ /* The final vlan_tci state.
+ *
+ * The value of the vlan TCI prior to the committing of ODP MPLS
+ * actions should be stored in 'xin->flow->vlan_tci'.
+ *
+ * The final value of the VLAN TCI should be stored in 'vlan_tci'. And
+ * is if the value of 'vlan_tci' and 'xin->flow->vlan_tci' differ then
+ * VLAN ODP actions will be committed after any MPLS actions regardless
+ * of whether VLAN actions were also committed before the MPLS actions or
+ * not.
+ *
+ * This mechanism allows a VLAN tag to be popped before pushing
+ * an MPLS LSE and then the same VLAN tag pushed after pushing
+ * the MPLS LSE. In this way it is possible to push an MPLS LSE
+ * before an existing VLAN tag. Moreover this mechanism allows
+ * the order in which VLAN tags and MPLS LSEs are pushed. */
+ ovs_be16 final_vlan_tci;
+
+ /* The next vlan_tci state.
+ *
+ * This value this variable points to updated each time an
+ * action updates the VLAN tci.
+ *
+ * This variable initially points to 'xin->flow->vlan_tci' so that ODP
+ * VLAN actions are committed before any MPLS actions. When an MPLS
+ * action is composed 'next_vlan_tci' is updated to point to
+ * 'final_vlan_tci'. This causes subsequent VLAN actions to be
+ * committed after MPLS actions. */
+ ovs_be16 *next_vlan_tci;
+
};
/* A controller may use OFPP_NONE as the ingress port to indicate that
@@ -982,7 +1013,7 @@ static void
output_normal(struct xlate_ctx *ctx, const struct xbundle *out_xbundle,
uint16_t vlan)
{
- ovs_be16 *flow_tci = &ctx->xin->vlan_tci;
+ ovs_be16 *flow_tci = &ctx->final_vlan_tci;
uint16_t vid;
ovs_be16 tci, old_tci;
struct xport *xport;
@@ -1258,7 +1289,7 @@ xlate_normal(struct xlate_ctx *ctx)
/* Drop malformed frames. */
if (flow->dl_type == htons(ETH_TYPE_VLAN) &&
- !(ctx->xin->vlan_tci & htons(VLAN_CFI))) {
+ !(ctx->final_vlan_tci & htons(VLAN_CFI))) {
if (ctx->xin->packet != NULL) {
static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
VLOG_WARN_RL(&rl, "bridge %s: dropping packet with partial "
@@ -1282,7 +1313,7 @@ xlate_normal(struct xlate_ctx *ctx)
}
/* Check VLAN. */
- vid = vlan_tci_to_vid(ctx->xin->vlan_tci);
+ vid = vlan_tci_to_vid(ctx->final_vlan_tci);
if (!input_vid_is_valid(vid, in_xbundle, ctx->xin->packet != NULL)) {
xlate_report(ctx, "disallowed VLAN VID for this input port, dropping");
return;
@@ -1540,7 +1571,7 @@ compose_output_action__(struct xlate_ctx *ctx, ofp_port_t ofp_port,
const struct xport *xport = get_ofp_port(ctx->xbridge, ofp_port);
struct flow_wildcards *wc = &ctx->xout->wc;
struct flow *flow = &ctx->xin->flow;
- ovs_be16 flow_vlan_tci, xin_vlan_tci;
+ ovs_be16 flow_vlan_tci, vlan_tci;
uint32_t flow_pkt_mark;
uint8_t flow_nw_tos;
odp_port_t out_port, odp_port;
@@ -1609,7 +1640,7 @@ compose_output_action__(struct xlate_ctx *ctx, ofp_port_t ofp_port,
}
flow_vlan_tci = flow->vlan_tci;
- xin_vlan_tci = ctx->xin->vlan_tci;
+ vlan_tci = ctx->final_vlan_tci;
flow_pkt_mark = flow->pkt_mark;
flow_nw_tos = flow->nw_tos;
@@ -1649,20 +1680,20 @@ compose_output_action__(struct xlate_ctx *ctx, ofp_port_t ofp_port,
wc->masks.vlan_tci |= htons(VLAN_VID_MASK | VLAN_CFI);
}
vlandev_port = vsp_realdev_to_vlandev(ctx->xbridge->ofproto, ofp_port,
- ctx->xin->vlan_tci);
+ ctx->final_vlan_tci);
if (vlandev_port == ofp_port) {
out_port = odp_port;
} else {
out_port = ofp_port_to_odp_port(ctx->xbridge, vlandev_port);
flow->vlan_tci = htons(0);
- ctx->xin->vlan_tci = htons(0);
+ ctx->final_vlan_tci = htons(0);
}
}
if (out_port != ODPP_NONE) {
commit_odp_actions(flow, &ctx->base_flow,
&ctx->xout->odp_actions, &ctx->xout->wc,
- &ctx->mpls_depth_delta, ctx->xin->vlan_tci);
+ &ctx->mpls_depth_delta, ctx->final_vlan_tci);
nl_msg_put_odp_port(&ctx->xout->odp_actions, OVS_ACTION_ATTR_OUTPUT,
out_port);
@@ -1674,7 +1705,7 @@ compose_output_action__(struct xlate_ctx *ctx, ofp_port_t ofp_port,
out:
/* Restore flow */
flow->vlan_tci = flow_vlan_tci;
- ctx->xin->vlan_tci = xin_vlan_tci;
+ ctx->final_vlan_tci = vlan_tci;
flow->pkt_mark = flow_pkt_mark;
flow->nw_tos = flow_nw_tos;
}
@@ -1819,7 +1850,7 @@ execute_controller_action(struct xlate_ctx *ctx, int len,
commit_odp_actions(&ctx->xin->flow, &ctx->base_flow,
&ctx->xout->odp_actions, &ctx->xout->wc,
- &ctx->mpls_depth_delta, ctx->xin->vlan_tci);
+ &ctx->mpls_depth_delta, ctx->final_vlan_tci);
odp_execute_actions(NULL, packet, &key, ctx->xout->odp_actions.data,
ctx->xout->odp_actions.size, NULL, NULL);
@@ -2207,7 +2238,7 @@ xlate_sample_action(struct xlate_ctx *ctx,
commit_odp_actions(&ctx->xin->flow, &ctx->base_flow,
&ctx->xout->odp_actions, &ctx->xout->wc,
- &ctx->mpls_depth_delta, ctx->xin->vlan_tci);
+ &ctx->mpls_depth_delta, ctx->final_vlan_tci);
compose_flow_sample_cookie(os->probability, os->collector_set_id,
os->obs_domain_id, os->obs_point_id, &cookie);
@@ -2236,13 +2267,14 @@ may_receive(const struct xport *xport, struct xlate_ctx *ctx)
}
static void
-vlan_tci_restore(struct xlate_in *xin, ovs_be16 *tci_ptr, ovs_be16 orig_tci)
+vlan_tci_restore(struct xlate_ctx *ctx, ovs_be16 orig_tci)
{
/* If MPLS actions were executed after vlan actions then
* copy the final vlan_tci out and restore the intermediate VLAN state. */
- if (xin->flow.vlan_tci != orig_tci && tci_ptr == &xin->vlan_tci) {
- xin->vlan_tci = xin->flow.vlan_tci;
- xin->flow.vlan_tci = orig_tci;
+ if (ctx->xin->flow.vlan_tci != orig_tci &&
+ ctx->next_vlan_tci == &ctx->final_vlan_tci) {
+ ctx->final_vlan_tci = ctx->xin->flow.vlan_tci;
+ ctx->xin->flow.vlan_tci = orig_tci;
}
}
@@ -2252,19 +2284,8 @@ do_xlate_actions(const struct ofpact *ofpacts, size_t ofpacts_len,
{
struct flow_wildcards *wc = &ctx->xout->wc;
struct flow *flow = &ctx->xin->flow;
- ovs_be16 *vlan_tci;
const struct ofpact *a;
-
- /* VLAN actions are stored in '*vlan_tci'. This variable initially
- * points to 'xin->flow->vlan_tci', so that VLAN actions are applied
- * before any MPLS actions. When an MPLS action is translated,
- * 'vlan_tci' is updated to point to 'xin->vlan_tci'. This causes later
- * VLAN actions to be applied after MPLS actions. For each iteration
- * of the loop 'xin->vlan_tci' is updated to reflect the final VLAN
- * state of the flow. */
- vlan_tci = &ctx->xin->flow.vlan_tci;
-
OFPACT_FOR_EACH (a, ofpacts, ofpacts_len) {
struct ofpact_controller *controller;
const struct ofpact_metadata *metadata;
@@ -2274,7 +2295,7 @@ do_xlate_actions(const struct ofpact *ofpacts, size_t ofpacts_len,
}
/* Update the final vlan state to match the current state. */
- ctx->xin->vlan_tci = *vlan_tci;
+ ctx->final_vlan_tci = *ctx->next_vlan_tci;
switch (a->type) {
case OFPACT_OUTPUT:
@@ -2299,28 +2320,28 @@ do_xlate_actions(const struct ofpact *ofpacts, size_t ofpacts_len,
case OFPACT_SET_VLAN_VID:
wc->masks.vlan_tci |= htons(VLAN_VID_MASK | VLAN_CFI);
- *vlan_tci &= ~htons(VLAN_VID_MASK);
- *vlan_tci |= (htons(ofpact_get_SET_VLAN_VID(a)->vlan_vid)
+ *ctx->next_vlan_tci &= ~htons(VLAN_VID_MASK);
+ *ctx->next_vlan_tci |= (htons(ofpact_get_SET_VLAN_VID(a)->vlan_vid)
| htons(VLAN_CFI));
break;
case OFPACT_SET_VLAN_PCP:
wc->masks.vlan_tci |= htons(VLAN_VID_MASK | VLAN_CFI);
- *vlan_tci &= ~htons(VLAN_PCP_MASK);
- *vlan_tci |=
+ *ctx->next_vlan_tci &= ~htons(VLAN_PCP_MASK);
+ *ctx->next_vlan_tci |=
htons((ofpact_get_SET_VLAN_PCP(a)->vlan_pcp << VLAN_PCP_SHIFT)
| VLAN_CFI);
break;
case OFPACT_STRIP_VLAN:
memset(&wc->masks.vlan_tci, 0xff, sizeof wc->masks.vlan_tci);
- *vlan_tci = htons(0);
+ *ctx->next_vlan_tci = htons(0);
break;
case OFPACT_PUSH_VLAN:
/* XXX 802.1AD(QinQ) */
memset(&wc->masks.vlan_tci, 0xff, sizeof wc->masks.vlan_tci);
- *vlan_tci = htons(VLAN_CFI);
+ *ctx->next_vlan_tci = htons(VLAN_CFI);
break;
case OFPACT_SET_ETH_SRC:
@@ -2391,20 +2412,20 @@ do_xlate_actions(const struct ofpact *ofpacts, size_t ofpacts_len,
case OFPACT_REG_MOVE: {
ovs_be16 orig_tci = flow->vlan_tci;
nxm_execute_reg_move(ofpact_get_REG_MOVE(a), flow, wc);
- vlan_tci_restore(ctx->xin, vlan_tci, orig_tci);
+ vlan_tci_restore(ctx, orig_tci);
break;
}
case OFPACT_REG_LOAD: {
ovs_be16 orig_tci = flow->vlan_tci;
nxm_execute_reg_load(ofpact_get_REG_LOAD(a), flow);
- vlan_tci_restore(ctx->xin, vlan_tci, orig_tci);
+ vlan_tci_restore(ctx, orig_tci);
break;
}
case OFPACT_STACK_PUSH: {
ovs_be16 orig_tci = flow->vlan_tci;
- flow->vlan_tci = *vlan_tci;
+ flow->vlan_tci = *ctx->next_vlan_tci;
nxm_execute_stack_push(ofpact_get_STACK_PUSH(a), flow, wc,
&ctx->stack);
flow->vlan_tci = orig_tci;
@@ -2415,7 +2436,7 @@ do_xlate_actions(const struct ofpact *ofpacts, size_t ofpacts_len,
ovs_be16 orig_tci = flow->vlan_tci;
nxm_execute_stack_pop(ofpact_get_STACK_POP(a), flow, wc,
&ctx->stack);
- vlan_tci_restore(ctx->xin, vlan_tci, orig_tci);
+ vlan_tci_restore(ctx, orig_tci);
break;
}
@@ -2433,11 +2454,11 @@ do_xlate_actions(const struct ofpact *ofpacts, size_t ofpacts_len,
* Do not save and therefore pop the VLAN tags if the MPLS LSE
* should be pushed before any VLAN tags that are present.
* This is the behaviour described for OpenFlow 1.3. */
- ctx->xin->vlan_tci = *vlan_tci;
+ ctx->final_vlan_tci = *ctx->next_vlan_tci;
if (!oam->mpls_before_vlan) {
flow->vlan_tci = htons(0);
}
- vlan_tci = &ctx->xin->vlan_tci;
+ ctx->next_vlan_tci = &ctx->final_vlan_tci;
break;
}
@@ -2540,7 +2561,6 @@ xlate_in_init(struct xlate_in *xin, struct ofproto_dpif *ofproto,
{
xin->ofproto = ofproto;
xin->flow = *flow;
- xin->vlan_tci = flow->vlan_tci;
xin->packet = packet;
xin->may_learn = packet != NULL;
xin->rule = rule;
@@ -2770,6 +2790,8 @@ xlate_actions(struct xlate_in *xin, struct xlate_out *xout)
ctx.table_id = 0;
ctx.exit = false;
ctx.mpls_depth_delta = 0;
+ ctx.final_vlan_tci = ctx->xin->flow.vlan_tci;
+ ctx.next_vlan_tci = &ctx->xin->flow.vlan_tci;
if (xin->ofpacts) {
ofpacts = xin->ofpacts;
diff --git a/ofproto/ofproto-dpif-xlate.h b/ofproto/ofproto-dpif-xlate.h
index 54fd36d..6403f50 100644
--- a/ofproto/ofproto-dpif-xlate.h
+++ b/ofproto/ofproto-dpif-xlate.h
@@ -60,11 +60,6 @@ struct xlate_in {
* this flow when actions change header fields. */
struct flow flow;
- /* If MPLS and VLAN actions were both present in the translation, and VLAN
- * actions should occur after the MPLS actions, then this field is used
- * to store the final vlan_tci state. */
- ovs_be16 vlan_tci;
-
/* The packet corresponding to 'flow', or a null pointer if we are
* revalidating without a packet to refer to. */
const struct ofpbuf *packet;
^ permalink raw reply related
* [PATCH] net: sh_eth: Fix RX packets errors on R8A7740
From: Nguyen Hong Ky @ 2013-10-07 6:29 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Ryusuke Sakato, Sergei Shtylyov, Simon Horman
Hi David S. Miller,
This patch will fix RX packets errors when receiving big size of data.
Moreover, I set suitable parameters for get more stable when receiving
packets.
It was created on the top of mainline kernel v3.11.
I tested this patch on Armadillo800eva, it appears to be working well.
Would you please review and apply it for me.
Thank you,
Nguyen Hong Ky
Nguyen Hong Ky (1):
net: sh_eth: Fix RX packets errors on R8A7740
drivers/net/ethernet/renesas/sh_eth.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
--
1.7.5.4
^ 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