netfilter buglog - Dec 2023 - [Bug 1728] New: Regression: iptables lock is now waited for without --wait

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

            Bug ID: 1728
           Summary: Regression: iptables lock is now waited for without
                    --wait
           Product: iptables
           Version: 1.8.x
          Hardware: x86_64
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: unknown
          Assignee: netfilter-buglog at lists.netfilter.org
          Reporter: howardjohn at google.com

Iptables 1.8.8 contains a (seemingly) unexpected behavioral change in the lock
waiting logic. This was introduced in commit
07e2107ef0cbc1b81864c3c0f0ef297a9dfff44d, "xshared: Implement xtables lock
timeout using signals".

Prior to this commit, without --wait the command would exit immediately if the
lock could not be acquired. After this commit, the command will wait
indefinitely for the lock if --wait is not set.

This can be demonstrated by intentionally taking the lock and running various
iptables commands against it.

For all cases I run: sudo flock /run/xtables.lock sleep 10 &
followed by a random iptables command (sudo ./iptables/xtables-legacy-multi
iptables -t nat -A blah).


On iptables from the HEAD of master (f5cf76626d95d2c491a80288bccc160c53b44e88),
the command waits 10s

On iptables 1.8.7, the command fails immediately with "Another app is
currently
holding the xtables lock".

On master with 07e2107ef0cbc1b81864c3c0f0ef297a9dfff44d reverted, the command
fails immediately as well.

-- 
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/20231218/c1e9cfda/attachment.html>

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

Antonio Ojea <antonio.ojea.garcia at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P5                          |P1
                 CC|                            |antonio.ojea.garcia at gmail.c
                   |                            |om
           Severity|normal                      |major

--- Comment #1 from Antonio Ojea <antonio.ojea.garcia at gmail.com> ---
This change in behavior is problematic for environments like Kubernetes that
heavily use iptables, because applications that were not counting on wait for a
lock will now start blocking.

Despite a lot of environments are using iptables-nft these days, there is
always a long tail in the industry with environments that are still using
iptables-legacy.

-- 
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/20231218/9ef7a059/attachment.html>

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

Phil Sutter <phil at nwl.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |phil at nwl.cc

--- Comment #2 from Phil Sutter <phil at nwl.cc> ---
I submitted a fix for review:

https://lore.kernel.org/netfilter-devel/20231219020855.4794-1-phil at nwl.cc/

sadly, the only workaround that comes to mind is always passing '-w 1'
to
mitigate the indefinite wait to a 1s delay.

-- 
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/20231219/d4fe58f7/attachment.html>

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

Phil Sutter <phil at nwl.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Phil Sutter <phil at nwl.cc> ---
Fix is upstream: 63ab5b8906f69 ("iptables-legacy: Fix for mandatory lock
waiting").

-- 
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/20231221/7d37fb76/attachment.html>

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

--- Comment #4 from Antonio Ojea <antonio.ojea.garcia at gmail.com> ---
Thank you very much Phil

-- 
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/20231221/7288cb5c/attachment.html>