On 09/14/16 at 09:23am, Mickaël Salaün wrote:
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 9aa01d9d3d80..36c3e482239c 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -85,6 +85,8 @@ enum bpf_arg_type {
>
> ARG_PTR_TO_CTX, /* pointer to context
On 09/14/16 at 09:23am, Mickaël Salaün wrote:
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 9aa01d9d3d80..36c3e482239c 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -85,6 +85,8 @@ enum bpf_arg_type {
>
> ARG_PTR_TO_CTX, /* pointer to context
On 09/14/16 at 09:23am, Mickaël Salaün wrote:
> @@ -155,6 +163,7 @@ union bpf_attr {
> __u32 log_size; /* size of user buffer */
> __aligned_u64 log_buf;/* user supplied buffer */
> __u32 kern_version; /* checked when
On 09/14/16 at 09:23am, Mickaël Salaün wrote:
> @@ -155,6 +163,7 @@ union bpf_attr {
> __u32 log_size; /* size of user buffer */
> __aligned_u64 log_buf;/* user supplied buffer */
> __u32 kern_version; /* checked when
On 09/14/16 at 09:23am, Mickaël Salaün wrote:
> This fix a pointer leak when an unprivileged eBPF program read a pointer
> value from the context. Even if is_valid_access() returns a pointer
> type, the eBPF verifier replace it with UNKNOWN_VALUE. The register
> value containing an address is then
On 09/14/16 at 09:23am, Mickaël Salaün wrote:
> This fix a pointer leak when an unprivileged eBPF program read a pointer
> value from the context. Even if is_valid_access() returns a pointer
> type, the eBPF verifier replace it with UNKNOWN_VALUE. The register
> value containing an address is then
On 07/07/16 at 10:36pm, Jiri Kosina wrote:
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index f45929c..630838e 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -52,6 +52,7 @@
> #include
> #include
> #include
> +#include
>
> struct
On 07/07/16 at 10:36pm, Jiri Kosina wrote:
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index f45929c..630838e 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -52,6 +52,7 @@
> #include
> #include
> #include
> +#include
>
> struct
On 12/09/15 at 10:38am, Herbert Xu wrote:
> On Wed, Dec 09, 2015 at 03:36:32AM +0100, Thomas Graf wrote:
> >
> > Without knowing your exact implementation plans: introducing an
> > additional reference indirection for every lookup will have a
> > huge performance penalt
On 12/09/15 at 10:24am, Herbert Xu wrote:
> On Wed, Dec 09, 2015 at 03:18:26AM +0100, Thomas Graf wrote:
> >
> > Assuming that we only encounter this scenario with very large
> > table sizes, it might be OK to assume that deferring the actual
> > resize via the wor
On 12/05/15 at 03:06pm, Herbert Xu wrote:
> Unless we can make __vmalloc work with BH disabled, I guess we'll
> have to go back to multi-level lookups unless someone has a better
> suggestion.
Assuming that we only encounter this scenario with very large
table sizes, it might be OK to assume
On 12/09/15 at 10:24am, Herbert Xu wrote:
> On Wed, Dec 09, 2015 at 03:18:26AM +0100, Thomas Graf wrote:
> >
> > Assuming that we only encounter this scenario with very large
> > table sizes, it might be OK to assume that deferring the actual
> > resize via the wor
On 12/05/15 at 03:06pm, Herbert Xu wrote:
> Unless we can make __vmalloc work with BH disabled, I guess we'll
> have to go back to multi-level lookups unless someone has a better
> suggestion.
Assuming that we only encounter this scenario with very large
table sizes, it might be OK to assume
On 12/09/15 at 10:38am, Herbert Xu wrote:
> On Wed, Dec 09, 2015 at 03:36:32AM +0100, Thomas Graf wrote:
> >
> > Without knowing your exact implementation plans: introducing an
> > additional reference indirection for every lookup will have a
> > huge performance penalt
On 12/05/15 at 03:06pm, Herbert Xu wrote:
> On Fri, Dec 04, 2015 at 07:15:55PM +0100, Phil Sutter wrote:
> >
> > > Only one should really do this, while others are waiting.
> >
> > Sure, that was my previous understanding of how this thing works.
>
> Yes that's clearly how it should be.
On 12/05/15 at 03:06pm, Herbert Xu wrote:
> On Fri, Dec 04, 2015 at 07:15:55PM +0100, Phil Sutter wrote:
> >
> > > Only one should really do this, while others are waiting.
> >
> > Sure, that was my previous understanding of how this thing works.
>
> Yes that's clearly how it should be.
On 10/21/15 at 05:17pm, Daniel Borkmann wrote:
> On 10/20/2015 08:56 PM, Eric W. Biederman wrote:
> ...
> >Just FYI: Using a device for this kind of interface is pretty
> >much a non-starter as that quickly gets you into situations where
> >things do not work in containers. If someone gets a
On 10/21/15 at 05:17pm, Daniel Borkmann wrote:
> On 10/20/2015 08:56 PM, Eric W. Biederman wrote:
> ...
> >Just FYI: Using a device for this kind of interface is pretty
> >much a non-starter as that quickly gets you into situations where
> >things do not work in containers. If someone gets a
On 10/16/15 at 10:32am, Alexei Starovoitov wrote:
> On 10/16/15 9:43 AM, Hannes Frederic Sowa wrote:
> >Oh, tracing does not allow daemons. Why? I can only imagine embedded
> >users, no?
>
> yes and for networking: restartability and HA.
> cannot really do that with fuse/daemons.
Right, the
On 10/16/15 at 10:32am, Alexei Starovoitov wrote:
> On 10/16/15 9:43 AM, Hannes Frederic Sowa wrote:
> >Oh, tracing does not allow daemons. Why? I can only imagine embedded
> >users, no?
>
> yes and for networking: restartability and HA.
> cannot really do that with fuse/daemons.
Right, the
On 10/08/15 at 08:20pm, Hannes Frederic Sowa wrote:
> Hi Alexei,
>
> On Thu, Oct 8, 2015, at 07:23, Alexei Starovoitov wrote:
> > The feature is controlled by sysctl kernel.unprivileged_bpf_disabled.
> > This toggle defaults to off (0), but can be set true (1). Once true,
> > bpf programs and
On 10/08/15 at 08:20pm, Hannes Frederic Sowa wrote:
> Hi Alexei,
>
> On Thu, Oct 8, 2015, at 07:23, Alexei Starovoitov wrote:
> > The feature is controlled by sysctl kernel.unprivileged_bpf_disabled.
> > This toggle defaults to off (0), but can be set true (1). Once true,
> > bpf programs and
>
> entry->next = base + off
> entry->next <<= 1
> entry->next |= 1
>
> Which will break concurrent readers.
>
> NULLS value recomputation is not needed here, so just remove
> the complex logic.
>
> The data race was found with KernelThre
On 09/21/15 at 04:03pm, Eric Dumazet wrote:
> What I said is :
>
> In @head you already have the correct nulls value, from hash table.
>
> You do not need to recompute this value, and/or test if hash table chain
> is empty.
>
> If hash bucket is empty, it contains the appropriate NULLS value.
>
On 09/21/15 at 04:03pm, Eric Dumazet wrote:
> What I said is :
>
> In @head you already have the correct nulls value, from hash table.
>
> You do not need to recompute this value, and/or test if hash table chain
> is empty.
>
> If hash bucket is empty, it contains the appropriate NULLS value.
>
nitizer (KTSAN).
>
> Signed-off-by: Dmitry Vyukov <dvyu...@google.com>
Acked-by: Thomas Graf <tg...@suug.ch>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 09/21/15 at 07:51am, Eric Dumazet wrote:
> The important part here is that we rehash an item, so we need to make
> sure to maintain consistent ->next field, and need to prevent compiler
> from using ->next as a temporary variable.
>
> ptr->next = 1UL | ((base + offset) << 1);
>
> Is dangerous
On 09/21/15 at 07:51am, Eric Dumazet wrote:
> The important part here is that we rehash an item, so we need to make
> sure to maintain consistent ->next field, and need to prevent compiler
> from using ->next as a temporary variable.
>
> ptr->next = 1UL | ((base + offset) << 1);
>
> Is dangerous
gt; has been bound.
>
> Fixes: c0bb07df7d98 ("netlink: Reset portid after netlink_insert failure")
> Reported-by: Tejun Heo
> Reported-by: Linus Torvalds
> Signed-off-by: Herbert Xu
> Reviewed-by: Cong Wang
Acked-by: Thomas Graf
--
To unsubscribe from this list: send t
gt; has been bound.
>
> Fixes: c0bb07df7d98 ("netlink: Reset portid after netlink_insert failure")
> Reported-by: Tejun Heo <t...@kernel.org>
> Reported-by: Linus Torvalds <torva...@linux-foundation.org>
> Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au
y
> getting rid of the pointer intermediary and referring directly to the
> ip_tunnel_info structure.
>
> Signed-off-by: Geert Uytterhoeven
Acked-by: Thomas Graf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ke
y
> getting rid of the pointer intermediary and referring directly to the
> ip_tunnel_info structure.
>
> Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Acked-by: Thomas Graf <tg...@suug.ch>
--
To unsubscribe from this list: send the line "unsubscribe linu
On 09/02/15 at 10:00am, Herbert Xu wrote:
> On Tue, Sep 01, 2015 at 04:51:24PM +0200, Thomas Graf wrote:
> >
> > 1. The current in-kernel self-test
> > 2. bind_netlink.c: https://github.com/tgraf/rhashtable
>
> Thanks, I will try to reproduce this.
Th
On 09/02/15 at 10:00am, Herbert Xu wrote:
> On Tue, Sep 01, 2015 at 04:51:24PM +0200, Thomas Graf wrote:
> >
> > 1. The current in-kernel self-test
> > 2. bind_netlink.c: https://github.com/tgraf/rhashtable
>
> Thanks, I will try to reproduce this.
Th
On 09/01/15 at 10:16pm, Herbert Xu wrote:
> On Tue, Sep 01, 2015 at 04:13:05PM +0200, Thomas Graf wrote:
> >
> > You can easily trigger this outside of the testsuite as well. Open
> > 10K Netlink sockets in a loop and the creation of the sockets will
> > fail way b
On 09/01/15 at 10:03pm, Herbert Xu wrote:
> On Tue, Sep 01, 2015 at 03:56:18PM +0200, Phil Sutter wrote:
> >
> > Looking at rhashtable_test.c, I see the initial table size is 8 entries.
> > 70% of that is 5.6 entries, so background expansion is started after the
> > 6th entry has been added,
On 09/01/15 at 10:16pm, Herbert Xu wrote:
> On Tue, Sep 01, 2015 at 04:13:05PM +0200, Thomas Graf wrote:
> >
> > You can easily trigger this outside of the testsuite as well. Open
> > 10K Netlink sockets in a loop and the creation of the sockets will
> > fail way b
On 09/01/15 at 10:03pm, Herbert Xu wrote:
> On Tue, Sep 01, 2015 at 03:56:18PM +0200, Phil Sutter wrote:
> >
> > Looking at rhashtable_test.c, I see the initial table size is 8 entries.
> > 70% of that is 5.6 entries, so background expansion is started after the
> > 6th entry has been added,
On 08/28/15 at 03:34pm, Phil Sutter wrote:
> Quite ugly, IMHO: rhashtable_insert_fast() may return -ENOMEM as
> non-permanent error, if allocation in GFP_ATOMIC failed. In this case,
> allocation in GFP_KERNEL is retried by rht_deferred_worker(). Sadly,
> there is no way to determine if that has
size unless overridden by parameter.
>
> Note that specifying the exact number of objects upon table init won't
> suffice as that value is being rounded down to the next power of two -
> anticipate this by rounding up to the next power of two in beforehand.
>
> Signed-off-by:
On 08/28/15 at 12:28pm, Phil Sutter wrote:
> After adding cond_resched() calls to threadfunc(), a surprisingly high
> rate of insert failures occurred probably due to table resizes getting a
> better chance to run in background. To not soften up the remaining
> tests, retry inserts until they
On 08/28/15 at 12:28pm, Phil Sutter wrote:
> This should fix for soft lockup bugs triggered on slow systems.
>
> Signed-off-by: Phil Sutter
Acked-by: Thomas Graf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord
On 08/28/15 at 12:28pm, Phil Sutter wrote:
This should fix for soft lockup bugs triggered on slow systems.
Signed-off-by: Phil Sutter p...@nwl.cc
Acked-by: Thomas Graf tg...@suug.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
overridden by parameter.
Note that specifying the exact number of objects upon table init won't
suffice as that value is being rounded down to the next power of two -
anticipate this by rounding up to the next power of two in beforehand.
Signed-off-by: Phil Sutter p...@nwl.cc
Acked-by: Thomas
On 08/28/15 at 12:28pm, Phil Sutter wrote:
After adding cond_resched() calls to threadfunc(), a surprisingly high
rate of insert failures occurred probably due to table resizes getting a
better chance to run in background. To not soften up the remaining
tests, retry inserts until they either
On 08/28/15 at 03:34pm, Phil Sutter wrote:
Quite ugly, IMHO: rhashtable_insert_fast() may return -ENOMEM as
non-permanent error, if allocation in GFP_ATOMIC failed. In this case,
allocation in GFP_KERNEL is retried by rht_deferred_worker(). Sadly,
there is no way to determine if that has
ot subject to this patch but we may want to revisit the syntax of the
state flags. It's neatly compressed like this but ct_state=untracked
ct_state=related might be more readable. The +trk should be implicit
for anything !untracked
> Signed-off-by: Joe Stringer
Acked-by: Thomas Graf
--
To
ata attached to the connection. Label modification occurs after
> lookup, and will only persist when the conntrack entry is committed by
> providing the COMMIT flag to the CT action. Labels are currently fixed
> to 128 bits in size.
>
> Signed-off-by: Joe Stringer
Acked-by: Thomas Graf
--
To
nel state to dst_entry")
> Signed-off-by: Sasha Levin
Acked-by: Thomas Graf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
d-off-by: Joe Stringer
Acked-by: Thomas Graf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
; CT action. The maximum received unit (MRU) size is tracked so that
> refragmentation can occur during output.
>
> IP frag handling contributed by Andy Zhou.
>
> Signed-off-by: Joe Stringer
> Signed-off-by: Justin Pettit
> Signed-off-by: Andy Zhou
Acked-by
On 08/24/15 at 05:32pm, Joe Stringer wrote:
> This variation on skb_dst_copy() doesn't require two skbs.
>
> Signed-off-by: Joe Stringer
> Acked-by: Pravin B Shelar
Acked-by: Thomas Graf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the original actions length when
> de-serializing and re-use the original length when serializing.
>
> Signed-off-by: Joe Stringer
> Acked-by: Pravin B Shelar
Acked-by: Thomas Graf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
contributed by Andy Zhou.
Signed-off-by: Joe Stringer joestrin...@nicira.com
Signed-off-by: Justin Pettit jpet...@nicira.com
Signed-off-by: Andy Zhou az...@nicira.com
Acked-by: Thomas Graf tg...@suug.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
of the
state flags. It's neatly compressed like this but ct_state=untracked
ct_state=related might be more readable. The +trk should be implicit
for anything !untracked
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Thomas Graf tg...@suug.ch
--
To unsubscribe from this list: send the line
On 08/24/15 at 05:32pm, Joe Stringer wrote:
This variation on skb_dst_copy() doesn't require two skbs.
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Pravin B Shelar pshe...@nicira.com
Acked-by: Thomas Graf tg...@suug.ch
--
To unsubscribe from this list: send the line
-by: Sasha Levin sasha.le...@oracle.com
Acked-by: Thomas Graf tg...@suug.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
to the connection. Label modification occurs after
lookup, and will only persist when the conntrack entry is committed by
providing the COMMIT flag to the CT action. Labels are currently fixed
to 128 bits in size.
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Thomas Graf tg...@suug.ch
actions length when
de-serializing and re-use the original length when serializing.
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Pravin B Shelar pshe...@nicira.com
Acked-by: Thomas Graf tg...@suug.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
...@nicira.com
Acked-by: Thomas Graf tg...@suug.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signed-off-by: Joe Stringer
> Acked-by: Florian Westphal
Acked-by: Thomas Graf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
On 08/18/15 at 04:39pm, Joe Stringer wrote:
> The following patches will reuse this code from OVS.
>
> Signed-off-by: Joe Stringer
Acked-by: Thomas Graf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@v
andled by transparently assembling them as part of the
> ct action. The maximum received unit (MRU) size is tracked so that
> refragmentation can occur during output.
>
> IP frag handling contributed by Andy Zhou.
>
> Signed-off-by: Joe Stringer
> Signed-off-by: Justin
-by: Joe Stringer joestrin...@nicira.com
Acked-by: Florian Westphal f...@strlen.de
Acked-by: Thomas Graf tg...@suug.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
.
Acked-by: Thomas Graf tg...@suug.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 08/18/15 at 04:39pm, Joe Stringer wrote:
The following patches will reuse this code from OVS.
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Thomas Graf tg...@suug.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
t to zero so this extended test does not run at all by
> default.
>
> Signed-off-by: Phil Sutter
Looks great. A default of 10 makes sense as well. Thanks a lot!
Acked-by: Thomas Graf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
.
Signed-off-by: Phil Sutter p...@nwl.cc
Looks great. A default of 10 makes sense as well. Thanks a lot!
Acked-by: Thomas Graf tg...@suug.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On 07/31/15 at 10:51am, Joe Stringer wrote:
> On 31 July 2015 at 07:34, Hannes Frederic Sowa wrote:
> > In general, this shouldn't be necessary as the packet should already be
> > scrubbed before they arrive here.
> >
> > Could you maybe add a WARN_ON and check how those skbs with conntrack
> >
On 07/31/15 at 10:51am, Joe Stringer wrote:
On 31 July 2015 at 07:34, Hannes Frederic Sowa han...@redhat.com wrote:
In general, this shouldn't be necessary as the packet should already be
scrubbed before they arrive here.
Could you maybe add a WARN_ON and check how those skbs with
On 07/30/15 at 04:16pm, Joe Stringer wrote:
> On 30 July 2015 at 11:40, Thomas Graf wrote:
> > On 07/30/15 at 11:12am, Joe Stringer wrote:
> >> Signed-off-by: Joe Stringer
> >
> > Can you write a few lines on why this is needed? I have flows which
> > use th
On 07/30/15 at 04:16pm, Joe Stringer wrote:
On 30 July 2015 at 11:40, Thomas Graf tg...@suug.ch wrote:
On 07/30/15 at 11:12am, Joe Stringer wrote:
Signed-off-by: Joe Stringer joestrin...@nicira.com
Can you write a few lines on why this is needed? I have flows which
use the mark
On 07/30/15 at 11:12am, Joe Stringer wrote:
> Signed-off-by: Joe Stringer
Acked-by: Thomas Graf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majord
On 07/30/15 at 11:12am, Joe Stringer wrote:
> This will allow the ovs-conntrack code to reuse these macros.
>
> Signed-off-by: Joe Stringer
Acked-by: Thomas Graf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord
the original actions length when
> de-serializing and re-use the original length when serializing.
>
> Signed-off-by: Joe Stringer
Acked-by: Thomas Graf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
On 07/30/15 at 11:12am, Joe Stringer wrote:
> Signed-off-by: Joe Stringer
Can you write a few lines on why this is needed? I have flows which
use the mark to communicate with netfilter through internal ports.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On 07/30/15 at 11:12am, Joe Stringer wrote:
This will allow the ovs-conntrack code to reuse these macros.
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Thomas Graf tg...@suug.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
actions length when
de-serializing and re-use the original length when serializing.
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Thomas Graf tg...@suug.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
On 07/30/15 at 11:12am, Joe Stringer wrote:
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Thomas Graf tg...@suug.ch
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On 07/30/15 at 11:12am, Joe Stringer wrote:
Signed-off-by: Joe Stringer joestrin...@nicira.com
Can you write a few lines on why this is needed? I have flows which
use the mark to communicate with netfilter through internal ports.
--
To unsubscribe from this list: send the line unsubscribe
On 07/23/15 at 01:28am, David Miller wrote:
> From: Thomas Graf
> Date: Thu, 23 Jul 2015 10:08:44 +0200
>
> > Convert the module_init() to a invocation from inet_init() since
> > ip_tunnel_core is part of the INET built-in.
> >
> > Fixes: 3093fbe7ff4 ("r
Convert the module_init() to a invocation from inet_init() since
ip_tunnel_core is part of the INET built-in.
Fixes: 3093fbe7ff4 ("route: Per route IP tunnel metadata via lightweight
tunnel")
Signed-off-by: Thomas Graf
---
Compiles for me with:
make ARCH=arm CROSS_COMPILE=arm
Convert the module_init() to a invocation from inet_init() since
ip_tunnel_core is part of the INET built-in.
Fixes: 3093fbe7ff4 (route: Per route IP tunnel metadata via lightweight
tunnel)
Signed-off-by: Thomas Graf tg...@suug.ch
---
Compiles for me with:
make ARCH=arm CROSS_COMPILE=arm-linux
On 07/23/15 at 01:28am, David Miller wrote:
From: Thomas Graf tg...@suug.ch
Date: Thu, 23 Jul 2015 10:08:44 +0200
Convert the module_init() to a invocation from inet_init() since
ip_tunnel_core is part of the INET built-in.
Fixes: 3093fbe7ff4 (route: Per route IP tunnel metadata via
On 07/17/15 at 12:26pm, Phil Sutter wrote:
> On Fri, Jul 17, 2015 at 10:04:56AM +0200, Thomas Graf wrote:
> > On 07/02/15 at 10:09pm, Meelis Roos wrote:
> > > [ 33.425061] Running rhashtable test nelem=8, max_size=65536,
> > > shrinking=0
> > > [ 33.
On 07/02/15 at 10:09pm, Meelis Roos wrote:
> [ 33.425061] Running rhashtable test nelem=8, max_size=65536, shrinking=0
> [ 33.425154] Test 00:
> [ 33.534470] Adding 5 keys
> [ 34.743553] Info: encountered resize
> [ 34.743698] Info: encountered resize
> [ 34.743838] Info:
On 07/02/15 at 10:09pm, Meelis Roos wrote:
[ 33.425061] Running rhashtable test nelem=8, max_size=65536, shrinking=0
[ 33.425154] Test 00:
[ 33.534470] Adding 5 keys
[ 34.743553] Info: encountered resize
[ 34.743698] Info: encountered resize
[ 34.743838] Info: encountered
On 07/17/15 at 12:26pm, Phil Sutter wrote:
On Fri, Jul 17, 2015 at 10:04:56AM +0200, Thomas Graf wrote:
On 07/02/15 at 10:09pm, Meelis Roos wrote:
[ 33.425061] Running rhashtable test nelem=8, max_size=65536,
shrinking=0
[ 33.425154] Test 00:
[ 33.534470] Adding 5 keys
On 07/16/15 at 02:15pm, Denys Vlasenko wrote:
> On 07/16/2015 12:41 PM, Thomas Graf wrote:
> > On 07/16/15 at 12:02pm, Denys Vlasenko wrote:
> >> +/* jhash - hash an arbitrary key
> >> + * @k: sequence of bytes as key
> >> + * @length: the length of the key
On 07/16/15 at 12:02pm, Denys Vlasenko wrote:
> +/* jhash - hash an arbitrary key
> + * @k: sequence of bytes as key
> + * @length: the length of the key
> + * @initval: the previous hash, or an arbitray value
> + *
> + * The generic version, hashes an arbitrary sequence of bytes.
> + * No
On 07/16/15 at 12:02pm, Denys Vlasenko wrote:
+/* jhash - hash an arbitrary key
+ * @k: sequence of bytes as key
+ * @length: the length of the key
+ * @initval: the previous hash, or an arbitray value
+ *
+ * The generic version, hashes an arbitrary sequence of bytes.
+ * No alignment or
On 07/16/15 at 02:15pm, Denys Vlasenko wrote:
On 07/16/2015 12:41 PM, Thomas Graf wrote:
On 07/16/15 at 12:02pm, Denys Vlasenko wrote:
+/* jhash - hash an arbitrary key
+ * @k: sequence of bytes as key
+ * @length: the length of the key
+ * @initval: the previous hash, or an arbitray
On 07/15/15 at 12:35am, mr...@linux.ee wrote:
> Yes, this fixes the error, thank you.
>
> The new problem with the test - soft lockup - CPU#0 stuck for 22s! is
> still there on 360 MHz UltraSparc IIi. I understand it is harmless but
> is there some easy way to make the test avoid NMI watchdog?
On 07/13/15 at 10:11pm, Cong Wang wrote:
> Caused by:
>
> commit 21e4902aea80ef35afc00ee8d2abdea4f519b7f7
> Author: Thomas Graf
> Date: Fri Jan 2 23:00:22 2015 +0100
>
> netlink: Lockless lookup with RCU grace period in socket release
>
> Defers the rele
On 07/13/15 at 10:11pm, Cong Wang wrote:
Caused by:
commit 21e4902aea80ef35afc00ee8d2abdea4f519b7f7
Author: Thomas Graf tg...@suug.ch
Date: Fri Jan 2 23:00:22 2015 +0100
netlink: Lockless lookup with RCU grace period in socket release
Defers the release of the socket
On 07/15/15 at 12:35am, mr...@linux.ee wrote:
Yes, this fixes the error, thank you.
The new problem with the test - soft lockup - CPU#0 stuck for 22s! is
still there on 360 MHz UltraSparc IIi. I understand it is harmless but
is there some easy way to make the test avoid NMI watchdog?
[
^^
> [ 32.022828] Deleting 2048 keys
Thanks for the report. I think this is already fixed. Can you try with the
following commit:
commit 246b23a7695bd5a457aa51a36a948cce53d1d477
Author: Thomas Graf
Date: Thu Apr 30 22:37:44 2015 +
rhashtable-test: Use walker to test bucket statis
Thanks for the report. I think this is already fixed. Can you try with the
following commit:
commit 246b23a7695bd5a457aa51a36a948cce53d1d477
Author: Thomas Graf tg...@suug.ch
Date: Thu Apr 30 22:37:44 2015 +
rhashtable-test: Use walker to test bucket statistics
As resizes may
Remove bogus max_size setting
>
> Now that resizing is completely automatic, we need to remove
> the max_size setting or the test will fail.
>
> Reported-by: Fengguang Wu
> Signed-off-by: Herbert Xu
Acked-by: Thomas Graf
Had the same fix queued up in an upcoming series ;-)
.
Reported-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: Herbert Xu herb...@gondor.apana.org.au
Acked-by: Thomas Graf tg...@suug.ch
Had the same fix queued up in an upcoming series ;-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
1 - 100 of 368 matches
Mail list logo
