Re: [PATCH nftables 8/8] test: py: add tests for shifted nat port-ranges

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

On Tue, Apr 25, 2023 at 08:51:43PM +0100, Jeremy Sowden wrote:
> On 2023-04-12, at 13:06:02 +0200, Pablo Neira Ayuso wrote:
> > On Tue, Apr 11, 2023 at 01:21:40PM +0100, Jeremy Sowden wrote:
> > > On 2023-03-26, at 22:39:42 +0200, Pablo Neira Ayuso wrote:
> > > > Jeremy, may I suggest you pick up on the bitwise _SREG2 support?
> > > > I will post a v4 with small updates for ("mark statement support
> > > > for non-constant expression") tomorrow. Probably you don't need
> > > > the new AND and OR operations for this? Only the a new _SREG2 to
> > > > specify that input comes from non-constant?
> > > 
> > > Just to clarify, do you want just the `_SREG2` infrastructure from
> > > the last patch series but without the new bitwise ops?  That is to
> > > say it would be possible to send two operands to the kernel in
> > > registers, but no use would be made of it (yet).  Or are you
> > > proposing to update the existing mask-and-xor ops to send right hand
> > > operands via registers?
> > 
> > I mean, would it be possible to add a NFT_BITWISE_BOOL variant that
> > takes _SREG2 via select_ops?
> 
> In an earlier version, instead of adding new boolean ops, I added
> support for passing the mask and xor arguments in registers:
> 
>   https://lore.kernel.org/netfilter-devel/20200224124931.512416-1-jeremy@azazel.net/
> 
> Doing the same thing with one extra register is straightforward for AND
> and XOR:
> 
>   AND(x, y) = (x & y) ^ 0
>   XOR(x, y) = (x & 1) ^ y
> 
> since we can pass y in _SREG2 and 0 in _XOR for AND, and 1 in _MASK and
> y in _SREG2 for XOR.  For OR:
> 
>   OR(x, y) = (x & ~y) ^ y
> 
> it's a bit more complicated.  Instead of getting both the mask and xor
> arguments from user space, we need to do something like passing y in
> _SREG2 alone, and then constructing the bitwise negation in the kernel.
>
> Obviously, this means that the kernel is no longer completely agnostic
> about the sorts of mask-and-xor expressions user space may send.
>
> Since that is the case, we could go further and just perform the
> original ope- rations.  Thus if we get an boolean op with an _SREG2
> argument:
> 
>   * if there is an _XOR of 0, compute:
> 
>     _SREG & _SREG2
> 
>   * if there is a _MASK of 1, compute:
> 
>     _SREG ^ _SREG2
> 
>   * if there are no _MASK or _XOR arguments, compute:
> 
>     _SREG | _SREG2

OK, if my understanding is correct, these are the two options:

1) Infer from arguments the type of operation.
2) Have explicit NFT_BITWISE_{AND,OR,XOR} operations.

If so, I think it is better to stick to your original patch, where
explicit bitwise operations NFT_BITWISE_{_AND,_OR,_XOR} are added
(which is what you proposed last time IIRC).

Thanks for explaining.