xt_recseq is per-CPU sequence counter which is not entirely using the seqcount API. The writer side of the sequence counter is updating the packet and byte counter (64bit) while processing a packet. The reader simply retrieves the two counter. Based on the code, the writer side can be recursive which is probably why the "regular" write side isn't used or maybe because there is no "lock". The seqcount is per-CPU and disabling BH is used as the "lock". On PREEMPT_RT code in local_bh_disable()ed section is preemptible and this means that a seqcount reader with higher priority can preempt the writer which leads to a deadlock. While trying to trigger the writer side, I managed only to trigger a single reader and only while using iptables-legacy/ arptables-legacy commands. The nft did not trigger it. So it is legacy code only. Would it work to convert the counters to u64_stats_sync? On 32bit there would be a seqcount_t with preemption disabling during the update which means the xt_write_recseq_begin()/ xt_write_recseq_end() has to be limited the counter update only. On 64bit architectures there would be just the update. This means that number of packets and bytes might be "off" (the one got updated, the other not "yet") but I don't think that this is a problem here. I could send a RFC patch if there is nothing obvious I overlooked ;) Sebastian
