Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > On 2025-02-17 16:35:48 [+0100], Florian Westphal wrote: > > 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. Yes, I think so. > > 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. Yes, since 6c959fd5e17387201dba3619b2e6af213939a0a7 the legacy symbol is user visible so next step is to replace various "select ...TABLES_LEGACY" with "depends on" clauses.
