On Wed, Aug 29, 2018 at 01:16:25PM +0200, Pablo Neira Ayuso wrote:
> Hi Phil,
>
> On Wed, Aug 29, 2018 at 11:52:09AM +0200, Phil Sutter wrote:
> > Hi,
> >
> > I found constellations in which userspace ruleset cache maintenance
> > causes headaches. A "simple" case is this:
> >
> > | # nft flush ruleset
> > | # nft -i
> > | nft> add table ip t
> > | nft> list ruleset
> > | table ip t {
> > | }
> > | table ip t {
> > | }
Hm, wait. See below.
[...]
> > Here's a more complex one:
> >
> > | # ./src/nft -i
> > | nft> list ruleset
> > | nft> add table ip t
> > | nft> add table ip t2 ; add chain ip t2 c
> > | Error: Could not process rule: Table 't2' does not exist
> > | add table ip t2 ; add chain ip t2 c
> > | ^^^^^^^^^^^^^^^^^^
> >
> > The first call to 'list ruleset' causes cache->genid to be non-zero.
> > Adding the first table does not trigger a cache update, but kernel's
> > genid increments as a result.
Looks like we should be flushing after 'list ruleset' in interactive
mode? In these two examples it looks like there's a missing flush
somewhere in the interactive mode to me.
I mean, we don't know when the next command comes, so doing fine grain
tracking in this case makes no sense.
Let me know, thanks.
