[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