Sparc64 U60: no iptables

Sparc64 U60: no iptables

[Sébastien Bernard]

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;

-------------------

Re: Sparc64 U60: no iptables

[David S. Miller]

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".

Re: Sparc64 U60: no iptables

[seb]

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

Re: Sparc64 U60: no iptables

[David S. Miller]

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.

Re: Sparc64 U60: no iptables

[Joseph Murawski]

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