Re: [PATCH nf-next v10 0/6] ipset: replace internal hash table with rhashtable

[Jozsef Kadlecsik <kadlec@netfilter.org>]

Hi Florian,

On Thu, 12 Nov 2026, Florian Westphal wrote:

> I pushed a few of the test updates to ipset.git, but not this 
> 3-part-series:
> 
> https://patchwork.ozlabs.org/project/netfilter-devel/patch/20261111101603.22698-1-fw@strlen.de/
> 
> First one passes on either rhashtable branch or main, but I'm not sure
> it should :-)
> 
> Resp. I'm not sure what the contract/expected behavior of net,iface set 
> type is when the address matches the net/mask entry, but the interface 
> doesn't.  I followed existing behaviour, so that test would enshrine 
> that: it stops matching more candidates.

Hm, it shouldn't. The expected behaviour is as follows: if the net/mask 
entry matches but the interface not, then the code should continue trying 
to find matching entries but just with the same mask value and not with 
other ones. That way the same net/mask entry behind multiple interfaces is 
supported and matched.

In the original code the "multi" parameter handles the case: in the 
net,iface matching function (i.e. hash_netiface[46]_data_equal()) it is 
set to true if net/mask matches and in the outer generic matching function 
in mtype_test_cidrs() it is taken into account to break the loop of trying 
to match further in the ordered list of possible mask values in the set.

> I'd prefer if you could double-check that the semantics that the test
> is checking are sensible/correct.
> 
> 2 and 3 fail on main, in both cases I think these are bugs in
> the existing implementation.

I'll have a look at it.

Best regards,
Jozsef
-- 
E-mail : kadlec@netfilter.org, kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
Address: Wigner Research Centre for Physics
         H-1525 Budapest 114, POB. 49, Hungary