Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxx> wrote: > On Thu, 28 Sep 2023, Pablo Neira Ayuso wrote: > > One concern might be deadlock due to reordering, but I don't see how > > that can happen. > > The same problem exists ipset: when a set is listed/saved (dumped), > concurrent destroy/rename/swap for the same set must be excluded. As > neither spinlock nor mutex helps, a reference counter is used: the start > of the dump increases it and by checking it all concurrent events can > safely be rejected by returning EBUSY. Thanks for sharing! I assume that means that a dumper that starts a dump, and then goes to sleep before closing the socket/finishing the dump can block further ipset updates, is that correct? (I assume so, I don't see a solution that doesn't trade one problem for another).
