[Bug 1392] New: nft stalls on EGAIN upon repeatedly flushing and populating a set
bugzilla-daemon at netfilter.org
bugzilla-daemon at netfilter.org
Mon Dec 30 23:17:27 CET 2019
https://bugzilla.netfilter.org/show_bug.cgi?id=1392
Bug ID: 1392
Summary: nft stalls on EGAIN upon repeatedly flushing and
populating a set
Product: nftables
Version: unspecified
Hardware: x86_64
OS: Gentoo
Status: NEW
Severity: normal
Priority: P5
Component: nft
Assignee: pablo at netfilter.org
Reporter: kfm at plushkava.net
Created attachment 580
--> https://bugzilla.netfilter.org/attachment.cgi?id=580&action=edit
bash script that reproduces the issue filed
Recently, I was assisting somebody in the course of adjusting some scripts that
generate an ipset consisting of IPv6 bogons, so as to use native nftables sets.
While testing on my own machine, I found that nft appeared to sporadically
hang.
Upon further investigation, I found that the process - which entails one
"flush" and one "add element" command - was being carried out rapidly at first,
only to encounter difficulties if repeated without flushing and recomposing the
underlying table entirely. The attached script acts as a reproducer. Here is
some sample output from my machine:
[0]: Iteration #1
[1]: Iteration #2
[429]: Iteration #3
[845]: Iteration #4
This means that the set was populated in a second or less (good), only to take
approximately 428 seconds on the second attempt (very bad). A single CPU core
is pegged throughout the second - and all subsequent - iterations. Some casual
stracing implies that there is some issue communicating with netlink. An EAGAIN
occurs, followed by a long stall.
Also, at one point, the following error appeared in my terminal, though I have
not been able to reproduce it:
netlink: Error: Could not process rule: No space left on device
This machine is using the following components:
Linux 5.4.6
glibc-2.29
libmnl-1.0.4
libnfnetlink-1.0.1
libnftnl-1.1.5
nftables-0.9.3
My expectation is that repeated adjustment of the set be as efficient as it is
upon the first population, and that the overall reliability is commensurate
with that of ipset.
--
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20191230/c7297ac1/attachment.html>
More information about the netfilter-buglog
mailing list