U60: no iptables

U60: no iptables

[Sébastien Bernard]

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

Re: U60: no iptables

[Emmanuel Kasper]

 >How can I get the copy of the trace without handwriting ?

You can use a serial console for that, with another machine connected to 
the serial port of your u60, with minicom/hyperterminal/tip
Sun machines handle that quite well.
See http://www.obsolyte.com/sunFAQ/serial/ ( amongst others )
Manu


Sébastien Bernard a écrit :

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


-- 
To UNSUBSCRIBE, email to debian-sparc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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

[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