<html>
<head>
<base href="https://bugzilla.netfilter.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - nft stalls on EGAIN upon repeatedly flushing and populating a set"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1392">1392</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>nft stalls on EGAIN upon repeatedly flushing and populating a set
</td>
</tr>
<tr>
<th>Product</th>
<td>nftables
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86_64
</td>
</tr>
<tr>
<th>OS</th>
<td>Gentoo
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P5
</td>
</tr>
<tr>
<th>Component</th>
<td>nft
</td>
</tr>
<tr>
<th>Assignee</th>
<td>pablo@netfilter.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>kfm@plushkava.net
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=580" name="attach_580" title="bash script that reproduces the issue filed">attachment 580</a> <a href="attachment.cgi?id=580&action=edit" title="bash script that reproduces the issue filed">[details]</a></span>
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>