* Re: netxen: box stuck in netxen_napi_disable()
From: Eric Dumazet @ 2015-01-22 6:52 UTC (permalink / raw)
To: Mike Galbraith; +Cc: netdev
In-Reply-To: <1421907358.5286.42.camel@marge.simpson.net>
On Thu, 2015-01-22 at 07:15 +0100, Mike Galbraith wrote:
> On Wed, 2015-01-21 at 21:57 -0800, Eric Dumazet wrote:
>
> > This driver doesn't follow the NAPI model correctly.
> >
> > Please try following fix :
>
> Thanks Eric, I'll plug it in in a bit and poke at it. No news is good
> news, as good as news gets for unknown repeatability bugs that is ;-)
To trigger the bug, all you had to do was to stress the transmit side.
You could reduce MAX_STATUS_HANDLE from 64 to 4 to trigger it even
faster.
I'll send an official patch tomorrow morning.
Thanks !
^ permalink raw reply
* [PATCH 1/3] stmmac: if force_thresh_dma_mode is set, pass tc to both txmode and rxmode in tx_hard_error_bump_tc interrupt
From: Sonic Zhang @ 2015-01-22 6:55 UTC (permalink / raw)
To: Giuseppe Cavallaro, David S. Miller
Cc: netdev, adi-buildroot-devel, Sonic Zhang
From: Sonic Zhang <sonic.zhang@analog.com>
Dont' pass SF_DMA_MODE to rxmode in this case.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 8c6b7c1..5edfc8a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1446,7 +1446,11 @@ static void stmmac_dma_interrupt(struct stmmac_priv *priv)
/* Try to bump up the dma threshold on this failure */
if (unlikely(tc != SF_DMA_MODE) && (tc <= 256)) {
tc += 64;
- priv->hw->dma->dma_mode(priv->ioaddr, tc, SF_DMA_MODE);
+ if (priv->plat->force_thresh_dma_mode)
+ priv->hw->dma->dma_mode(priv->ioaddr, tc, tc);
+ else
+ priv->hw->dma->dma_mode(priv->ioaddr, tc,
+ SF_DMA_MODE);
priv->xstats.threshold = tc;
}
} else if (unlikely(status == tx_hard_error))
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 3/3] netlink: Lock out table resizes while dumping Netlink sockets
From: Herbert Xu @ 2015-01-22 7:20 UTC (permalink / raw)
To: Thomas Graf
Cc: Patrick McHardy, davem, paulmck, ying.xue, netdev,
netfilter-devel, Eric Dumazet
In-Reply-To: <20150122063501.GA3746@gondor.apana.org.au>
On Thu, Jan 22, 2015 at 05:35:01PM +1100, Herbert Xu wrote:
> On Wed, Jan 21, 2015 at 10:23:46AM +0000, Thomas Graf wrote:
> >
> > The usage will be identical to how __inet_lookup_listener() uses it.
> > If at the end of the lookup, we ended up in a different table than
> > we started, the lookup is restarted as an entry has moved to another
> > table while we were moving over it.
>
> Who uses this stuff apart from ip_dynaddr?
OK it's there for fast socket recycling. Given that and the fact
that everyone seems to be happy with restarting the dump after a
resize, I think we should just go with that.
Anybody who wants a better walk can always implement their own
data structure outside of rhashtable.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 2/3] stmmac: hardware TX COE doesn't work when force_thresh_dma_mode is set
From: Sonic Zhang @ 2015-01-22 6:55 UTC (permalink / raw)
To: Giuseppe Cavallaro, David S. Miller
Cc: netdev, adi-buildroot-devel, Sonic Zhang
In-Reply-To: <1421909758-31359-1-git-send-email-sonic.adi@gmail.com>
From: Sonic Zhang <sonic.zhang@analog.com>
Clear the TX COE bit when force_thresh_dma_mode is set even hardware
dma capability says support.
Tested on BF609.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 5edfc8a..7a7385a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2746,7 +2746,11 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
priv->plat->enh_desc = priv->dma_cap.enh_desc;
priv->plat->pmt = priv->dma_cap.pmt_remote_wake_up;
- priv->plat->tx_coe = priv->dma_cap.tx_coe;
+ /* TXCOE doesn't work in thresh DMA mode */
+ if (priv->plat->force_thresh_dma_mode)
+ priv->plat->tx_coe = 0;
+ else
+ priv->plat->tx_coe = priv->dma_cap.tx_coe;
if (priv->dma_cap.rx_coe_type2)
priv->plat->rx_coe = STMMAC_RX_COE_TYPE2;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/3] stmmac: Add an optional device tree property "snps,burst_len"
From: Sonic Zhang @ 2015-01-22 6:55 UTC (permalink / raw)
To: Giuseppe Cavallaro, David S. Miller
Cc: netdev, adi-buildroot-devel, Sonic Zhang
In-Reply-To: <1421909758-31359-1-git-send-email-sonic.adi@gmail.com>
From: Sonic Zhang <sonic.zhang@analog.com>
This property define the AXI bug lenth.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
Documentation/devicetree/bindings/net/stmmac.txt | 1 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index c41afd9..8ca65ce 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -43,6 +43,7 @@ Optional properties:
available this clock is used for programming the Timestamp Addend Register.
If not passed then the system clock will be used and this is fine on some
platforms.
+- snps,burst_len: The AXI burst lenth value of the AXI BUS MODE register.
Examples:
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 3039de2..a20cf0d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -234,6 +234,9 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
of_property_read_bool(np, "snps,fixed-burst");
dma_cfg->mixed_burst =
of_property_read_bool(np, "snps,mixed-burst");
+ of_property_read_u32(np, "snps,burst_len", &dma_cfg->burst_len);
+ if (dma_cfg->burst_len < 0 || dma_cfg->burst_len > 256)
+ dma_cfg->burst_len = 0;
}
plat->force_thresh_dma_mode = of_property_read_bool(np, "snps,force_thresh_dma_mode");
if (plat->force_thresh_dma_mode) {
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 2/3] stmmac: hardware TX COE doesn't work when force_thresh_dma_mode is set
From: Giuseppe CAVALLARO @ 2015-01-22 8:18 UTC (permalink / raw)
To: Sonic Zhang, David S. Miller; +Cc: netdev, adi-buildroot-devel, Sonic Zhang
In-Reply-To: <1421909758-31359-2-git-send-email-sonic.adi@gmail.com>
On 1/22/2015 7:55 AM, Sonic Zhang wrote:
> From: Sonic Zhang <sonic.zhang@analog.com>
>
> Clear the TX COE bit when force_thresh_dma_mode is set even hardware
> dma capability says support.
>
> Tested on BF609.
>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 5edfc8a..7a7385a 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2746,7 +2746,11 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
> priv->plat->enh_desc = priv->dma_cap.enh_desc;
> priv->plat->pmt = priv->dma_cap.pmt_remote_wake_up;
>
> - priv->plat->tx_coe = priv->dma_cap.tx_coe;
> + /* TXCOE doesn't work in thresh DMA mode */
> + if (priv->plat->force_thresh_dma_mode)
> + priv->plat->tx_coe = 0;
> + else
> + priv->plat->tx_coe = priv->dma_cap.tx_coe;
>
> if (priv->dma_cap.rx_coe_type2)
> priv->plat->rx_coe = STMMAC_RX_COE_TYPE2;
>
^ permalink raw reply
* Re: [net PATCH 1/1] drivers: net: cpsw: discard dual emac default vlan configuration
From: Mugunthan V N @ 2015-01-22 8:20 UTC (permalink / raw)
To: Sergei Shtylyov, netdev; +Cc: davem, stable
In-Reply-To: <54BE6573.1040801@cogentembedded.com>
On Tuesday 20 January 2015 07:55 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 1/20/2015 3:25 PM, Mugunthan V N wrote:
>
>> In Dual EMAC, the default vlans are used to segregate rx packets between
>
> VLANs. And RX.
>
>> the ports, so adding the same default vlan to the switch will affect the
>
> VLAN.
>
>> normal packet transfers. So returning error on addition of dual emac
>
> EMAC.
>
>> default vlans.
>
> VLANs.
>
>> Even if emac 0 default port vlan is added to emac 1, it will lead to
>
> EMAC. And VLAN
>
>> break
>
> Breaking.
>
>> dual EMAC port seperations.
>
> Separations.
>
>> Fixes: d9ba8f9 (driver: net: ethernet: cpsw: dual emac interface
>> implementation)
>
> 12 hex digits, please.
>
>> Cc: <stable@vger.kernel.org> # v3.9+
>> Reported-by: Felipe Balbi <balbi@ti.com>
>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>> ---
>> drivers/net/ethernet/ti/cpsw.c | 22 ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>
>> diff --git a/drivers/net/ethernet/ti/cpsw.c
>> b/drivers/net/ethernet/ti/cpsw.c
>> index e068d48..7c32815 100644
>> --- a/drivers/net/ethernet/ti/cpsw.c
>> +++ b/drivers/net/ethernet/ti/cpsw.c
>> @@ -1683,6 +1683,19 @@ static int cpsw_ndo_vlan_rx_add_vid(struct
>> net_device *ndev,
>> if (vid == priv->data.default_vlan)
>> return 0;
>>
>> + if (priv->data.dual_emac) {
>> + /* In dual EMAC, reserved VLAN id should not be used of
>
> s/of/for/, perhaps?
>
>> + * creating vlan interfaces as this can break the dual
>
> s/vlan/VLAN/. Be consistent, please.
>
>> + * EMAC port seperation
>
> Separation.
>
> [...]
Will fix this and resubmit next version.
Regards
Mugunthan V N
^ permalink raw reply
* Re: [PATCH 3/3] stmmac: Add an optional device tree property "snps,burst_len"
From: Giuseppe CAVALLARO @ 2015-01-22 8:20 UTC (permalink / raw)
To: Sonic Zhang, David S. Miller; +Cc: netdev, adi-buildroot-devel, Sonic Zhang
In-Reply-To: <1421909758-31359-3-git-send-email-sonic.adi@gmail.com>
On 1/22/2015 7:55 AM, Sonic Zhang wrote:
> From: Sonic Zhang <sonic.zhang@analog.com>
>
> This property define the AXI bug lenth.
Hello
I can accept this patch for now. So thx :-)
FYI, I will send a set of patches to program the AXI Bus mode
register providing more parameters from DT.
Peppe
>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
> ---
> Documentation/devicetree/bindings/net/stmmac.txt | 1 +
> .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
> index c41afd9..8ca65ce 100644
> --- a/Documentation/devicetree/bindings/net/stmmac.txt
> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
> @@ -43,6 +43,7 @@ Optional properties:
> available this clock is used for programming the Timestamp Addend Register.
> If not passed then the system clock will be used and this is fine on some
> platforms.
> +- snps,burst_len: The AXI burst lenth value of the AXI BUS MODE register.
>
> Examples:
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 3039de2..a20cf0d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -234,6 +234,9 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
> of_property_read_bool(np, "snps,fixed-burst");
> dma_cfg->mixed_burst =
> of_property_read_bool(np, "snps,mixed-burst");
> + of_property_read_u32(np, "snps,burst_len", &dma_cfg->burst_len);
> + if (dma_cfg->burst_len < 0 || dma_cfg->burst_len > 256)
> + dma_cfg->burst_len = 0;
> }
> plat->force_thresh_dma_mode = of_property_read_bool(np, "snps,force_thresh_dma_mode");
> if (plat->force_thresh_dma_mode) {
>
^ permalink raw reply
* Re: netxen: box stuck in netxen_napi_disable()
From: Mike Galbraith @ 2015-01-22 8:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1421909520.3471.2.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, 2015-01-21 at 22:52 -0800, Eric Dumazet wrote:
> On Thu, 2015-01-22 at 07:15 +0100, Mike Galbraith wrote:
> > On Wed, 2015-01-21 at 21:57 -0800, Eric Dumazet wrote:
> >
> > > This driver doesn't follow the NAPI model correctly.
> > >
> > > Please try following fix :
> >
> > Thanks Eric, I'll plug it in in a bit and poke at it. No news is good
> > news, as good as news gets for unknown repeatability bugs that is ;-)
>
> To trigger the bug, all you had to do was to stress the transmit side.
Nope, it's easier than that...
> You could reduce MAX_STATUS_HANDLE from 64 to 4 to trigger it even
> faster.
Wow, that made it amazingly easy to verify.
With MAX_STATUS_HANDLE=4, without your patch applied box hangs as soon
as I bring the network up. Add your patch on top, all is peachy. Fresh
boot, or rmmod/modprobe and network restart, doesn't matter, box works
with your patch, is dead without it.
Here's an ornament for the fix if you think it'll look prettier :)
Reported-and-tested-by: Mike Galbraith <umgwanakikbuti@gmail.com>
-Mike
^ permalink raw reply
* Re: [PATCH 2/3] netlink: Mark dumps as inconsistent which have been interrupted by a resize
From: Herbert Xu @ 2015-01-22 8:49 UTC (permalink / raw)
To: Thomas Graf; +Cc: Ying Xue, davem, kaber, paulmck, netdev, netfilter-devel
In-Reply-To: <20150121121748.GD12570@casper.infradead.org>
On Wed, Jan 21, 2015 at 12:17:48PM +0000, Thomas Graf wrote:
>
> Thanks for the review. We also need to avoid hitting 0 when we overflow
> on a seq increment. The netfilter code is doing this correctly but several
> other users are suffering from this as well.
>
> I'll address this in v2 together with the other discussed changes.
Could you hold off for a bit? I've got some changes that touch
this area that I'd like to push out. Basically I'm trying to
eliminate direct access of rhashtable internals from the existing
users.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/3] netlink: Mark dumps as inconsistent which have been interrupted by a resize
From: Patrick McHardy @ 2015-01-22 8:56 UTC (permalink / raw)
To: Herbert Xu; +Cc: Thomas Graf, Ying Xue, davem, paulmck, netdev, netfilter-devel
In-Reply-To: <20150122084924.GA4720@gondor.apana.org.au>
On 22.01, Herbert Xu wrote:
> On Wed, Jan 21, 2015 at 12:17:48PM +0000, Thomas Graf wrote:
> >
> > Thanks for the review. We also need to avoid hitting 0 when we overflow
> > on a seq increment. The netfilter code is doing this correctly but several
> > other users are suffering from this as well.
> >
> > I'll address this in v2 together with the other discussed changes.
>
> Could you hold off for a bit? I've got some changes that touch
> this area that I'd like to push out. Basically I'm trying to
> eliminate direct access of rhashtable internals from the existing
> users.
Hope it will still be possible, I need it for GC in timeout support for
nftables sets.
Current patch attached for reference.
commit 91a334436d2f8eaa8261251d7d98cb700138f8b6
Author: Patrick McHardy <kaber@trash.net>
Date: Fri Jan 16 18:12:31 2015 +0000
netfilter: nft_hash: add support for timeouts
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/nft_hash.c b/net/netfilter/nft_hash.c
index cba0ad2..e7cf886 100644
--- a/net/netfilter/nft_hash.c
+++ b/net/netfilter/nft_hash.c
@@ -15,6 +15,7 @@
#include <linux/log2.h>
#include <linux/jhash.h>
#include <linux/netlink.h>
+#include <linux/workqueue.h>
#include <linux/rhashtable.h>
#include <linux/netfilter.h>
#include <linux/netfilter/nf_tables.h>
@@ -23,19 +24,47 @@
/* We target a hash table size of 4, element hint is 75% of final size */
#define NFT_HASH_ELEMENT_HINT 3
+struct nft_hash {
+ struct rhashtable ht;
+ struct delayed_work gc_work;
+};
+
struct nft_hash_elem {
struct rhash_head node;
struct nft_set_ext ext;
};
+struct nft_hash_compare_arg {
+ const struct nft_data *key;
+ unsigned int len;
+};
+
+static bool nft_hash_compare(void *ptr, void *arg)
+{
+ const struct nft_hash_elem *he = ptr;
+ struct nft_hash_compare_arg *x = arg;
+
+ if (nft_data_cmp(nft_set_ext_key(&he->ext), x->key, x->len))
+ return false;
+ if (nft_set_ext_exists(&he->ext, NFT_SET_EXT_TIMEOUT) &&
+ time_after_eq(jiffies, *nft_set_ext_timeout(&he->ext)))
+ return false;
+
+ return true;
+}
+
static bool nft_hash_lookup(const struct nft_set *set,
const struct nft_data *key,
const struct nft_set_ext **ext)
{
- struct rhashtable *priv = nft_set_priv(set);
+ struct nft_hash *priv = nft_set_priv(set);
const struct nft_hash_elem *he;
+ struct nft_hash_compare_arg arg = {
+ .key = key,
+ .len = set->klen,
+ };
- he = rhashtable_lookup(priv, key);
+ he = rhashtable_lookup_compare(&priv->ht, key, nft_hash_compare, &arg);
if (he != NULL)
*ext = &he->ext;
@@ -45,10 +74,10 @@ static bool nft_hash_lookup(const struct nft_set *set,
static int nft_hash_insert(const struct nft_set *set,
const struct nft_set_elem *elem)
{
- struct rhashtable *priv = nft_set_priv(set);
+ struct nft_hash *priv = nft_set_priv(set);
struct nft_hash_elem *he = elem->priv;
- rhashtable_insert(priv, &he->node);
+ rhashtable_insert(&priv->ht, &he->node);
return 0;
}
@@ -64,58 +93,43 @@ static void nft_hash_elem_destroy(const struct nft_set *set,
static void nft_hash_remove(const struct nft_set *set,
const struct nft_set_elem *elem)
{
- struct rhashtable *priv = nft_set_priv(set);
+ struct nft_hash *priv = nft_set_priv(set);
+ struct nft_hash_elem *he = elem->cookie;
- rhashtable_remove(priv, elem->cookie);
+ rhashtable_remove(&priv->ht, &he->node);
synchronize_rcu();
kfree(elem->cookie);
}
-struct nft_compare_arg {
- const struct nft_set *set;
- struct nft_set_elem *elem;
-};
-
-static bool nft_hash_compare(void *ptr, void *arg)
-{
- struct nft_hash_elem *he = ptr;
- struct nft_compare_arg *x = arg;
-
- if (!nft_data_cmp(nft_set_ext_key(&he->ext), &x->elem->key,
- x->set->klen)) {
- x->elem->cookie = he;
- x->elem->priv = he;
- return true;
- }
-
- return false;
-}
-
static int nft_hash_get(const struct nft_set *set, struct nft_set_elem *elem)
{
- struct rhashtable *priv = nft_set_priv(set);
- struct nft_compare_arg arg = {
- .set = set,
- .elem = elem,
+ struct nft_hash *priv = nft_set_priv(set);
+ struct nft_hash_elem *he;
+ struct nft_hash_compare_arg arg = {
+ .key = &elem->key,
+ .len = set->klen,
};
- if (rhashtable_lookup_compare(priv, &elem->key,
- &nft_hash_compare, &arg))
+ he = rhashtable_lookup_compare(&priv->ht, &elem->key,
+ nft_hash_compare, &arg);
+ if (he != NULL) {
+ elem->cookie = he;
+ elem->priv = he;
return 0;
-
+ }
return -ENOENT;
}
static void nft_hash_walk(const struct nft_ctx *ctx, const struct nft_set *set,
struct nft_set_iter *iter)
{
- struct rhashtable *priv = nft_set_priv(set);
+ struct nft_hash *priv = nft_set_priv(set);
const struct bucket_table *tbl;
struct nft_hash_elem *he;
struct nft_set_elem elem;
unsigned int i;
- tbl = rht_dereference_rcu(priv->tbl, priv);
+ tbl = rht_dereference_rcu(priv->ht.tbl, &priv->ht);
for (i = 0; i < tbl->size; i++) {
struct rhash_head *pos;
@@ -134,16 +148,48 @@ cont:
}
}
+static void nft_hash_gc(struct work_struct *work)
+{
+ const struct nft_set *set;
+ const struct bucket_table *tbl;
+ struct rhash_head *pos, *next;
+ struct nft_hash_elem *he;
+ struct nft_hash *priv;
+ unsigned long timeout;
+ unsigned int i;
+
+ priv = container_of(work, struct nft_hash, gc_work.work);
+ set = (void *)priv - offsetof(struct nft_set, data);
+
+ mutex_lock(&priv->ht.mutex);
+ tbl = rht_dereference(priv->ht.tbl, &priv->ht);
+ for (i = 0; i < tbl->size; i++) {
+ rht_for_each_entry_safe(he, pos, next, tbl, i, node) {
+ if (!nft_set_ext_exists(&he->ext, NFT_SET_EXT_TIMEOUT))
+ continue;
+ timeout = *nft_set_ext_timeout(&he->ext);
+ if (time_before(jiffies, timeout))
+ continue;
+
+ rhashtable_remove(&priv->ht, &he->node);
+ nft_hash_elem_destroy(set, he);
+ }
+ }
+ mutex_unlock(&priv->ht.mutex);
+
+ queue_delayed_work(system_power_efficient_wq, &priv->gc_work, HZ);
+}
+
static unsigned int nft_hash_privsize(const struct nlattr * const nla[])
{
- return sizeof(struct rhashtable);
+ return sizeof(struct nft_hash);
}
static int nft_hash_init(const struct nft_set *set,
const struct nft_set_desc *desc,
const struct nlattr * const tb[])
{
- struct rhashtable *priv = nft_set_priv(set);
+ struct nft_hash *priv = nft_set_priv(set);
struct rhashtable_params params = {
.nelem_hint = desc->size ? : NFT_HASH_ELEMENT_HINT,
.head_offset = offsetof(struct nft_hash_elem, node),
@@ -153,30 +199,42 @@ static int nft_hash_init(const struct nft_set *set,
.grow_decision = rht_grow_above_75,
.shrink_decision = rht_shrink_below_30,
};
+ int err;
- return rhashtable_init(priv, ¶ms);
+ err = rhashtable_init(&priv->ht, ¶ms);
+ if (err < 0)
+ return err;
+
+ INIT_DEFERRABLE_WORK(&priv->gc_work, nft_hash_gc);
+ if (set->flags & NFT_SET_TIMEOUT)
+ queue_delayed_work(system_power_efficient_wq,
+ &priv->gc_work, HZ);
+
+ return 0;
}
static void nft_hash_destroy(const struct nft_set *set)
{
- struct rhashtable *priv = nft_set_priv(set);
+ struct nft_hash *priv = nft_set_priv(set);
const struct bucket_table *tbl;
struct nft_hash_elem *he;
struct rhash_head *pos, *next;
unsigned int i;
+ cancel_delayed_work_sync(&priv->gc_work);
+
/* Stop an eventual async resizing */
- priv->being_destroyed = true;
- mutex_lock(&priv->mutex);
+ priv->ht.being_destroyed = true;
+ mutex_lock(&priv->ht.mutex);
- tbl = rht_dereference(priv->tbl, priv);
+ tbl = rht_dereference(priv->ht.tbl, &priv->ht);
for (i = 0; i < tbl->size; i++) {
rht_for_each_entry_safe(he, pos, next, tbl, i, node)
nft_hash_elem_destroy(set, he);
}
- mutex_unlock(&priv->mutex);
+ mutex_unlock(&priv->ht.mutex);
- rhashtable_destroy(priv);
+ rhashtable_destroy(&priv->ht);
}
static bool nft_hash_estimate(const struct nft_set_desc *desc, u32 features,
@@ -187,9 +245,11 @@ static bool nft_hash_estimate(const struct nft_set_desc *desc, u32 features,
esize = sizeof(struct nft_hash_elem);
if (features & NFT_SET_MAP)
esize += sizeof(struct nft_data);
+ if (features & NFT_SET_TIMEOUT)
+ esize += sizeof(unsigned long);
if (desc->size) {
- est->size = sizeof(struct rhashtable) +
+ est->size = sizeof(struct nft_hash) +
roundup_pow_of_two(desc->size * 4 / 3) *
sizeof(struct nft_hash_elem *) +
desc->size * esize;
@@ -218,7 +278,7 @@ static struct nft_set_ops nft_hash_ops __read_mostly = {
.remove = nft_hash_remove,
.lookup = nft_hash_lookup,
.walk = nft_hash_walk,
- .features = NFT_SET_MAP,
+ .features = NFT_SET_MAP | NFT_SET_TIMEOUT,
.owner = THIS_MODULE,
};
@@ -238,3 +298,4 @@ module_exit(nft_hash_module_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Patrick McHardy <kaber@trash.net>");
MODULE_ALIAS_NFT_SET();
+
^ permalink raw reply related
* Re: [PATCH 3/3] netlink: Lock out table resizes while dumping Netlink sockets
From: Thomas Graf @ 2015-01-22 9:05 UTC (permalink / raw)
To: Herbert Xu
Cc: Patrick McHardy, davem, paulmck, ying.xue, netdev,
netfilter-devel, Eric Dumazet
In-Reply-To: <20150122072030.GA4039@gondor.apana.org.au>
On 01/22/15 at 06:20pm, Herbert Xu wrote:
> On Thu, Jan 22, 2015 at 05:35:01PM +1100, Herbert Xu wrote:
> > On Wed, Jan 21, 2015 at 10:23:46AM +0000, Thomas Graf wrote:
> > >
> > > The usage will be identical to how __inet_lookup_listener() uses it.
> > > If at the end of the lookup, we ended up in a different table than
> > > we started, the lookup is restarted as an entry has moved to another
> > > table while we were moving over it.
> >
> > Who uses this stuff apart from ip_dynaddr?
>
> OK it's there for fast socket recycling. Given that and the fact
> that everyone seems to be happy with restarting the dump after a
> resize, I think we should just go with that.
>
> Anybody who wants a better walk can always implement their own
> data structure outside of rhashtable.
What did you think of the idea to let the user store the walker
bit for rhashtable?
^ permalink raw reply
* Re: [PATCH 2/3] netlink: Mark dumps as inconsistent which have been interrupted by a resize
From: Herbert Xu @ 2015-01-22 9:22 UTC (permalink / raw)
To: Patrick McHardy
Cc: Thomas Graf, Ying Xue, davem, paulmck, netdev, netfilter-devel
In-Reply-To: <20150122085643.GB4037@acer.localdomain>
On Thu, Jan 22, 2015 at 08:56:44AM +0000, Patrick McHardy wrote:
>
> Hope it will still be possible, I need it for GC in timeout support for
> nftables sets.
This should be able to use the same walk that you're currently
using for dump once we add the restart, no?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH net 0/2] Two cls_bpf fixes
From: Daniel Borkmann @ 2015-01-22 9:41 UTC (permalink / raw)
To: davem; +Cc: jiri, netdev
Found them while doing a review on act_bpf and going over the
cls_bpf code again. Will also address the first issue in act_bpf
as it needs to be fixed there, too.
Thanks!
Daniel Borkmann (2):
net: cls_bpf: fix size mismatch on filter preparation
net: cls_bpf: fix auto generation of per list handles
net/sched/cls_bpf.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
--
1.7.11.7
^ permalink raw reply
* [PATCH net 1/2] net: cls_bpf: fix size mismatch on filter preparation
From: Daniel Borkmann @ 2015-01-22 9:41 UTC (permalink / raw)
To: davem; +Cc: jiri, netdev
In-Reply-To: <1421919662-21066-1-git-send-email-dborkman@redhat.com>
In cls_bpf_modify_existing(), we read out the number of filter blocks,
do some sanity checks, allocate a block on that size, and copy over the
BPF instruction blob from user space, then pass everything through the
classic BPF checker prior to installation of the classifier.
We should reject mismatches here, there are 2 scenarios: the number of
filter blocks could be smaller than the provided instruction blob, so
we do a partial copy of the BPF program, and thus the instructions will
either be rejected from the verifier or a valid BPF program will be run;
in the other case, we'll end up copying more than we're supposed to,
and most likely the trailing garbage will be rejected by the verifier
as well (i.e. we need to fit instruction pattern, ret {A,K} needs to be
last instruction, load/stores must be correct, etc); in case not, we
would leak memory when dumping back instruction patterns. The code should
have only used nla_len() as Dave noted to avoid this from the beginning.
Anyway, lets fix it by rejecting such load attempts.
Fixes: 7d1d65cb84e1 ("net: sched: cls_bpf: add BPF-based classifier")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
---
net/sched/cls_bpf.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c
index 84c8219..49e5fa8 100644
--- a/net/sched/cls_bpf.c
+++ b/net/sched/cls_bpf.c
@@ -180,6 +180,11 @@ static int cls_bpf_modify_existing(struct net *net, struct tcf_proto *tp,
}
bpf_size = bpf_len * sizeof(*bpf_ops);
+ if (bpf_size != nla_len(tb[TCA_BPF_OPS])) {
+ ret = -EINVAL;
+ goto errout;
+ }
+
bpf_ops = kzalloc(bpf_size, GFP_KERNEL);
if (bpf_ops == NULL) {
ret = -ENOMEM;
--
1.7.11.7
^ permalink raw reply related
* [PATCH net 2/2] net: cls_bpf: fix auto generation of per list handles
From: Daniel Borkmann @ 2015-01-22 9:41 UTC (permalink / raw)
To: davem; +Cc: jiri, netdev
In-Reply-To: <1421919662-21066-1-git-send-email-dborkman@redhat.com>
When creating a bpf classifier in tc with priority collisions and
invoking automatic unique handle assignment, cls_bpf_grab_new_handle()
will return a wrong handle id which in fact is non-unique. Usually
altering of specific filters is being addressed over major id, but
in case of collisions we result in a filter chain, where handle ids
address individual cls_bpf_progs inside the classifier.
Issue is, in cls_bpf_grab_new_handle() we probe for head->hgen handle
in cls_bpf_get() and in case we found a free handle, we're supposed
to use exactly head->hgen. In case of insufficient numbers of handles,
we bail out later as handle id 0 is not allowed.
Fixes: 7d1d65cb84e1 ("net: sched: cls_bpf: add BPF-based classifier")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
---
net/sched/cls_bpf.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c
index 49e5fa8..f59adf8 100644
--- a/net/sched/cls_bpf.c
+++ b/net/sched/cls_bpf.c
@@ -220,15 +220,21 @@ static u32 cls_bpf_grab_new_handle(struct tcf_proto *tp,
struct cls_bpf_head *head)
{
unsigned int i = 0x80000000;
+ u32 handle;
do {
if (++head->hgen == 0x7FFFFFFF)
head->hgen = 1;
} while (--i > 0 && cls_bpf_get(tp, head->hgen));
- if (i == 0)
+
+ if (unlikely(i == 0)) {
pr_err("Insufficient number of handles\n");
+ handle = 0;
+ } else {
+ handle = head->hgen;
+ }
- return i;
+ return handle;
}
static int cls_bpf_change(struct net *net, struct sk_buff *in_skb,
--
1.7.11.7
^ permalink raw reply related
* [net PATCH v2 1/1] drivers: net: cpsw: discard dual emac default vlan configuration
From: Mugunthan V N @ 2015-01-22 9:49 UTC (permalink / raw)
To: netdev; +Cc: davem, Mugunthan V N, stable
In Dual EMAC, the default VLANs are used to segregate Rx packets between
the ports, so adding the same default VLAN to the switch will affect the
normal packet transfers. So returning error on addition of dual EMAC
default VLANs.
Even if EMAC 0 default port VLAN is added to EMAC 1, it will lead to
break dual EMAC port separations.
Fixes: d9ba8f9e6298 (driver: net: ethernet: cpsw: dual emac interface implementation)
Cc: <stable@vger.kernel.org> # v3.9+
Reported-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
Changes from initial version:
* Fixed typo errors in comments and no code changes.
---
drivers/net/ethernet/ti/cpsw.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index e068d48..a39131f 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1683,6 +1683,19 @@ static int cpsw_ndo_vlan_rx_add_vid(struct net_device *ndev,
if (vid == priv->data.default_vlan)
return 0;
+ if (priv->data.dual_emac) {
+ /* In dual EMAC, reserved VLAN id should not be used for
+ * creating VLAN interfaces as this can break the dual
+ * EMAC port separation
+ */
+ int i;
+
+ for (i = 0; i < priv->data.slaves; i++) {
+ if (vid == priv->slaves[i].port_vlan)
+ return -EINVAL;
+ }
+ }
+
dev_info(priv->dev, "Adding vlanid %d to vlan filter\n", vid);
return cpsw_add_vlan_ale_entry(priv, vid);
}
@@ -1696,6 +1709,15 @@ static int cpsw_ndo_vlan_rx_kill_vid(struct net_device *ndev,
if (vid == priv->data.default_vlan)
return 0;
+ if (priv->data.dual_emac) {
+ int i;
+
+ for (i = 0; i < priv->data.slaves; i++) {
+ if (vid == priv->slaves[i].port_vlan)
+ return -EINVAL;
+ }
+ }
+
dev_info(priv->dev, "removing vlanid %d from vlan filter\n", vid);
ret = cpsw_ale_del_vlan(priv->ale, vid, 0);
if (ret != 0)
--
2.2.1.62.g3f15098
^ permalink raw reply related
* RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous mode control
From: David Laight @ 2015-01-22 9:50 UTC (permalink / raw)
To: 'Skidmore, Donald C', Hiroshi Shimamoto, Bjørn Mork
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Choi, Sy Jong, linux-kernel@vger.kernel.org, Hayato Momma
In-Reply-To: <F6FB0E698C9B3143BDF729DF222866469129BC03@ORSMSX110.amr.corp.intel.com>
From: Skidmore, Donald C
> > > From: Hiroshi Shimamoto
> > > > My concern is what is the real issue that VF multicast promiscuous mode
> > can cause.
> > > > I think there is the 4k entries to filter multicast address, and the
> > > > current ixgbe/ixgbevf can turn all bits on from VM. That is almost same as
> > enabling multicast promiscuous mode.
> > > > I mean that we can receive all multicast addresses by an onerous
> > operation in untrusted VM.
> > > > I think we should clarify what is real security issue in this context.
> > >
> > > If you are worried about passing un-enabled multicasts to users then
> > > what about doing a software hash of received multicasts and checking
> > > against an actual list of multicasts enabled for that hash entry.
> > > Under normal conditions there is likely to be only a single address to check.
> > >
> > > It may (or may not) be best to use the same hash as any hashing
> > > hardware filter uses.
> >
> > thanks for the comment. But I don't think that is the point.
> >
> > I guess, introducing VF multicast promiscuous mode seems to add new
> > privilege to peek every multicast packet in VM and that doesn't look good.
> > On the other hand, I think that there has been the same privilege in the
> > current ixgbe/ixgbevf implementation already. Or I'm reading the code
> > wrongly.
> > I'd like to clarify what is the issue of allowing to receive all multicast packets.
>
> Allowing a VM to give itself the privilege of seeing every multicast packet
> could be seen as a hole in VM isolation.
> Now if the host system allows this policy I don't see this as an issue as
> someone specifically allowed this to happen and then must not be concerned.
> We could even log that it has occurred, which I believe your patch did do.
> The issue is also further muddied, as you mentioned above, since some of
> these multicast packets are leaking anyway (the HW currently uses a 12 bit mask).
> It's just that this change would greatly enlarge that hole from a fraction to
> all multicast packets.
Why does it have anything to do with VM isolation?
Isn't is just the same as if the VM were connected directly to the
ethernet cable?
David
^ permalink raw reply
* Re: [PATCH 3/3] netlink: Lock out table resizes while dumping Netlink sockets
From: Herbert Xu @ 2015-01-22 9:50 UTC (permalink / raw)
To: Thomas Graf
Cc: Patrick McHardy, davem, paulmck, ying.xue, netdev,
netfilter-devel, Eric Dumazet
In-Reply-To: <20150122090518.GA30859@casper.infradead.org>
On Thu, Jan 22, 2015 at 09:05:18AM +0000, Thomas Graf wrote:
>
> What did you think of the idea to let the user store the walker
> bit for rhashtable?
The problem with that is the bit is needed to indicate special
walker objects which the user won't be able to decipher (see
xfrm_state_walk).
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: subtle change in behavior with tun driver
From: Michael S. Tsirkin @ 2015-01-22 9:53 UTC (permalink / raw)
To: Ani Sinha; +Cc: netdev@vger.kernel.org
In-Reply-To: <CAOxq_8NJdFV6fbVh-uns3bpaKNjtcGEOEDb4U3_rX3d+w85SWQ@mail.gmail.com>
On Wed, Jan 21, 2015 at 02:36:17PM -0800, Ani Sinha wrote:
> Hi guys :
>
> Commit 5d097109257c03 ("tun: only queue packets on device") seems to
> have introduced a subtle change in behavior in the tun driver in the
> default (non IFF_ONE_QUEUE) case. Previously when the queues got full
> and eventually sk_wmem_alloc of the socket exceeded sk_sndbuf value,
> the user would be given a feedback by returning EAGAIN from sendto()
> etc. That way, the user could retry sending the packet again.
This behaviour is common, but by no means guaranteed.
For example, if socket buffer size is large enough,
packets are small enough, or there are multiple sockets
transmitting through tun, packets would previously
accumulate in qdisc, followed by packet drops
without EAGAIN.
> Unfortunately, with this new default single queue mode, the driver
> silently drops the packet when the device queue is full without giving
> userland any feedback. This makes it appear to userland as though the
> packet was transmitted successfully. It seems there is a semantic
> change in the driver with this commit.
>
> If the receiving process gets stuck for a short interval and is unable
> to drain packets and then restarts again, one might see strange packet
> drops in the kernel without getting any error back on the sender's
> side. It kind of feels wrong.
>
> Any thoughts?
>
> Ani
Unfortunately - since it's pretty common for unpriveledged userspace to
drive the tun device - blocking the queue indefinitely as was done
previously leads to deadlocks for some apps, this was deemed worse than
some performance degradation.
As a simple work-around, if you want packets to accumulate in the qdisc,
it's easy to implement by using a non work conserving qdisc.
Set the limits to match the speed at which your application
is able to consume the packets.
I've been thinking about using some kind of watchdog to
make it safe to put the old non IFF_ONE_QUEUE semantics back,
unfortunately due to application being able to consume packets at the
same time it's not trivial to do in a non-racy way.
--
MST
^ permalink raw reply
* [PATCH net-next 0/2] Minor cls_basic, act_bpf update
From: Daniel Borkmann @ 2015-01-22 9:58 UTC (permalink / raw)
To: davem; +Cc: jiri, netdev
Daniel Borkmann (2):
net: cls_basic: return from walking on match in basic_get
net: act_bpf: fix size mismatch on filter preparation
net/sched/act_bpf.c | 3 +++
net/sched/cls_basic.c | 7 +++++--
2 files changed, 8 insertions(+), 2 deletions(-)
--
1.7.11.7
^ permalink raw reply
* [PATCH net-next 2/2] net: act_bpf: fix size mismatch on filter preparation
From: Daniel Borkmann @ 2015-01-22 9:58 UTC (permalink / raw)
To: davem; +Cc: jiri, netdev
In-Reply-To: <1421920699-26556-1-git-send-email-dborkman@redhat.com>
Similarly as in cls_bpf, also this code needs to reject mismatches.
Reference: http://article.gmane.org/gmane.linux.network/347406
Fixes: d23b8ad8ab23 ("tc: add BPF based action")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
---
net/sched/act_bpf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
index 1bd257e..82c5d7f 100644
--- a/net/sched/act_bpf.c
+++ b/net/sched/act_bpf.c
@@ -122,6 +122,9 @@ static int tcf_bpf_init(struct net *net, struct nlattr *nla,
return -EINVAL;
bpf_size = bpf_num_ops * sizeof(*bpf_ops);
+ if (bpf_size != nla_len(tb[TCA_ACT_BPF_OPS]))
+ return -EINVAL;
+
bpf_ops = kzalloc(bpf_size, GFP_KERNEL);
if (!bpf_ops)
return -ENOMEM;
--
1.7.11.7
^ permalink raw reply related
* [PATCH net-next 1/2] net: cls_basic: return from walking on match in basic_get
From: Daniel Borkmann @ 2015-01-22 9:58 UTC (permalink / raw)
To: davem; +Cc: jiri, netdev, Thomas Graf
In-Reply-To: <1421920699-26556-1-git-send-email-dborkman@redhat.com>
As soon as we've found a matching handle in basic_get(), we can
return it. There's no need to continue walking until the end of
a filter chain, since they are unique anyway.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Cc: Thomas Graf <tgraf@suug.ch>
---
net/sched/cls_basic.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/sched/cls_basic.c b/net/sched/cls_basic.c
index 5aed341..fc399db 100644
--- a/net/sched/cls_basic.c
+++ b/net/sched/cls_basic.c
@@ -65,9 +65,12 @@ static unsigned long basic_get(struct tcf_proto *tp, u32 handle)
if (head == NULL)
return 0UL;
- list_for_each_entry(f, &head->flist, link)
- if (f->handle == handle)
+ list_for_each_entry(f, &head->flist, link) {
+ if (f->handle == handle) {
l = (unsigned long) f;
+ break;
+ }
+ }
return l;
}
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH net-next 1/2] net: cls_basic: return from walking on match in basic_get
From: Thomas Graf @ 2015-01-22 10:01 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, jiri, netdev
In-Reply-To: <1421920699-26556-2-git-send-email-dborkman@redhat.com>
On 01/22/15 at 10:58am, Daniel Borkmann wrote:
> As soon as we've found a matching handle in basic_get(), we can
> return it. There's no need to continue walking until the end of
> a filter chain, since they are unique anyway.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Acked-by: Jiri Pirko <jiri@resnulli.us>
> Cc: Thomas Graf <tgraf@suug.ch>
Acked-by: Thomas Graf <tgraf@suug.ch>
^ permalink raw reply
* Re: [PATCH 2/3] netlink: Mark dumps as inconsistent which have been interrupted by a resize
From: Patrick McHardy @ 2015-01-22 10:07 UTC (permalink / raw)
To: Herbert Xu; +Cc: Thomas Graf, Ying Xue, davem, paulmck, netdev, netfilter-devel
In-Reply-To: <20150122092212.GA5035@gondor.apana.org.au>
On 22.01, Herbert Xu wrote:
> On Thu, Jan 22, 2015 at 08:56:44AM +0000, Patrick McHardy wrote:
> >
> > Hope it will still be possible, I need it for GC in timeout support for
> > nftables sets.
>
> This should be able to use the same walk that you're currently
> using for dump once we add the restart, no?
Yes, should even be possible to use the walk function with some small
adjustments.
^ 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