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

[bugzilla-daemon at netfilter.org]

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>