netfilter buglog - Sep 2020 - [Bug 1464] New: Trying to populate a set raises a netlink error "Could not process rule: No space left on device"

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

            Bug ID: 1464
           Summary: Trying to populate a set raises a netlink error "Could
                    not process rule: No space left on device"
           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

This bug is somewhat related to bug 1392. As explained there, I was unable to
atomically re-populate a set by issuing a "flush set" command followed
by an
"add element" command within the same command stream. Eventually this
was
resolved by upgrading to nftables commit 40ef308.

However, in the inital report, I had also mentioned that executing my script
would occasionally result in the following error:-

  netlink: Error: Could not process rule: No space left on device

I had hoped that this issue would never arise again. Unfortunately, today it
has. Whenever it has happened before, flushing the ruleset has always sufficed
as a workaround. For now, I have chosen not to do this because the affected
host is in a state whereby I can reliably reproduce this.

The script in question downloads the IPv4 bogons list from Team Cymru and tries
to populate a specific set. On the last occasion that I ran it, it emptied the
set but failed to add the given elements, before printing the above-mentioned
error. After realising this, I reduced my script to just the part that tries to
populate the set and tried it again. Hence, the test case looks like this:-

  tmpfile=/tmp/tmp.lWZWu0uSkn
  nft -f - <<-EOF
      flush set ip raw bogons
      add element ip raw bogons {
          $(grep -v '^#' "$tmpfile" | paste -d, -s -)
      }
  EOF

The temp file is a copy of the "fullbogons-ipv4.txt" file that I last
downloaded. At this point, I am able to reproduce the error by running the
above code, despite the fact that it has worked correctly for weeks up until
now.

The definition of the set is currently as follows:-

  table ip raw {
    set bogons {
      type ipv4_addr
      flags interval,timeout
      timeout 4h5m
    }
  }

Some components have changed since I last commented on bug 1392. Here is what I
am running now:

  * Linux 5.8.8 (I upgraded from the 5.7 series)
  * nftables commit c156232
  * libnftnl commit 99be0e6

I shall attach the exact command stream, along with some additional
information.

-- 
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/20200913/420c421a/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

kfm at plushkava.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugzilla.netfilter.
                   |                            |org/show_bug.cgi?id=1392

-- 
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/20200913/54e4207c/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

kfm at plushkava.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |1461

-- 
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/20200913/128e8b0b/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

--- Comment #1 from kfm at plushkava.net ---
Created attachment 608
  --> https://bugzilla.netfilter.org/attachment.cgi?id=608&action=edit
bug-1464-nft-input-stream.txt

The input stream, as composed for "nft -f -".

-- 
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/20200913/85ba572b/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

--- Comment #2 from kfm at plushkava.net ---
Created attachment 609
  --> https://bugzilla.netfilter.org/attachment.cgi?id=609&action=edit
bug-1464-strace.txt

The output of strace for the execution of the test case.

-- 
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/20200913/a9baa686/attachment-0001.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

--- Comment #3 from kfm at plushkava.net ---
In case it matters, there are also some sysctl tweaks that apply to the
affected host. These are as follows.

  # conntrackd appreciates larger buffers for UDP communication.
  net.core.rmem_max=8388608
  net.core.wmem_max=8388608

  # Approximately double the defaults so that conntrack -E does not lose
events.
  net.core.rmem_default=524288
  net.core.wmem_default=524288

-- 
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/20200913/2663e4df/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

--- Comment #4 from kfm at plushkava.net ---
Just to add that this issue remains reproducible here with the combination of
Linux 5.9.11, nftables 0.9.7 and libnftnl 1.1.8.

-- 
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/20201201/7ded8bbb/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

Pablo Neira Ayuso <pablo at netfilter.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #5 from Pablo Neira Ayuso <pablo at netfilter.org> ---
Is this easily reproducible in your testbed? I cannot reproduce it here yet. I
can see a fork() call in your nft-enoent binary. Could you attach the strace -f
output to track child process?

-- 
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/20201202/9d005bda/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

--- Comment #6 from kfm at plushkava.net ---
(In reply to Pablo Neira Ayuso from comment #5)
> Is this easily reproducible in your testbed? I cannot reproduce it here
yet.
> I can see a fork() call in your nft-enoent binary. Could you attach the
> strace -f output to track child process?
Yes. Every time. I can reproduce it simply by applying the attached command
stream directly with nft(8) so I'll attach a trace of that.

-- 
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/20201202/ffc38ffc/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

kfm at plushkava.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #609 is|0                           |1
           obsolete|                            |

--- Comment #7 from kfm at plushkava.net ---
Created attachment 618
  --> https://bugzilla.netfilter.org/attachment.cgi?id=618&action=edit
bug-1464-strace-r1.txt

# strace -obug-1464-strace-r1.txt nft -f bug-1464-nft-input-stream.txt

-- 
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/20201202/f754d3d2/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

--- Comment #8 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to kfm from comment #7)
> Created attachment 618 [details]
> bug-1464-strace-r1.txt
> 
> # strace -obug-1464-strace-r1.txt nft -f bug-1464-nft-input-stream.txt
Netlink message is sent:

sendmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000},
msg_namelen=12, msg_iov=[{iov_base=[{{len=20, type=NFNL_MSG_BATCH_BEGIN,
flags=NLM_F_REQUEST, seq=0, pid=0}, {nfgen_family=AF_UNSPEC,
version=NFNETLINK_V0, res_id=htons(2560)}, {{len=40,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_DELSETELEM, flags=NLM_F_REQUEST,
seq=1,
pid=0}, {nfgen_family=AF_INET, version=NFNETLINK_V0, res_id=htons(0),
[{{nla_len=11, nla_type=0x2}, "\x62\x6f\x67\x6f\x6e\x73\x00"},
{{nla_len=8,
nla_type=NFNETLINK_V1}, "\x72\x61\x77\x00"}]}, {{len=51440,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_NEWSETELEM,
flags=NLM_F_REQUEST|NLM_F_CREATE, seq=2, pid=0}, {nfgen_family=AF_INET,
version=NFNETLINK_V0, res_id=htons(0), [{{nla_len=11, nla_type=0x2},
"\x62\x6f\x67\x6f\x6e\x73\x00"}, {{nla_len=8, nla_type=0x4},
"\x00\x00\x00\x1d"}, {{nla_len=8, nla_type=NFNETLINK_V1},
"\x72\x61\x77\x00"},
{{nla_len=51392, nla_type=NLA_F_NESTED|0x3},
"\x10\x00\x01\x80\x0c\x00\x01\x80\x08\x00\x01\x00\x00\x00\x00\x00\x18\x00\x02\x80\x08\x00\x03\x00\x00\x00\x00\x01\x0c\x00\x01\x80"...}]},
{{len=20, type=NFNL_MSG_BATCH_END, flags=NLM_F_REQUEST, seq=3, pid=0},
{nfgen_family=AF_UNSPEC, version=NFNETLINK_V0, res_id=htons(2560)}],
iov_len=51520}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 51520

Then, select() reports a reply message:

select(4, [3], NULL, NULL, {tv_sec=0, tv_usec=0}) = 1 (in [3], left {tv_sec=0,
tv_usec=0})

And userspace gets it via recvmsg():

recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000},
msg_namelen=12, msg_iov=[{iov_base={{len=51460, type=NLMSG_ERROR, flags=0,
seq=2, pid=11881}, {error=-EEXIST, msg={{len=51440,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_NEWSETELEM,
flags=NLM_F_REQUEST|NLM_F_CREATE, seq=2, pid=0}, {nfgen_family=AF_INET,
version=NFNETLINK_V0, res_id=htons(0), [{{nla_len=11, nla_type=0x2},
"\x62\x6f\x67\x6f\x6e\x73\x00"}, {{nla_len=8, nla_type=0x4},
"\x00\x00\x00\x1d"}, {{nla_len=8, nla_type=NFNETLINK_V1},
"\x72\x61\x77\x00"},
{{nla_len=51392, nla_type=NLA_F_NESTED|0x3},
"\x10\x00\x01\x80\x0c\x00\x01\x80\x08\x00\x01\x00\x00\x00\x00\x00\x18\x00\x02\x80\x08\x00\x03\x00\x00\x00\x00\x01\x0c\x00\x01\x80"...}]}}},
iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_TRUNC}, 0) = 4096

Kernel is sending a netlink message to userspace whose nlmsg_len is 51460 (?)

Userspace only has a 4096 buffer to receive, so libmnl gets the MSG_TRUNC flag
and turn it into ENOSPC.

-- 
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/20201202/ec2cfb2b/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

--- Comment #9 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to kfm from comment #6)
> (In reply to Pablo Neira Ayuso from comment #5)
> > Is this easily reproducible in your testbed? I cannot reproduce it
here yet.
> > I can see a fork() call in your nft-enoent binary. Could you attach
the
> > strace -f output to track child process?
> 
> Yes. Every time. I can reproduce it simply by applying the attached command
> stream directly with nft(8) so I'll attach a trace of that.
I'm testing with 5.10.0-rc4+

so you there you do:

#1 Add this table

 table ip raw {
    set bogons {
      type ipv4_addr
      flags interval,timeout
      timeout 4h5m
    }
  }

#2 then:

nft -f bug-1464-nft-input-stream.txt

#3 run again:

nft -f bug-1464-nft-input-stream.txt

and you hit the bug?

Maybe I'm overlooking something on the steps to reproduce this.

-- 
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/20201202/0c4c3d8c/attachment-0001.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

--- Comment #10 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to Pablo Neira Ayuso from comment #8)
> (In reply to kfm from comment #7)
> > Created attachment 618 [details]
> > bug-1464-strace-r1.txt
> > 
> > # strace -obug-1464-strace-r1.txt nft -f bug-1464-nft-input-stream.txt
> 
> Netlink message is sent:
> 
> sendmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000},
> msg_namelen=12, msg_iov=[{iov_base=[{{len=20, type=NFNL_MSG_BATCH_BEGIN,
> flags=NLM_F_REQUEST, seq=0, pid=0}, {nfgen_family=AF_UNSPEC,
> version=NFNETLINK_V0, res_id=htons(2560)}, {{len=40,
> type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_DELSETELEM, flags=NLM_F_REQUEST,
seq=1,
> pid=0}, {nfgen_family=AF_INET, version=NFNETLINK_V0, res_id=htons(0),
> [{{nla_len=11, nla_type=0x2}, "\x62\x6f\x67\x6f\x6e\x73\x00"},
{{nla_len=8,
> nla_type=NFNETLINK_V1}, "\x72\x61\x77\x00"}]}, {{len=51440,
> type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_NEWSETELEM,
> flags=NLM_F_REQUEST|NLM_F_CREATE, seq=2, pid=0}, {nfgen_family=AF_INET,
> version=NFNETLINK_V0, res_id=htons(0), [{{nla_len=11, nla_type=0x2},
> "\x62\x6f\x67\x6f\x6e\x73\x00"}, {{nla_len=8, nla_type=0x4},
> "\x00\x00\x00\x1d"}, {{nla_len=8, nla_type=NFNETLINK_V1},
> "\x72\x61\x77\x00"}, {{nla_len=51392, nla_type=NLA_F_NESTED|0x3},
>
"\x10\x00\x01\x80\x0c\x00\x01\x80\x08\x00\x01\x00\x00\x00\x00\x00\x18\x00\x02
> \x80\x08\x00\x03\x00\x00\x00\x00\x01\x0c\x00\x01\x80"...}]}, {{len=20,
> type=NFNL_MSG_BATCH_END, flags=NLM_F_REQUEST, seq=3, pid=0},
> {nfgen_family=AF_UNSPEC, version=NFNETLINK_V0, res_id=htons(2560)}],
> iov_len=51520}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 51520
The large message is send from userspace to the kernel:

{{len=51440, type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_NEWSETELEM,
> Then, select() reports a reply message:
> 
> select(4, [3], NULL, NULL, {tv_sec=0, tv_usec=0}) = 1 (in [3], left
> {tv_sec=0, tv_usec=0})
> 
> And userspace gets it via recvmsg():
> 
> recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000},
> msg_namelen=12, msg_iov=[{iov_base={{len=51460, type=NLMSG_ERROR, flags=0,
> seq=2, pid=11881}, {error=-EEXIST, msg={{len=51440,
> type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_NEWSETELEM,
> flags=NLM_F_REQUEST|NLM_F_CREATE, seq=2, pid=0}, {nfgen_family=AF_INET,
> version=NFNETLINK_V0, res_id=htons(0), [{{nla_len=11, nla_type=0x2},
> "\x62\x6f\x67\x6f\x6e\x73\x00"}, {{nla_len=8, nla_type=0x4},
> "\x00\x00\x00\x1d"}, {{nla_len=8, nla_type=NFNETLINK_V1},
> "\x72\x61\x77\x00"}, {{nla_len=51392, nla_type=NLA_F_NESTED|0x3},
>
"\x10\x00\x01\x80\x0c\x00\x01\x80\x08\x00\x01\x00\x00\x00\x00\x00\x18\x00\x02
> \x80\x08\x00\x03\x00\x00\x00\x00\x01\x0c\x00\x01\x80"...}]}}},
> iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_TRUNC}, 0)
> 4096
Then the NLM_ERROR message contains the original message len=51440.

Looks like userspace is sending a malformed attribute:

{{nla_len=51392, nla_type=NLA_F_NESTED|0x3},
>
"\x10\x00\x01\x80\x0c\x00\x01\x80\x08\x00\x01\x00\x00\x00\x00\x00\x18\x00\x02
> \x80\x08\x00\x03\x00\x00\x00\x00\x01\x0c\x00\x01\x80"...}]}}},
-- 
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/20201202/ae0a4db0/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

--- Comment #11 from Pablo Neira Ayuso <pablo at netfilter.org> ---
OK, I found the root cause.

On your side, you are triggering EEXIST on a very big netlink message contain
lots of elements from userspace.

The receive buffer is only MNL_SOCKET_BUFFER_SIZE which is not big enough to
store the NLMSG_ERROR message, which contains the original netlink message as a
payload.

Preparing a patch to fix this...

-- 
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/20201202/2fd0f106/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

--- Comment #12 from kfm at plushkava.net ---
Thank you for the detailed explanation and outstanding sleuthing work. I'll
try
whatever patch you suggest as soon as it lands.

-- 
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/20201202/335c73a7/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

--- Comment #13 from Pablo Neira Ayuso <pablo at netfilter.org> ---
Created attachment 619
  --> https://bugzilla.netfilter.org/attachment.cgi?id=619&action=edit
add NFT_MNL_ACK_MAXSIZE

Attaching patch aiming to fix ENOSPC due to netlink MSG_TRUNC.

You should see EEXIST after this fix, which is the original error that the
kernel is intending to deliver.

Thanks.

-- 
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/20201202/8e68875b/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

--- Comment #14 from kfm at plushkava.net ---
Created attachment 620
  --> https://bugzilla.netfilter.org/attachment.cgi?id=620&action=edit
bug-1464-strace-r2.txt

A fresh trace, having applied attachment #619 (the NFT_MNL_ACK_MAXSIZE patch).
The set was not yet cleared, so most - if not all - elements continue to
overlap with the payload.

-- 
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/20201202/b71f84df/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

--- Comment #15 from kfm at plushkava.net ---
When I say "not yet cleared", I mean not independently. Of course, the
input
stream still contains the flush set command.

-- 
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/20201202/de1609c4/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

--- Comment #16 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to kfm from comment #14)
> Created attachment 620 [details]
> bug-1464-strace-r2.txt
> 
> A fresh trace, having applied attachment #619 [details] (the
> NFT_MNL_ACK_MAXSIZE patch). The set was not yet cleared, so most - if not
> all - elements continue to overlap with the payload.
So after the patch, I can see it sends the netlink message:

sendmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000},
msg_namelen=12, msg_iov=[{iov_base=[{{len=20, type=NFNL_MSG_BATCH_BEGIN,
flags=NLM_F_REQUEST, seq=0, pid=0}, {nfgen_family=AF_UNSPEC,
version=NFNETLINK_V0, res_id=htons(2560)}, {{len=40,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_DELSETELEM, flags=NLM_F_REQUEST,
seq=1,
pid=0}, {nfgen_family=AF_INET, version=NFNETLINK_V0, res_id=htons(0),
[{{nla_len=11, nla_type=0x2}, "\x62\x6f\x67\x6f\x6e\x73\x00"},
{{nla_len=8,
nla_type=NFNETLINK_V1}, "\x72\x61\x77\x00"}]}, {{len=51440,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_NEWSETELEM,
flags=NLM_F_REQUEST|NLM_F_CREATE, seq=2, pid=0}, {nfgen_family=AF_INET,
version=NFNETLINK_V0, res_id=htons(0), [{{nla_len=11, nla_type=0x2},
"\x62\x6f\x67\x6f\x6e\x73\x00"}, {{nla_len=8, nla_type=0x4},
"\x00\x00\x00\x1d"}, {{nla_len=8, nla_type=NFNETLINK_V1},
"\x72\x61\x77\x00"},
{{nla_len=51392, nla_type=NLA_F_NESTED|0x3},
"\x10\x00\x01\x80\x0c\x00\x01\x80\x08\x00\x01\x00\x00\x00\x00\x00\x18\x00\x02\x80\x08\x00\x03\x00\x00\x00\x00\x01\x0c\x00\x01\x80"...}]},
{{len=20, type=NFNL_MSG_BATCH_END, flags=NLM_F_REQUEST, seq=3, pid=0},
{nfgen_family=AF_UNSPEC, version=NFNETLINK_V0, res_id=htons(2560)}],
iov_len=51520}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 51520

I can see NFT_MSG_DELSETELEM (flush) coming before NFT_MSG_NEWSETELEM (add
elements) here above.

select(4, [3], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)                 
close(4)                                = 0                                     
close(3)                                = 0  

And kernel reports no error, nft does not print it either (strace does not show
any write() syscall)

I don't see any error in this trace at quick glance. Still issues on your
side?

-- 
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/20201202/f5bcc650/attachment-0001.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

--- Comment #17 from kfm at plushkava.net ---
As you say, I can't seem to trigger any errors now. Moreover, the set
appears
to be flushed and re-populated, as expected. To be certain, I shall devise a
simple stress test which varies the input and validates the results. While
I'm
at it, I might as well go over the tests that I ran in bug #1392. I shall
report back at some point tomorrow (it's coming up to midnight of Thursday
here). Thanks.

-- 
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/20201203/4c146ac8/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1464

--- Comment #18 from Pablo Neira Ayuso <pablo at netfilter.org> ---
Upstream fix available:

6975c6d39366 mnl: reply netlink error message might be larger than
MNL_SOCKET_BUFFER_SIZE

It includes a test to reproduce the ENOSPC problem with sets.

-- 
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/20201208/db75d148/attachment.html>