Re: [PATCH net-next 1/3] netfilter: Make xt_table::private RCU protected.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2025-02-17 16:35:48 [+0100], Florian Westphal wrote:
> 
> > What are the counters used in userland for? I've seen that they are
> > copied but did not understood why.
> >   iptables-legacy -A INPUT -j ACCEPT
> > ends up in xt_replace_table() but iptables-nft doesn't. Different
> > interface, better design? Or I just used legacy and now it is considered
> > as the only?
> 
> iptables-nft uses the nftables netlink API, I don't think it suffers
> from the preempt_rt issues you're resolving in the setsockopt api.

The thing is it there so I would like to see fixed one way or another.
But if this is the old API, it means the counter change in #3 is not
beneficial to iptables-nft.

> It won't go anywhere near xt_replace_table and it doesn't use the
> xtables binary format on the user/kernel api side.
> 
> > I see two invocations on iptables-legacy-restore.
> > 
> > But the question remains: Why copy counters after replacing the rule
> > set?
> 
> Good question.  What I can gather from
> https://git.netfilter.org/iptables/tree/libiptc/libiptc.c#n2597
> 
> After replace we get copy of the old counters, depending on mode
> we can force-update counters post-replace in kernel, via
> 
> 	ret = setsockopt(handle->sockfd, TC_IPPROTO, SO_SET_ADD_COUNTERS,
> 			 newcounters, counterlen);
> 
> I suspect this is whats used by 'iptables -L -v -Z INPUT'.
> But I don't know if anyone uses this in practice.

Oh. Wonderful. So even if skip counter updates after pointer
replacement, the damage is very limited.

> Maybe Pablo remembers the details, this is ancient code by kernel
> standards.
> 
> I think we might get away with losing counters on the update
> side, i.e. rcu_update_pointer() so new CPUs won't find the old
> binary blob, copy the counters, then defer destruction via rcu_work
> or similar and accept that the counters might have marginally
> changed after the copy to userland and before last cpu left its
> rcu critical section.

I could do that if we want to accelerate it. That is if we don't have
the muscle to point people to iptables-nft or iptables-legacy-restore.

Speaking of: Are there plans to remove the legacy interface? This could
be used as meet the users ;) But seriously, the nft part is around for
quite some time and there is not downside to it.

Sebastian




[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux