Hangbin,
On Tue, Nov 19, 2024 at 07:22:21AM +, Hangbin Liu wrote:
> On Sun, Nov 17, 2024 at 09:09:00PM +0100, Jason A. Donenfeld wrote:
> > On Mon, Nov 11, 2024 at 04:19:02AM +, Hangbin Liu wrote:
> > > Use nft by default if it's supported, as nft is the replacement for
> > > iptables,
>
Hi Liu Hangbin,
On Thu, Nov 07, 2024 at 02:54:38AM +, Hangbin Liu wrote:
> Use nft by default if it's supported, as nft is the replacement for iptables,
> which is used by default in some releases. Additionally, iptables is dropped
> in some releases.
>
> Signed-off-by: Hangbin Liu
> ---
> C
un-time between 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
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
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[] = {
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
> > > required
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 which
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
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 dropp
s 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
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 com
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
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 su
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
ial handling 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/c
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 348e3435cbefa815
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 t
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:
> > > >
> >
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. Using
l give up our resize/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
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
> >
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 TLS
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
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
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
at 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_rhashta
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(
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
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
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 p
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
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),
>
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
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
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
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
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
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(
: 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
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
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
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:
>
> [..]
>
alf 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
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<--
[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
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
&
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
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
&
r during
rehash") 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
r during
rehash") 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 a
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 t
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 a/include/linux/et
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 dat
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
> > next-2013
54 matches
Mail list logo
