9 messages, 5 authors, 2005-03-13 · open the first message on its own page
From: Dmitry Torokhov <hidden>
Date: 2005-03-11 07:23:38
Hi, My box gets stuck while booting (actually starting ntpd) whith tonight pull from Linus. It looks like it is spinning in ipt_do_table when I do SysRq-P. No call trace though. Anyone else seeing it? Any ideas? -- Dmitry
From: Patrick McHardy <hidden>
Date: 2005-03-11 14:01:06
Dmitry Torokhov wrote:
My box gets stuck while booting (actually starting ntpd) whith tonight pull from Linus. It looks like it is spinning in ipt_do_table when I do SysRq-P. No call trace though.
Please post your ruleset and .config. A backtrace would also be useful.
Anyone else seeing it? Any ideas?
Works fine here. You could try if reverting one of these two patches helps (second one only if its a SMP box). ChangeSet@1.2010, 2005-03-09 20:28:17-08:00, bdschuym@pandora.be [NETFILTER]: Reduce call chain length in netfilter (take 2) ChangeSet@1.1982.114.20, 2005-03-03 23:15:48+01:00, ak@suse.de [NETFILTER]: Reduce netfilter memory use on MP systems Regards Patrick
From: "David S. Miller" <davem@davemloft.net>
Date: 2005-03-11 19:06:42
On Fri, 11 Mar 2005 15:00:56 +0100 Patrick McHardy [off-list ref] wrote:
Works fine here. You could try if reverting one of these two patches helps (second one only if its a SMP box). ChangeSet@1.2010, 2005-03-09 20:28:17-08:00, bdschuym@pandora.be [NETFILTER]: Reduce call chain length in netfilter (take 2)
It's this change, I know it is, because Linus sees the same problem on his workstation. You wouldn't happen to be seeing this problem on a PPC box would you? Since Linus's machine is a PPC machine too, that would support my theory that this could be a compiler issue on that platform. Damn, wait, Patrick, I think I know what's happening. The iptables IPT_* verdicts are dependant upon the NF_* values, and they don't cope with Bart's changes I bet. Can you figure out what the exact error would be? This kind of issue would explain the looping inside of ipt_do_table(), wouldn't it?
From: Dmitry Torokhov <hidden>
Date: 2005-03-11 19:10:46
On Friday 11 March 2005 13:51, David S. Miller wrote:
On Fri, 11 Mar 2005 15:00:56 +0100 Patrick McHardy [off-list ref] wrote:quoted
Works fine here. You could try if reverting one of these two patches helps (second one only if its a SMP box). ChangeSet@1.2010, 2005-03-09 20:28:17-08:00, bdschuym@pandora.be [NETFILTER]: Reduce call chain length in netfilter (take 2)It's this change, I know it is, because Linus sees the same problem on his workstation. You wouldn't happen to be seeing this problem on a PPC box would you? Since Linus's machine is a PPC machine too, that would support my theory that this could be a compiler issue on that platform.
No, it is regular PIII laptop (preempt, UP).
Damn, wait, Patrick, I think I know what's happening. The iptables IPT_* verdicts are dependant upon the NF_* values, and they don't cope with Bart's changes I bet. Can you figure out what the exact error would be? This kind of issue would explain the looping inside of ipt_do_table(), wouldn't it?
-- Dmitry
From: Sergey Vlasov <hidden>
Date: 2005-03-11 19:31:48
On Fri, 11 Mar 2005 10:51:36 -0800 David S. Miller wrote:
On Fri, 11 Mar 2005 15:00:56 +0100 Patrick McHardy [off-list ref] wrote:quoted
Works fine here. You could try if reverting one of these two patches helps (second one only if its a SMP box). ChangeSet@1.2010, 2005-03-09 20:28:17-08:00, bdschuym@pandora.be [NETFILTER]: Reduce call chain length in netfilter (take 2)It's this change, I know it is, because Linus sees the same problem on his workstation. You wouldn't happen to be seeing this problem on a PPC box would you? Since Linus's machine is a PPC machine too, that would support my theory that this could be a compiler issue on that platform. Damn, wait, Patrick, I think I know what's happening. The iptables IPT_* verdicts are dependant upon the NF_* values, and they don't cope with Bart's changes I bet. Can you figure out what the exact error would be? This kind of issue would explain the looping inside of ipt_do_table(), wouldn't it?
This is not just some buggy code - that patch also breaks interfaces: include/linux/netfilter_ipv4/ip_tables.h: #define IPT_RETURN (-NF_MAX_VERDICT - 1) And this value is visible in userspace. Therefore we cannot modify NF_MAX_VERDICT without breaking all existing iptables binaries.
From: Patrick McHardy <hidden>
Date: 2005-03-11 20:54:33
David S. Miller wrote:
Damn, wait, Patrick, I think I know what's happening. The iptables IPT_* verdicts are dependant upon the NF_* values, and they don't cope with Bart's changes I bet. Can you figure out what the exact error would be? This kind of issue would explain the looping inside of ipt_do_table(), wouldn't it?
You're right, good catch. IPT_RETURN is interpreted internally by ip_tables, but since the value changed it isn't recognized by ip_tables anymore and returned to nf_iterate() as NF_REPEAT. This patch restores the old value.
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2005-03-11 21:24:29
Patrick McHardy [off-list ref] wrote:
You're right, good catch. IPT_RETURN is interpreted internally by ip_tables, but since the value changed it isn't recognized by ip_tables anymore and returned to nf_iterate() as NF_REPEAT. This patch restores the old value.
Please fix netfilter_arp while you're at it since it does exactly
the same thing.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
From: Patrick McHardy <hidden>
Date: 2005-03-11 23:20:24
Herbert Xu wrote:
Patrick McHardy [off-list ref] wrote:quoted
You're right, good catch. IPT_RETURN is interpreted internally by ip_tables, but since the value changed it isn't recognized by ip_tables anymore and returned to nf_iterate() as NF_REPEAT. This patch restores the old value.Please fix netfilter_arp while you're at it since it does exactly the same thing.
New patch attached, thanks.
From: Dmitry Torokhov <hidden>
Date: 2005-03-13 06:54:13
On Friday 11 March 2005 17:55, Patrick McHardy wrote:
Herbert Xu wrote:quoted
Patrick McHardy [off-list ref] wrote:quoted
You're right, good catch. IPT_RETURN is interpreted internally by ip_tables, but since the value changed it isn't recognized by ip_tables anymore and returned to nf_iterate() as NF_REPEAT. This patch restores the old value.Please fix netfilter_arp while you're at it since it does exactly the same thing.New patch attached, thanks.
If this is of any interest, yesterday's pull from Linux plus this patch seem to be working fine here. Thank you. -- Dmitry