On Tue, Feb 28, 2017 at 01:03:07PM +0100, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > On Sat, Feb 25, 2017 at 10:02:03PM -0600, Dan Williams wrote: > > > Checking a rule that includes a jump to a module-based target currently > > > sets the "changed" flag on the handle, which then causes TC_COMMIT() to > > > run through the whole SO_SET_REPLACE/SO_SET_ADD_COUNTERS path. This > > > seems wrong for simply checking rules, an operation which is documented > > > as "...does not alter the existing iptables configuration..." but yet > > > it clearly could do so. > > > > > > Fix that by ensuring that rule check operations for module targets > > > don't set the changed flag, and thus exit early from TC_COMMIT(). > > > > Thanks for explaining. How are you hitting this problem? I'm curious > > to see if I can reproduce it. > > Its easy to reproduce. > > iptables -t nat -o lo -A POSTROUTING -s 10.2.3.4 -j MASQUERADE > iptables -t nat -o lo -C POSTROUTING -s 10.2.3.4 -j MASQUERADE > > you should see (via strace) that 2nd command also issues the iptables > setsockopt calls. Thanks for explain. Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
