On Sun, 7 Jul 2024 10:08:24 +0200 Florian Westphal <fw@xxxxxxxxx> > Hillf Danton <hdanton@xxxxxxxx> wrote: > > > I think this change might be useful as it also documents > > > this requirement. > > > > Yes it is boy and the current reproducer triggered another warning [1,2]. > > > > [1] https://lore.kernel.org/lkml/20240706231332.3261-1-hdanton@xxxxxxxx/ > > The WARN is incorrect. The destroy list can be non-empty; i already > tried to explain why. > That warning as-is could be false positive but it could be triggered with a single netns. cpu1 cpu2 cpu3 --- --- --- nf_tables_trans_destroy_work() spin_lock(&nf_tables_destroy_list_lock); // 1) clear the destroy list list_splice_init(&nf_tables_destroy_list, &head); spin_unlock(&nf_tables_destroy_list_lock); nf_tables_commit_release() spin_lock(&nf_tables_destroy_list_lock); // 2) refill the destroy list list_splice_tail_init(&nft_net->commit_list, &nf_tables_destroy_list); spin_unlock(&nf_tables_destroy_list_lock); schedule_work(&trans_destroy_work); mutex_unlock(&nft_net->commit_mutex); nft_rcv_nl_event() mutex_lock(&nft_net->commit_mutex); flush_work(&trans_destroy_work); start_flush_work() insert_wq_barrier() /* * If @target is currently being executed, schedule the * barrier to the worker; otherwise, put it after @target. */ // 3) flush work ends with the refilled destroy list left intact tear tables down
