Re: [nft PATCH] make cache persistent if local entries were added

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Oct 20, 2018 at 12:24:06PM +0200, Phil Sutter wrote:
> JSON API as well as nft CLI allow to run multiple commands within the
> same batch. Depending on the local cache state, a later command may
> trigger a cache update which removes the local entry added by an earlier
> command.
> 
> To overcome this, introduce a special genid value to set when local
> entries are added to the cache which blocks all cache updates until the
> batch has been committed to the kernel.

Probably we can make sure we issue a cache_update() by when we call
chain_add_hash(), before adding the local object to the cache, then
lock it? Or add assert() to _add_hash() functions to make sure cache
is up to date? We need a valid cache before we can lock it, right?

Do you have several examples that are triggering the problem that we
can place in the test regression infrastructure?

Thanks!

> Signed-off-by: Phil Sutter <phil@xxxxxx>
> ---
>  include/nftables.h |  2 ++
>  include/rule.h     | 12 ++++++++----
>  src/evaluate.c     |  6 +++---
>  src/libnftables.c  |  2 ++
>  src/monitor.c      |  4 ++--
>  src/rule.c         | 17 +++++++++++++----
>  6 files changed, 30 insertions(+), 13 deletions(-)
> 
> diff --git a/include/nftables.h b/include/nftables.h
> index 25e78c80df7e0..47d2c2bb036cc 100644
> --- a/include/nftables.h
> +++ b/include/nftables.h
> @@ -37,6 +37,8 @@ struct nft_cache {
>  	struct list_head	list;
>  	uint32_t		seqnum;
>  };
> +#define CACHE_LOCK_GENID	(uint16_t)-1

This one is a valid cache number in the kernel, right? IIRC, it's zero
the one that is never used.



[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux