On Thu, Jul 03, 2025 at 04:21:51PM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > Thanks for the description, this scenario is esoteric. > > > > Is this bug fully reproducible? > > No. Unicorn. Only happened once. > Everything is based off reading the backtrace and vmcore. I guess this needs a chaos money to trigger this bug. Else, can we try to catch this unicorn again? I would push 1/4 and 3/4 to nf.git to start with. Unless you are 100% sure this fix is needed. > > > + /* IPS_CONFIRMED unset means 'ct not (yet) in hash', conntrack lookups > > > + * skip entries that lack this bit. This happens when a CPU is looking > > > + * at a stale entry that is being recycled due to SLAB_TYPESAFE_BY_RCU > > > + * or when another CPU encounters this entry right after the insertion > > > + * but before the set-confirm-bit below. > > > + */ > > > + ct->status |= IPS_CONFIRMED; > > > > My understanding is that this bit setting can still be reordered. > > You mean it could be moved before hlist_add? So this is needed? > > - ct->status |= IPS_CONFIRMED; > + smp_mb__before_atomic(); > + set_bit(IPS_CONFIRMED_BIT, &ct->status) ? > > I can send a v2 with this change.
