This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux release. Product Management has requested further review
of this request by Red Hat Engineering. This request is not yet committed for
inclusion in release.

One thing to look out for is if the qeth driver does delayed TX
packet freeing in a way that there is no upper bound. Delaying
TX using hw interrupt mitigation techniques is fine, as long
as there is a timer based small upper bound to the TX freeing.
But there must be that small upper bound, it is critical to correct
operation of the entire networking stack.
For example, if it does, this will break many many things,
not just ip_conntrack module unloading. It will hurt TCP performance
significantly as well, because until the TX packet is freed up by
the device the socket cannot use that send buffer space for queueing
new packets.
If the qeth driver is doing delayed TX packet freeing without an
appropriate upper bound, this will need to be fixed.

I see a lot of comments about qeth driver here but this issue with failing
'service iptables stop' happens on my box with an e1000 NIC too so it does not
appear to be qeth-specific. See the bugs that have been closed as duplicates of
this one, I don't think *all* those folks are running mainframes.

With just the patch from comment 30 (need_conntrack chunk removed) I can restart
iptables with and without the interface up. During shutdown though iptables
still hangs.. but I think this may be s390 specific (see bug 218798).
Can the original reporter test the patch in comment 30?

Sorry, I can't. For some odd reason, I can't reproduce this in that environment
right now. I'll keep trying, but can guarantee testing results with an x86
because I have a system reproducing that right now.

Is ip6tables running on this system? I just noticed that they share some
modules. On one of the stock kernels, if you stop ip6tables first, does
iptables stop successfully? If so, we may need to work this out through
initscipts rather than kernel.

Feedback from IBM zSeries: Well, i don't knwo whether some of the other changes
impact things, but in the previosu code, if ip6tables is stopped first, stopping
iptables still hung afterwards but that was without any of the patches applied

The module xt_state depends on ip_conntrack, ip_tables respectively
ip6_tables depends on xt_state _if_ the firewall configuration involves
connection tracking. This dependency is not shown by lsmod because no
symbols are being referenced by either module.
Therefore, while ip6tables has IPv6 connection tracking configured,
the ip6_tables module will hold a reference on the xt_state module
preventing it from being unloaded. This prevents ip_conntrack from
being unloaded as it requires xt_state to be unloaded first.
This means that as long as either iptables protocol version uses
conntracking, neither of them can be unloaded.
My suggestion is to disable iptables module unloading until a solution
is found.

In /etc/sysconfig/ip6tables:
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
Sorry but I really had to laugh. Using xt_state for IPpv6 traffic with
ip_conntrack can't possibly work. There is no connection tracking support
in ip_conntrack. Whoever added those rules did never even test them.
Please remove those rules from the default config ASAP.

The config problem is now addressed in bug 222981.
And this issue is only to address the race condition in netfilter.
Given that the patch has been integrated in 1.3002.el5 build,
move to MODIFIED and VERIFIED.