On Mon, Jun 17, 2019 at 06:28:40PM +0200, Pablo Neira Ayuso wrote:
> On Mon, Jun 17, 2019 at 06:11:04PM +0200, Phil Sutter wrote:
> > Hi,
> >
> > On Mon, Jun 17, 2019 at 02:25:16PM +0200, Pablo Neira Ayuso wrote:
> > [...]
> > > -int cache_evaluate(struct nft_ctx *nft, struct list_head *cmds)
> > > +unsigned int cache_evaluate(struct nft_ctx *nft, struct list_head *cmds)
> > > {
> > > - unsigned int echo_completeness = CMD_INVALID;
> > > - unsigned int completeness = CMD_INVALID;
> > > + unsigned int flags = NFT_CACHE_EMPTY;
> > > struct cmd *cmd;
> > >
> > > list_for_each_entry(cmd, cmds, list) {
> > > switch (cmd->op) {
> > > case CMD_ADD:
> > > case CMD_INSERT:
> > > - case CMD_REPLACE:
> > > - if (nft_output_echo(&nft->output))
> > > - echo_completeness = cmd->op;
> > > -
> > > + flags |= NFT_CACHE_TABLE |
> > > + NFT_CACHE_CHAIN |
> > > + NFT_CACHE_SET |
> > > + NFT_CACHE_FLOWTABLE |
> > > + NFT_CACHE_OBJECT;
> >
> > This means we start fetching the cache for simple 'add rule' commands
> > again, right?
>
> We need these for references to sets, eg.
>
> add rule x y ip saddr @x
>
> same for other flowtable and object.
Oh, right. I got that wrong - old code is always fetching the above
items unless there's no ruleset in kernel (i.e., returned genid is 0).
I confused that with fetching rules which at some point started to
happen by accident with my changes.
> We should not use NFT_CACHE_RULE in this case, if this is what you
> suggest.
No, quite the opposite: I thought we could get by without fetching
anything from kernel at all.
Yet now I wonder why the handle guessing stops working, because the
above can't be the cause of it.
Cheers, Phil
