* Sparc64 U60: no iptables [not found] ` <4348EFF4.3040305@frankengul.org> @ 2005-10-09 18:28 ` Sébastien Bernard 2005-10-10 3:26 ` David S. Miller 0 siblings, 1 reply; 5+ messages in thread From: Sébastien Bernard @ 2005-10-09 18:28 UTC (permalink / raw) To: debian-sparc, netfilter-devel, linux-kernel Sébastien Bernard a écrit : > Sébastien Bernard wrote: > >> Hi there. >> >> Being the owner of a two-way U60, I've been happy with it until >> 2.6.11.6. >> >> The machine is a 2x300Mhz Uii with 1536Mb of memory and 2 scsi >> internal disk. >> >> Since 2.6.12, I'm unfortunately unable to use it as gateway box, >> since the installation of iptables >> cause a OOPS in the ipt_mangle. >> >> I'm unable to send you the trace now because once it happened, it is >> not written on the files, only on the console. >> >> This oops happens from the 2.6.12.x to the 2.6.13.x - not tried the >> 2.6.14-rc. >> It is related to the iptables subsystem. >> It also happen with the official debian kernel (2.6.12-1-smp). >> >> I'll try this week-end to setup early 2.6.12-rcx to check when the >> problem occured. >> >> I will post the oops as soon as I write it down. >> How can I get the copy of the trace without handwriting ? >> What is the information relevant in the oops ? (register + stack >> trace ?) >> >> Seb >> >> > Ok, I reproduced the problem on the 2.6.12-rc1. > Here's the backtrace : > > Unable to handle kernel NULL pointer dereference. > > nmbd: Ooops[#1] > > ip_do_table + 0x21c/0x380 > ip_do_table + 0x44/0x380 > ip_local_hook + 0x84/0x120 > nf_iterate + 0x64/0xc0 > nf_hook_slow + 0x4c/0x120 > ip_push_pending_frames + 0x2d8/0x4c0 > udp_push_pending_frames + 0x118/0x260 > udp_sendmsg + 0x398/0x6c0 > inet_sendmsg + 0x30/0x60 > sock_sendmsg + 0xc8/0x100 > I found the culprit for my oops. In the iptables, NR_CPUS is set to 4 to get the 2 cpus recognized properly. The culprit patch substitute the NR_CPUS by the num_possible_cpus() macro. With this patch applied, inserting the iptables modules gets you instant oops... With it reverted, everything works as normal. I suspect that NR_CPUS == 4 and num_possible_cpus() == 2. Can one explain me why this patch works on other archs, and oops on the sparc64 smp ? Can one explain why I'm the only one to have this problem ? Seb Here is the patch I reverted : --- a/net/ipv4/netfilter/ip_tables.c 2005-03-17 17:35:05 -08:00 +++ b/net/ipv4/netfilter/ip_tables.c 2005-03-17 17:35:05 -08:00 @@ -923,7 +923,7 @@ } /* And one copy for every other CPU */ - for (i = 1; i < NR_CPUS; i++) { + for (i = 1; i < num_possible_cpus(); i++) { memcpy(newinfo->entries + SMP_ALIGN(newinfo->size)*i, newinfo->entries, SMP_ALIGN(newinfo->size)); @@ -945,7 +945,7 @@ struct ipt_entry *table_base; unsigned int i; - for (i = 0; i < NR_CPUS; i++) { + for (i = 0; i < num_possible_cpus(); i++) { table_base = (void *)newinfo->entries + TABLE_OFFSET(newinfo, i); @@ -992,7 +992,7 @@ unsigned int cpu; unsigned int i; - for (cpu = 0; cpu < NR_CPUS; cpu++) { + for (cpu = 0; cpu < num_possible_cpus(); cpu++) { i = 0; IPT_ENTRY_ITERATE(t->entries + TABLE_OFFSET(t, cpu), t->size, @@ -1130,7 +1130,7 @@ return -ENOMEM; newinfo = vmalloc(sizeof(struct ipt_table_info) - + SMP_ALIGN(tmp.size) * NR_CPUS); + + SMP_ALIGN(tmp.size) * num_possible_cpus()); if (!newinfo) return -ENOMEM; @@ -1460,7 +1460,7 @@ = { 0, 0, 0, { 0 }, { 0 }, { } }; newinfo = vmalloc(sizeof(struct ipt_table_info) - + SMP_ALIGN(repl->size) * NR_CPUS); + + SMP_ALIGN(repl->size) * num_possible_cpus()); if (!newinfo) return -ENOMEM; ------------------- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Sparc64 U60: no iptables 2005-10-09 18:28 ` Sparc64 U60: no iptables Sébastien Bernard @ 2005-10-10 3:26 ` David S. Miller 2005-10-10 8:25 ` seb 0 siblings, 1 reply; 5+ messages in thread From: David S. Miller @ 2005-10-10 3:26 UTC (permalink / raw) To: seb; +Cc: debian-sparc, netfilter-devel, linux-kernel From: Sébastien Bernard <seb@frankengul.org> Date: Sun, 09 Oct 2005 20:28:31 +0200 > Can one explain me why this patch works on other archs, and oops on the > sparc64 smp ? > Can one explain why I'm the only one to have this problem ? On your Ultra60 the two physical cpus are numbered "0" and "2". ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Sparc64 U60: no iptables 2005-10-10 3:26 ` David S. Miller @ 2005-10-10 8:25 ` seb 2005-10-10 18:16 ` David S. Miller 0 siblings, 1 reply; 5+ messages in thread From: seb @ 2005-10-10 8:25 UTC (permalink / raw) To: David S. Miller; +Cc: debian-sparc, netfilter-devel, linux-kernel On Sun, Oct 09, 2005 at 08:26:46PM -0700, David S. Miller wrote: > From: Sébastien Bernard <seb@frankengul.org> > Date: Sun, 09 Oct 2005 20:28:31 +0200 > > > Can one explain me why this patch works on other archs, and oops on the > > sparc64 smp ? > > Can one explain why I'm the only one to have this problem ? > > On your Ultra60 the two physical cpus are numbered "0" and "2". > Thanks for the information. Indeed they are. Does the patch assume that cpus are numbered in a row ? Now, I reverted the patch for ip_tables.c, ip6_tables.c and ebtables.c. Everything is working ok (11h uptime). Is this problem specific to the Ultra 60 or sparc arch ? Will a proper fix be issued for our machines ? Seb ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Sparc64 U60: no iptables 2005-10-10 8:25 ` seb @ 2005-10-10 18:16 ` David S. Miller 2005-10-19 2:13 ` Joseph Murawski 0 siblings, 1 reply; 5+ messages in thread From: David S. Miller @ 2005-10-10 18:16 UTC (permalink / raw) To: seb; +Cc: debian-sparc, netfilter-devel, linux-kernel From: seb@frankengul.org Date: Mon, 10 Oct 2005 10:25:07 +0200 > Indeed they are. Does the patch assume that cpus are numbered in a > row ? Yes, and that assumption is incorrect. > Now, I reverted the patch for ip_tables.c, ip6_tables.c and ebtables.c. > Everything is working ok (11h uptime). Right. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Sparc64 U60: no iptables 2005-10-10 18:16 ` David S. Miller @ 2005-10-19 2:13 ` Joseph Murawski 0 siblings, 0 replies; 5+ messages in thread From: Joseph Murawski @ 2005-10-19 2:13 UTC (permalink / raw) To: David S. Miller; +Cc: debian-sparc, netfilter-devel, linux-kernel Hello - I would like to confirm this problem and reverting the patch provided does fix the problem! I have an ultra 60, dual processor. gentoo linux gentoo-sources 2.6.13-gentoo-r2 Whenever i would enable the iptables modules (ip_tables) (ip_conntrack), execute the two commands iptables -X iptables -F and Ping any address ( including the loopback address) i would get an oops. I would just like to throw out my encounter with the problem and confirm that the reversion of the below patch, fixes the problem and i am able to use iptables with an smp kernel. if i am commiting a mailing list no no by posting this please let me know, but i thought it would be helpful to confirm this event. Also is there a bugzilla type system for the linux kernel? Thank you all for all your work! any questions please let me know, i am also willing to report a bug report if there is such a system in place. --- a/net/ipv4/netfilter/ip_tables.c 2005-03-17 17:35:05 -08:00 +++ b/net/ipv4/netfilter/ip_tables.c 2005-03-17 17:35:05 -08:00 @@ -923,7 +923,7 @@ } /* And one copy for every other CPU */ - for (i = 1; i < NR_CPUS; i++) { + for (i = 1; i < num_possible_cpus(); i++) { memcpy(newinfo->entries + SMP_ALIGN(newinfo->size)*i, newinfo->entries, SMP_ALIGN(newinfo->size)); @@ -945,7 +945,7 @@ struct ipt_entry *table_base; unsigned int i; - for (i = 0; i < NR_CPUS; i++) { + for (i = 0; i < num_possible_cpus(); i++) { table_base = (void *)newinfo->entries + TABLE_OFFSET(newinfo, i); @@ -992,7 +992,7 @@ unsigned int cpu; unsigned int i; - for (cpu = 0; cpu < NR_CPUS; cpu++) { + for (cpu = 0; cpu < num_possible_cpus(); cpu++) { i = 0; IPT_ENTRY_ITERATE(t->entries + TABLE_OFFSET(t, cpu), t->size, @@ -1130,7 +1130,7 @@ return -ENOMEM; newinfo = vmalloc(sizeof(struct ipt_table_info) - + SMP_ALIGN(tmp.size) * NR_CPUS); + + SMP_ALIGN(tmp.size) * num_possible_cpus()); if (!newinfo) return -ENOMEM; @@ -1460,7 +1460,7 @@ = { 0, 0, 0, { 0 }, { 0 }, { } }; newinfo = vmalloc(sizeof(struct ipt_table_info) - + SMP_ALIGN(repl->size) * NR_CPUS); + + SMP_ALIGN(repl->size) * num_possible_cpus()); if (!newinfo) return -ENOMEM; On 10/10/05, David S. Miller <davem@davemloft.net> wrote: > From: seb@frankengul.org > Date: Mon, 10 Oct 2005 10:25:07 +0200 > > > Indeed they are. Does the patch assume that cpus are numbered in a > > row ? > > Yes, and that assumption is incorrect. > > > Now, I reverted the patch for ip_tables.c, ip6_tables.c and ebtables.c. > > Everything is working ok (11h uptime). > > Right. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Joseph Murawski Hartford, CT ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-10-19 2:13 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4347A731.7010509@frankengul.org>
[not found] ` <4348EFF4.3040305@frankengul.org>
2005-10-09 18:28 ` Sparc64 U60: no iptables Sébastien Bernard
2005-10-10 3:26 ` David S. Miller
2005-10-10 8:25 ` seb
2005-10-10 18:16 ` David S. Miller
2005-10-19 2:13 ` Joseph Murawski
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox