Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > In one test, I noticed around ~75 entries stuck in the dying list. In > > another test, I noticed conntrackd -i | wc -l showed one entry that > > got stuck in the cache, which was not in the dying list. I suspect > > some problem in the retransmission logic. > > Another interesting information. If I generate new entries that get > stuck in the dying list because of undelivered events, the worker > seems to give another chance to deliver, and the entries that were > stuck are not there anymore. Hmm, don't yet understand how we could end up with pending events on the list without work queue being scheduled for execution. The eache worker will _always_ schedule itself _except_ when it thinks that it has delivered all entries. Its possible that a new entry was put on the dying list immediately after we've done the hlist nulls test, however in that case the delivery failure should also have scheduled the work queue via nf_conntrack_ecache_delayed_work(). AFAICS delayed_work_pending() cannot return true for a work struct that is still running since WORK_STRUCT_PENDING_BIT is cleared before callback invocation. Will look again tomorrow. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
