Re: [PATCH nft 2/2] evaluate: restrict allowed subtypes of concatenations

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Fri, Apr 11, 2025 at 07:52:01AM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
[...]
> > Not related, but if goal is to provide context then I also need more
> > explicit context hints for bitfield payload and bitwise expressions
> > where the evaluation needs to be different depending on where the
> > expression is located (not the same if the expression is either used
> > as selector or as lhs/rhs of assignment).
> > 
> > I don't know yet how such new context enum to modify evaluation
> > behaviour will look, so we can just use recursion.list by now, I don't
> > want to block this fix.
>
> OK.  Yes, it would also work if there was some different "where am I"
> indicator, e.g. if (ctx->expr_side == CTX_EXPR_LHS) or whatever.

Exactly, something like this.

> This fix isn't urgent, we can keep it back and come back to this
> if you prefer to first work on the ctx hint extensions.

I am in the need for such a context for payload/meta statements.

        meta mark set ip dscp map ...
                      ^^^^^^^

in this case, ip dscp needs to be evaluated as a key for lookups,
shift can probably be removed for implicit maps.

While in this case:

        meta mark set ip dscp
                      ^^^^^^^

in this case, ip dscp needs the shift.

Then, there is:

        ip dscp set meta mark
        ^^^^^^^

(note: this is not yet supported)

where ip dscp needs to expand to 16-bit because of the kernel
checksum routine requirements.

They are all payload expressions, but evaluation needs to be slightly
different depending on how the expression is used.

This context should help disentangle evaluation, evaluation is making
assumption based on subtle hints, I think there is a need for more
explicit hints.

We can revisit in a few weeks, otherwise take this.