Re: [PATCH v5] audit: log nftables configuration change events once per table

tween running or stopped auditd, at least for large rulesets. Individual calls suffer from added audit logging, but that's expected of course. Tested-by: Phil Sutter Thanks, Phil

Re: [PATCH] audit: log nftables configuration change events once per table

On Thu, Mar 18, 2021 at 02:37:03PM -0400, Richard Guy Briggs wrote: > On 2021-03-18 17:30, Phil Sutter wrote: [...] > > Why did you leave the object-related logs in place? They should reappear > > at commit time just like chains and sets for instance, no? > > There are

Re: [PATCH] audit: log nftables configuration change events once per table

Hi, On Thu, Mar 18, 2021 at 11:39:52AM -0400, Richard Guy Briggs wrote: > Reduce logging of nftables events to a level similar to iptables. > Restore the table field to list the table, adding the generation. This looks much better, a few remarks below: [...] > +static const u8 nft2audit_op[] =

Re: [PATCH ghak124 v3] audit: log nftables configuration change events

Hi, On Thu, Feb 11, 2021 at 04:02:55PM -0500, Steve Grubb wrote: > On Thursday, February 11, 2021 11:29:34 AM EST Paul Moore wrote: > > > If I'm not mistaken, iptables emits a single audit log per table, ipset > > > doesn't support audit at all. So I wonder how much audit logging is > > >

Re: [PATCH ghak124 v3] audit: log nftables configuration change events

Hi, On Thu, Jun 04, 2020 at 09:20:49AM -0400, Richard Guy Briggs wrote: > iptables, ip6tables, arptables and ebtables table registration, > replacement and unregistration configuration events are logged for the > native (legacy) iptables setsockopt api, but not for the > nftables netlink api

Re: netfilter: does the API break or something else ?

Hi, On Wed, May 13, 2020 at 11:20:35PM +0800, Xiubo Li wrote: > Recently I hit one netfilter issue, it seems the API breaks or something > else. Just for the record, this was caused by a misconfigured kernel. Cheers, Phil

Re: linux-next: Signed-off-by missing for commit in the netfilter tree

Hi, On Thu, Jul 25, 2019 at 07:18:03AM +1000, Stephen Rothwell wrote: > Commit > > 5f5ff5ca2e18 ("netfilter: nf_tables: Make nft_meta expression more robust") > > is missing a Signed-off-by from its author. Argh, my SoB ended in the changelog I put below the commit message and hence was

Re: [PATCH] test_rhashtable: remove semaphore usage

is part of a longer, untested, series to remove semaphores > > from the kernel, please review as such before applying. > > --- > > lib/test_rhashtable.c | 28 ++++++++ > > 1 file changed, 16 insertions(+), 12 deletions(-) > > This was created by

Re: [PATCH 2/2] iproute2: add support for invisible qdisc dumping

On Sat, Feb 25, 2017 at 10:29:17PM +0100, Jiri Kosina wrote: > From: Jiri Kosina > > Support the new TCA_DUMP_INVISIBLE netlink attribute that allows asking > kernel to perform 'full qdisc dump', as for historical reasons some of the > default qdiscs are being hidden by the

Re: [PATCH 2/2] iproute2: add support for invisible qdisc dumping

On Sat, Feb 25, 2017 at 10:29:17PM +0100, Jiri Kosina wrote: > From: Jiri Kosina > > Support the new TCA_DUMP_INVISIBLE netlink attribute that allows asking > kernel to perform 'full qdisc dump', as for historical reasons some of the > default qdiscs are being hidden by the kernel. > > The

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Thu, Apr 14, 2016 at 08:44:40AM -0700, Eric Dumazet wrote: > On Thu, 2016-04-14 at 17:34 +0200, Jiri Kosina wrote: > > On Thu, 14 Apr 2016, Phil Sutter wrote: > > > > > OTOH some qdiscs (CBQ, DRR, DSMARK, HFSC, HTB, QFQ) assign the default > > > one upon deleti

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Thu, Apr 14, 2016 at 08:44:40AM -0700, Eric Dumazet wrote: > On Thu, 2016-04-14 at 17:34 +0200, Jiri Kosina wrote: > > On Thu, 14 Apr 2016, Phil Sutter wrote: > > > > > OTOH some qdiscs (CBQ, DRR, DSMARK, HFSC, HTB, QFQ) assign the default > > > one upon deleti

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Thu, Apr 14, 2016 at 08:01:39AM -0700, Eric Dumazet wrote: > On Thu, 2016-04-14 at 16:44 +0200, Jiri Kosina wrote: > > Hi, > > > > I've came across the behavior where adding a child qdisc and then deleting > > it again makes the networking dysfunctional (I guess that's because all of > > a

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On Thu, Apr 14, 2016 at 08:01:39AM -0700, Eric Dumazet wrote: > On Thu, 2016-04-14 at 16:44 +0200, Jiri Kosina wrote: > > Hi, > > > > I've came across the behavior where adding a child qdisc and then deleting > > it again makes the networking dysfunctional (I guess that's because all of > > a

Re: [PATCH net] tuntap: restore default qdisc

fault qdisc by setting tx_queue_len in tun_setup(). > > Fixes: f84bb1eac027 ("net: fix IFF_NO_QUEUE for drivers using alloc_netdev") > Cc: Phil Sutter <p...@nwl.cc> > Signed-off-by: Jason Wang <jasow...@redhat.com> Acked-by: Phil Sutter <p...@nwl.cc>

Re: [PATCH net] tuntap: restore default qdisc

fault qdisc by setting tx_queue_len in tun_setup(). > > Fixes: f84bb1eac027 ("net: fix IFF_NO_QUEUE for drivers using alloc_netdev") > Cc: Phil Sutter > Signed-off-by: Jason Wang Acked-by: Phil Sutter

[net PATCH] IFF_NO_QUEUE: Fix for drivers not calling ether_setup()

dling of tx_queue_len == 0") Tested-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com> Signed-off-by: Phil Sutter <p...@nwl.cc> --- net/core/dev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/core/dev.c b/net/core/dev.c index 3f4071a84a03f..75383f40

[net PATCH] IFF_NO_QUEUE: Fix for drivers not calling ether_setup()

dling of tx_queue_len == 0") Tested-by: Mathieu Desnoyers Signed-off-by: Phil Sutter --- net/core/dev.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/core/dev.c b/net/core/dev.c index 3f4071a84a03f..75383f40e7ced 100644 --- a/net/core/dev.c +++ b/net/core/dev.c

Re: [PATCH] Revert "net: sched: drop all special handling of tx_queue_len == 0"

On Wed, Feb 17, 2016 at 01:57:42PM +, Mathieu Desnoyers wrote: > - On Feb 17, 2016, at 7:47 AM, Phil Sutter p...@nwl.cc wrote: > > > Hi, > > > > On Tue, Feb 16, 2016 at 07:56:23PM -0500, Mathieu Desnoyers wrote: > >> This reverts commit 348e343

Re: [PATCH] Revert "net: sched: drop all special handling of tx_queue_len == 0"

On Wed, Feb 17, 2016 at 01:57:42PM +, Mathieu Desnoyers wrote: > - On Feb 17, 2016, at 7:47 AM, Phil Sutter p...@nwl.cc wrote: > > > Hi, > > > > On Tue, Feb 16, 2016 at 07:56:23PM -0500, Mathieu Desnoyers wrote: > >> This reverts commit 348e343

Re: [PATCH] Revert "net: sched: drop all special handling of tx_queue_len == 0"

Hi, On Tue, Feb 16, 2016 at 07:56:23PM -0500, Mathieu Desnoyers wrote: > This reverts commit 348e3435cbefa815bd56a5205c1412b5afe7b92e. > It breaks HTB classful qdiscs on the loopback interface. > > It has been broken since kernel v4.2. The offending commit has > been identified by bissection of

Re: [PATCH] Revert "net: sched: drop all special handling of tx_queue_len == 0"

Hi, On Tue, Feb 16, 2016 at 07:56:23PM -0500, Mathieu Desnoyers wrote: > This reverts commit 348e3435cbefa815bd56a5205c1412b5afe7b92e. > It breaks HTB classful qdiscs on the loopback interface. > > It has been broken since kernel v4.2. The offending commit has > been identified by bissection of

Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation

On Fri, Dec 04, 2015 at 09:45:20AM -0800, Eric Dumazet wrote: > On Fri, 2015-12-04 at 18:01 +0100, Phil Sutter wrote: > > On Fri, Dec 04, 2015 at 10:39:56PM +0800, Herbert Xu wrote: > > > On Thu, Dec 03, 2015 at 08:08:39AM -0800, Eric Dumazet wrote: > > > > > >

Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation

On Fri, Dec 04, 2015 at 10:39:56PM +0800, Herbert Xu wrote: > On Thu, Dec 03, 2015 at 08:08:39AM -0800, Eric Dumazet wrote: > > > > Anyway, __vmalloc() can be used with GFP_ATOMIC, have you tried this ? > > OK I've tried it and I no longer get any ENOMEM errors! I can't confirm this, sadly.

Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation

On Fri, Dec 04, 2015 at 10:39:56PM +0800, Herbert Xu wrote: > On Thu, Dec 03, 2015 at 08:08:39AM -0800, Eric Dumazet wrote: > > > > Anyway, __vmalloc() can be used with GFP_ATOMIC, have you tried this ? > > OK I've tried it and I no longer get any ENOMEM errors! I can't confirm this, sadly.

Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation

On Fri, Dec 04, 2015 at 09:45:20AM -0800, Eric Dumazet wrote: > On Fri, 2015-12-04 at 18:01 +0100, Phil Sutter wrote: > > On Fri, Dec 04, 2015 at 10:39:56PM +0800, Herbert Xu wrote: > > > On Thu, Dec 03, 2015 at 08:08:39AM -0800, Eric Dumazet wrote: > > > > > >

Re: rhashtable: Prevent spurious EBUSY errors on insertion

/rehash and simply retry the > insertion with the new table. > > Reported-by: Thomas Graf > Reported-by: Phil Sutter > Signed-off-by: Herbert Xu Tested-by: Phil Sutter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: rhashtable: Prevent spurious EBUSY errors on insertion

resize/rehash and simply retry the > insertion with the new table. > > Reported-by: Thomas Graf <tg...@suug.ch> > Reported-by: Phil Sutter <p...@nwl.cc> > Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au> Tested-by: Phil Sutter <p...@nwl.cc> -- To u

Re: [PATCH v2 0/4] improve fault-tolerance of rhashtable runtime-test

On Mon, Nov 30, 2015 at 05:37:55PM +0800, Herbert Xu wrote: > Phil Sutter wrote: > > The following series aims to improve lib/test_rhashtable in different > > situations: > > > > Patch 1 allows the kernel to reschedule so the test does not block too > >

Re: [PATCH v2 0/4] improve fault-tolerance of rhashtable runtime-test

On Mon, Nov 30, 2015 at 05:37:55PM +0800, Herbert Xu wrote: > Phil Sutter <p...@nwl.cc> wrote: > > The following series aims to improve lib/test_rhashtable in different > > situations: > > > > Patch 1 allows the kernel to reschedule so the test does not block to

Re: [RFC PATCH 2/2] Crypto kernel tls socket

Hi, On Tue, Nov 24, 2015 at 12:20:00PM +0100, Hannes Frederic Sowa wrote: > Stephan Mueller writes: > > > Am Dienstag, 24. November 2015, 18:34:55 schrieb Herbert Xu: > > > > Hi Herbert, > > > >>On Mon, Nov 23, 2015 at 09:43:02AM -0800, Dave Watson wrote: > >>> Userspace crypto interface for

Re: [RFC PATCH 2/2] Crypto kernel tls socket

Hi, On Tue, Nov 24, 2015 at 12:20:00PM +0100, Hannes Frederic Sowa wrote: > Stephan Mueller writes: > > > Am Dienstag, 24. November 2015, 18:34:55 schrieb Herbert Xu: > > > > Hi Herbert, > > > >>On Mon, Nov 23, 2015 at 09:43:02AM -0800, Dave Watson wrote: > >>> Userspace

Re: [PATCH v2 4/4] rhashtable-test: allow to retry even if -ENOMEM was returned

On Fri, Nov 20, 2015 at 06:17:20PM +0100, Phil Sutter wrote: > This is rather a hack to expose the current issue with rhashtable to > under high pressure sometimes return -ENOMEM even though system memory > is not exhausted and a consecutive insert may succeed. Please note that this pro

[PATCH v2 4/4] rhashtable-test: allow to retry even if -ENOMEM was returned

This is rather a hack to expose the current issue with rhashtable to under high pressure sometimes return -ENOMEM even though system memory is not exhausted and a consecutive insert may succeed. Signed-off-by: Phil Sutter --- lib/test_rhashtable.c | 14 +- 1 file changed, 13

[PATCH v2 1/4] rhashtable-test: add cond_resched() to thread test

This should fix for soft lockup bugs triggered on slow systems. Signed-off-by: Phil Sutter --- lib/test_rhashtable.c | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/test_rhashtable.c b/lib/test_rhashtable.c index 8c1ad1c..63654e3 100644 --- a/lib/test_rhashtable.c +++ b/lib

[PATCH v2 0/4] improve fault-tolerance of rhashtable runtime-test

it contains. - Add patch 4 as a debugging aid. Phil Sutter (4): rhashtable-test: add cond_resched() to thread test rhashtable-test: retry insert operations rhashtable-test: calculate max_entries value by default rhashtable-test: allow to retry even if -ENOMEM was returned lib/test_rhashtable.c

[PATCH v2 3/4] rhashtable-test: calculate max_entries value by default

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 --- lib/test_rhashtable.c | 8 +--- 1 file changed, 5 insertions(+), 3

[PATCH v2 2/4] rhashtable-test: retry insert operations

the non-threaded test to retry insert operations, too. Suggested-by: Thomas Graf Signed-off-by: Phil Sutter --- lib/test_rhashtable.c | 53 --- 1 file changed, 29 insertions(+), 24 deletions(-) diff --git a/lib/test_rhashtable.c b/lib/test_rhashtable.c

Re: rhashtable: how to deal with that rhashtable_lookup_insert_key return -EBUSY

On Fri, Nov 20, 2015 at 01:14:18PM +0800, Xin Long wrote: > when I use rhashtable_lookup_insert_key, sometimes it will return -EBUSY. > im not sure if there is a good way to workabout it. > or I should just try again and again until it's inserted successfully ? > > I have seen some use in kernel

Re: rhashtable: how to deal with that rhashtable_lookup_insert_key return -EBUSY

On Fri, Nov 20, 2015 at 01:14:18PM +0800, Xin Long wrote: > when I use rhashtable_lookup_insert_key, sometimes it will return -EBUSY. > im not sure if there is a good way to workabout it. > or I should just try again and again until it's inserted successfully ? > > I have seen some use in kernel

[PATCH v2 2/4] rhashtable-test: retry insert operations

the non-threaded test to retry insert operations, too. Suggested-by: Thomas Graf <tg...@suug.ch> Signed-off-by: Phil Sutter <p...@nwl.cc> --- lib/test_rhashtable.c | 53 --- 1 file changed, 29 insertions(+), 24 deletions(-) diff

[PATCH v2 3/4] rhashtable-test: calculate max_entries value by default

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> --- lib/test_rhashtable.c | 8 +--- 1 file changed, 5 inse

[PATCH v2 4/4] rhashtable-test: allow to retry even if -ENOMEM was returned

This is rather a hack to expose the current issue with rhashtable to under high pressure sometimes return -ENOMEM even though system memory is not exhausted and a consecutive insert may succeed. Signed-off-by: Phil Sutter <p...@nwl.cc> --- lib/test_rhashtable.c | 14 +-

Re: [PATCH v2 4/4] rhashtable-test: allow to retry even if -ENOMEM was returned

On Fri, Nov 20, 2015 at 06:17:20PM +0100, Phil Sutter wrote: > This is rather a hack to expose the current issue with rhashtable to > under high pressure sometimes return -ENOMEM even though system memory > is not exhausted and a consecutive insert may succeed. Please note that this pro

[PATCH v2 0/4] improve fault-tolerance of rhashtable runtime-test

it contains. - Add patch 4 as a debugging aid. Phil Sutter (4): rhashtable-test: add cond_resched() to thread test rhashtable-test: retry insert operations rhashtable-test: calculate max_entries value by default rhashtable-test: allow to retry even if -ENOMEM was returned lib/test_rhashtable.c

[PATCH v2 1/4] rhashtable-test: add cond_resched() to thread test

This should fix for soft lockup bugs triggered on slow systems. Signed-off-by: Phil Sutter <p...@nwl.cc> --- lib/test_rhashtable.c | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/test_rhashtable.c b/lib/test_rhashtable.c index 8c1ad1c..63654e3 100644 --- a/lib/test_rhasht

Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads

On Thu, Sep 10, 2015 at 04:03:44PM +0800, 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 > > I can't reproduce it: I can't speak for netlink, but if you apply

Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads

On Thu, Sep 10, 2015 at 04:03:44PM +0800, 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 > > I can't reproduce it: I can't speak for netlink, but if you apply

Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads

On Tue, Sep 01, 2015 at 09:50:19PM +0800, Herbert Xu wrote: > On Tue, Sep 01, 2015 at 03:43:11PM +0200, Phil Sutter wrote: > > > > Hmm. Since memory allocation is first tried with GFP_ATOMIC set and upon > > failure retried in background, this seems like a situation which mi

Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads

On Tue, Sep 01, 2015 at 09:00:57PM +0800, Herbert Xu wrote: > On Tue, Sep 01, 2015 at 02:46:48PM +0200, Phil Sutter wrote: > > > > This is not an inherent behaviour of the implementation but general > > agreement. The insertion may fail non-permanently (returning -EBUSY), &

Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads

On Tue, Sep 01, 2015 at 07:43:00PM +0800, Herbert Xu wrote: > On Mon, Aug 31, 2015 at 01:00:12PM +0200, Phil Sutter wrote: > > > > The variable would be used to track if the worker has failed to allocate > > memory in background. > > > > Since the failing inse

Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads

On Tue, Sep 01, 2015 at 07:43:00PM +0800, Herbert Xu wrote: > On Mon, Aug 31, 2015 at 01:00:12PM +0200, Phil Sutter wrote: > > > > The variable would be used to track if the worker has failed to allocate > > memory in background. > > > > Since the failing inse

Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads

On Tue, Sep 01, 2015 at 09:50:19PM +0800, Herbert Xu wrote: > On Tue, Sep 01, 2015 at 03:43:11PM +0200, Phil Sutter wrote: > > > > Hmm. Since memory allocation is first tried with GFP_ATOMIC set and upon > > failure retried in background, this seems like a situation which mi

Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads

On Tue, Sep 01, 2015 at 09:00:57PM +0800, Herbert Xu wrote: > On Tue, Sep 01, 2015 at 02:46:48PM +0200, Phil Sutter wrote: > > > > This is not an inherent behaviour of the implementation but general > > agreement. The insertion may fail non-permanently (returning -EBUSY), &

Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads

On Sun, Aug 30, 2015 at 03:47:17PM +0800, Herbert Xu wrote: > Phil Sutter wrote: > > > > Should we introduce a new field to struct rhashtable to track the > > internal state? This might allow to clean up some rather obscure tests, > > e.g. whether a table resize is i

Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads

On Sun, Aug 30, 2015 at 03:47:17PM +0800, Herbert Xu wrote: > Phil Sutter <p...@nwl.cc> wrote: > > > > Should we introduce a new field to struct rhashtable to track the > > internal state? This might allow to clean up some rather obscure tests, > > e.g. whet

Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads

On Sat, Aug 29, 2015 at 12:43:03AM +0200, Thomas Graf wrote: > 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

Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads

On Sat, Aug 29, 2015 at 12:43:03AM +0200, Thomas Graf wrote: 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

Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads

On Fri, Aug 28, 2015 at 01:13:20PM +0200, Phil Sutter wrote: > On Fri, Aug 28, 2015 at 01:09:29PM +0200, Thomas Graf wrote: > > On 08/28/15 at 12:28pm, Phil Sutter wrote: > > > After adding cond_resched() calls to threadfunc(), a surprisingly high > > > rate of insert

Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads

On Fri, Aug 28, 2015 at 01:09:29PM +0200, Thomas Graf wrote: > 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

[PATCH 3/3] rhashtable-test: calculate max_entries value by default

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 --- lib/test_rhashtable.c | 8 +--- 1 file changed, 5 insertions(+), 3

[PATCH 2/3] rhashtable-test: retry insert operations in threads

-by: Phil Sutter --- lib/test_rhashtable.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/lib/test_rhashtable.c b/lib/test_rhashtable.c index 63654e3..093cf84 100644 --- a/lib/test_rhashtable.c +++ b/lib/test_rhashtable.c @@ -244,7 +244,7 @@ static int thread_lookup_test

[PATCH 1/3] rhashtable-test: add cond_resched() to thread test

This should fix for soft lockup bugs triggered on slow systems. Signed-off-by: Phil Sutter --- lib/test_rhashtable.c | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/test_rhashtable.c b/lib/test_rhashtable.c index 8c1ad1c..63654e3 100644 --- a/lib/test_rhashtable.c +++ b/lib

[PATCH 1/3] rhashtable-test: add cond_resched() to thread test

This should fix for soft lockup bugs triggered on slow systems. Signed-off-by: Phil Sutter p...@nwl.cc --- lib/test_rhashtable.c | 5 + 1 file changed, 5 insertions(+) diff --git a/lib/test_rhashtable.c b/lib/test_rhashtable.c index 8c1ad1c..63654e3 100644 --- a/lib/test_rhashtable.c +++ b

[PATCH 2/3] rhashtable-test: retry insert operations in threads

-by: Phil Sutter p...@nwl.cc --- lib/test_rhashtable.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/lib/test_rhashtable.c b/lib/test_rhashtable.c index 63654e3..093cf84 100644 --- a/lib/test_rhashtable.c +++ b/lib/test_rhashtable.c @@ -244,7 +244,7 @@ static int

[PATCH 3/3] rhashtable-test: calculate max_entries value by default

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 --- lib/test_rhashtable.c | 8 +--- 1 file changed, 5 insertions

Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads

On Fri, Aug 28, 2015 at 01:09:29PM +0200, Thomas Graf wrote: 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

Re: [PATCH 2/3] rhashtable-test: retry insert operations in threads

On Fri, Aug 28, 2015 at 01:13:20PM +0200, Phil Sutter wrote: On Fri, Aug 28, 2015 at 01:09:29PM +0200, Thomas Graf wrote: 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

Re: [rhashtable-test] EIP is at lock_is_held

g 24, 2015 at 12:40:43PM +0800, Fengguang Wu wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git master > > commit f4a3e90ba5739cfd761b6befadae9728bd3

Re: [rhashtable-test] EIP is at lock_is_held

at 12:40:43PM +0800, Fengguang Wu wrote: Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git master commit f4a3e90ba5739cfd761b6befadae9728bd3641ed Author: Phil Sutter p...@nwl.cc

Re: [PATCH] rhashtable-test: extend to test concurrency

On Sun, Aug 16, 2015 at 08:12:35PM +0200, Florian Westphal wrote: > Phil Sutter wrote: > > After having tested insertion, lookup, table walk and removal, spawn a > > number of threads running operations on the same rhashtable. Each of > > them will: > > [..] >

Re: [PATCH] rhashtable-test: extend to test concurrency

On Sun, Aug 16, 2015 at 08:12:35PM +0200, Florian Westphal wrote: Phil Sutter p...@nwl.cc wrote: After having tested insertion, lookup, table walk and removal, spawn a number of threads running operations on the same rhashtable. Each of them will: [..] + if (down_interruptible

[PATCH] rhashtable-test: extend to test concurrency

a second on my local VM with two cores. Running 200 threads took about four seconds. If slow systems suffer too much from this though, the default could be lowered or even set to zero so this extended test does not run at all by default. Signed-off-by: Phil Sutter --- lib/test_rhashtable.c | 155

Re: kthreads: sporadic NULL pointer dereference in exit_creds()

Hi, I found the problem, it was a bug in my own code. For details see below: On Wed, Aug 12, 2015 at 05:09:31PM +0200, Phil Sutter wrote: [...] > Here is the reproducer code (kthread_test.c) I used: > > ---8<--

[PATCH] rhashtable-test: extend to test concurrency

a second on my local VM with two cores. Running 200 threads took about four seconds. If slow systems suffer too much from this though, the default could be lowered or even set to zero so this extended test does not run at all by default. Signed-off-by: Phil Sutter p...@nwl.cc --- lib

Re: kthreads: sporadic NULL pointer dereference in exit_creds()

Hi, I found the problem, it was a bug in my own code. For details see below: On Wed, Aug 12, 2015 at 05:09:31PM +0200, Phil Sutter wrote: [...] Here is the reproducer code (kthread_test.c) I used: ---8--- #include linux

kthreads: sporadic NULL pointer dereference in exit_creds()

[please keep me on Cc: since I am not subscribed to this list] Hi, While enhancing lib/test_rhashtable.c by a few threads to provoke concurrency issues, I encountered a bug in the kernel's cleanup routines for kthreads. Upon calling kthread_stop(), it would occasionally call exit_creds() for the

kthreads: sporadic NULL pointer dereference in exit_creds()

[please keep me on Cc: since I am not subscribed to this list] Hi, While enhancing lib/test_rhashtable.c by a few threads to provoke concurrency issues, I encountered a bug in the kernel's cleanup routines for kthreads. Upon calling kthread_stop(), it would occasionally call exit_creds() for the

Re: 4.1 regression in resizable hashtable tests

On Fri, Jul 17, 2015 at 12:26:36PM +0200, 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 &

Re: 4.1 regression in resizable hashtable tests

34.896936] Traversal complete: counted=49993, nelems=5, > > entries=5, table-jumps=12 > > [ 34.897056] Test failed: Total count mismatch ^^^ > > I do see count mismatches as well due to the design of the walker > which restarts and thus sees certain entries

Re: 4.1 regression in resizable hashtable tests

mismatch ^^^ I do see count mismatches as well due to the design of the walker which restarts and thus sees certain entries multiple times. Do you have this commit as well? Author: Phil Sutter p...@nwl.cc Date: Mon Jul 6 15:51:20 2015 +0200 rhashtable: fix for resize events during

Re: 4.1 regression in resizable hashtable tests

On Fri, Jul 17, 2015 at 12:26:36PM +0200, 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

Re: [PATCH] rhashtable: fix for resize events during table walk

On Mon, Jul 06, 2015 at 09:30:40PM +0800, Herbert Xu wrote: > On Mon, Jul 06, 2015 at 02:01:42PM +0200, Phil Sutter wrote: > > diff --git a/lib/rhashtable.c b/lib/rhashtable.c > > index a60a6d3..e36b94b 100644 > > --- a/lib/rhashtable.c > > +++ b/lib/rhashtable.c &

[PATCH v2] rhashtable: fix for resize events during table walk

) although not explicitly tested. Fixes: eddee5ba ("rhashtable: Fix walker behaviour during rehash") Signed-off-by: Phil Sutter --- Changes since v1: - Use simplified solution suggested by Herbert Xu. --- lib/rhashtable.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH] rhashtable: fix for resize events during table walk

) although not explicitly tested. Fixes: eddee5ba ("rhashtable: Fix walker behaviour during rehash") Signed-off-by: Phil Sutter --- lib/rhashtable.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/rhashtable.c b/lib/rhashtable.c index a60a6d3..e36b94b 100644 --

[PATCH] rhashtable: fix for resize events during table walk

not explicitly tested. Fixes: eddee5ba (rhashtable: Fix walker behaviour during rehash) Signed-off-by: Phil Sutter p...@nwl.cc --- lib/rhashtable.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/rhashtable.c b/lib/rhashtable.c index a60a6d3..e36b94b 100644 --- a/lib

[PATCH v2] rhashtable: fix for resize events during table walk

not explicitly tested. Fixes: eddee5ba (rhashtable: Fix walker behaviour during rehash) Signed-off-by: Phil Sutter p...@nwl.cc --- Changes since v1: - Use simplified solution suggested by Herbert Xu. --- lib/rhashtable.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib

Re: [PATCH] rhashtable: fix for resize events during table walk

On Mon, Jul 06, 2015 at 09:30:40PM +0800, Herbert Xu wrote: On Mon, Jul 06, 2015 at 02:01:42PM +0200, Phil Sutter wrote: diff --git a/lib/rhashtable.c b/lib/rhashtable.c index a60a6d3..e36b94b 100644 --- a/lib/rhashtable.c +++ b/lib/rhashtable.c @@ -585,6 +585,7 @@ void

Re: [PATCH] tun: orphan an skb on tx

Hi, On Mon, Feb 02, 2015 at 07:27:10AM +, David Woodhouse wrote: > On Sun, 2015-02-01 at 21:07 -0800, David Miller wrote: > > From: David Woodhouse > > Date: Sun, 01 Feb 2015 21:29:43 + > > > > > I really was looking for some way to push down something like an XFRM > > > state into the

Re: [PATCH] tun: orphan an skb on tx

Hi, On Mon, Feb 02, 2015 at 07:27:10AM +, David Woodhouse wrote: On Sun, 2015-02-01 at 21:07 -0800, David Miller wrote: From: David Woodhouse dw...@infradead.org Date: Sun, 01 Feb 2015 21:29:43 + I really was looking for some way to push down something like an XFRM state

Re: linux-next: Tree for Aug 7

On Wed, Aug 07, 2013 at 04:36:21PM -0700, David Miller wrote: > From: David Miller > Date: Wed, 07 Aug 2013 16:27:48 -0700 (PDT) > > > Look, I'm going to fix this myself, because I'm pretty tired of > > waiting for the obvious fix. > > Someone please test this: > > diff --git

Re: linux-next: Tree for Aug 7

On Wed, Aug 07, 2013 at 04:36:21PM -0700, David Miller wrote: From: David Miller da...@davemloft.net Date: Wed, 07 Aug 2013 16:27:48 -0700 (PDT) Look, I'm going to fix this myself, because I'm pretty tired of waiting for the obvious fix. Someone please test this: diff --git

Re: linux-next: Tree for Aug 7

On Wed, Aug 07, 2013 at 10:47:13AM -0700, David Miller wrote: > From: Eric Dumazet > Date: Wed, 07 Aug 2013 09:40:09 -0700 > > > On Wed, 2013-08-07 at 18:22 +0200, Johannes Berg wrote: > > > >> Maybe. I haven't tested it, but I'm thinking that skb->data doesn't > >> point to the start of the

Re: linux-next: Tree for Aug 7

On Wed, Aug 07, 2013 at 10:29:18AM +0200, Sedat Dilek wrote: > On Wed, Aug 7, 2013 at 7:54 AM, Stephen Rothwell > wrote: > > Hi all, > > > > Changes since 20130806: > > > > The ext4 tree lost its build failure. > > > > The mvebu tree gained a build failure so I used the version from > >

Re: linux-next: Tree for Aug 7

On Wed, Aug 07, 2013 at 10:29:18AM +0200, Sedat Dilek wrote: On Wed, Aug 7, 2013 at 7:54 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, Changes since 20130806: The ext4 tree lost its build failure. The mvebu tree gained a build failure so I used the version from

Re: linux-next: Tree for Aug 7

On Wed, Aug 07, 2013 at 10:47:13AM -0700, David Miller wrote: From: Eric Dumazet eric.duma...@gmail.com Date: Wed, 07 Aug 2013 09:40:09 -0700 On Wed, 2013-08-07 at 18:22 +0200, Johannes Berg wrote: Maybe. I haven't tested it, but I'm thinking that skb-data doesn't point to the start