Problem with ipset on sparc64

Problem with ipset on sparc64

[Chini, Georg (HP App Services)]

Hello,

I'm using ipset 3.2 on a sparc64 system (ultra2), kernel 2.6.31.5, Debian 5.
Everything works fine, but the -L option shows strange values for a portmap.
Example:
Added Port 10, 20 and 456 to map xyz. Ipset -L xyz shows:
Name: xyz
Type: portmap
References: 1
Default binding: 
Header: from: 1 to: 65535
Members:
42
52
488
Bindings:

The iptables match works correctly, it is just the listing.
Any idea what's wrong?

Regards
       Georg Chini

Re: Problem with ipset on sparc64

[Jan Engelhardt]

On Wednesday 2009-11-04 22:07, Chini, Georg (HP App Services) wrote:

>Hello,
>
>I'm using ipset 3.2 on a sparc64 system (ultra2), kernel 2.6.31.5, Debian 5.
>Everything works fine, but the -L option shows strange values for a portmap.
>Example:
>Added Port 10, 20 and 456 to map xyz. Ipset -L xyz shows:

If you explicitly compile ipset as a 64-bit program rather than the
32-bit default that is used on sparc, will the correct values be
shown?

>Members:
>42
>52
>488
>Bindings:
>
>The iptables match works correctly, it is just the listing.
>Any idea what's wrong?

AW: Problem with ipset on sparc64

[Chini, Georg (HP App Services)]

>
>I'm using ipset 3.2 on a sparc64 system (ultra2), kernel 2.6.31.5, Debian 5.
>Everything works fine, but the -L option shows strange values for a portmap.


If you explicitly compile ipset as a 64-bit program rather than the
32-bit default that is used on sparc, will the correct values be
shown?

Thanks for the fast reply. I added -m64 to cc and ld options and
recompiled. Is that correct? If yes, I now get a bus error instead
of a wrong listing. Or do I have to change anything else?

Re: Problem with ipset on sparc64

[Jan Engelhardt]

On Wednesday 2009-11-04 22:50, Chini, Georg (HP App Services) wrote:
>>
>>I'm using ipset 3.2 on a sparc64 system (ultra2), kernel 2.6.31.5, Debian 5.
>>Everything works fine, but the -L option shows strange values for a portmap.
>
>
>If you explicitly compile ipset as a 64-bit program rather than the
>32-bit default that is used on sparc, will the correct values be
>shown?
>
>Thanks for the fast reply. I added -m64 to cc and ld options and
>recompiled. Is that correct? If yes, I now get a bus error instead
>of a wrong listing. Or do I have to change anything else?

Bus error means something was not quite correctly aligned
(yet another ipset bug).

The lack of cheap access to big-endian, alignment-sensitive hardware
means many codes do not get the testing they deserve :-/

To workaround the alignedness issue, you could take an x86_64 machine
and compile a strictly 32-bit ipset on it, and see whether the values
are also off.

Re: Problem with ipset on sparc64

[Jozsef Kadlecsik]

On Wed, 4 Nov 2009, Jan Engelhardt wrote:

> On Wednesday 2009-11-04 22:50, Chini, Georg (HP App Services) wrote:
> >>
> >>I'm using ipset 3.2 on a sparc64 system (ultra2), kernel 2.6.31.5, Debian 5.
> >>Everything works fine, but the -L option shows strange values for a portmap.
> >
> >
> >If you explicitly compile ipset as a 64-bit program rather than the
> >32-bit default that is used on sparc, will the correct values be
> >shown?
> >
> >Thanks for the fast reply. I added -m64 to cc and ld options and
> >recompiled. Is that correct? If yes, I now get a bus error instead
> >of a wrong listing. Or do I have to change anything else?
> 
> Bus error means something was not quite correctly aligned
> (yet another ipset bug).
> 
> The lack of cheap access to big-endian, alignment-sensitive hardware
> means many codes do not get the testing they deserve :-/

Yes, that's exaxtly. Funnily enough a few years ago I toyed the idea to 
buy a thrown out SPARCCenter2000 but I didn't have enough power in my 
place to boot up such a machine...
 
> To workaround the alignedness issue, you could take an x86_64 machine
> and compile a strictly 32-bit ipset on it, and see whether the values
> are also off.

I'll work on fixing the bug.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Problem with ipset on sparc64

[Jozsef Kadlecsik]

On Thu, 5 Nov 2009, Jozsef Kadlecsik wrote:

> On Wed, 4 Nov 2009, Jan Engelhardt wrote:
> 
> > On Wednesday 2009-11-04 22:50, Chini, Georg (HP App Services) wrote:
> > >>
> > >>I'm using ipset 3.2 on a sparc64 system (ultra2), kernel 2.6.31.5, Debian 5.
> > >>Everything works fine, but the -L option shows strange values for a portmap.
> > >
> > >
> > >If you explicitly compile ipset as a 64-bit program rather than the
> > >32-bit default that is used on sparc, will the correct values be
> > >shown?
> > >
> > >Thanks for the fast reply. I added -m64 to cc and ld options and
> > >recompiled. Is that correct? If yes, I now get a bus error instead
> > >of a wrong listing. Or do I have to change anything else?
> > 
> > Bus error means something was not quite correctly aligned
> > (yet another ipset bug).
> > 
> > The lack of cheap access to big-endian, alignment-sensitive hardware
> > means many codes do not get the testing they deserve :-/
> 
> Yes, that's exaxtly. Funnily enough a few years ago I toyed the idea to 
> buy a thrown out SPARCCenter2000 but I didn't have enough power in my 
> place to boot up such a machine...

In a few days I'll be able to use an Ultra 10 for testing - that'll settle 
the validating on big endian hardware.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Problem with ipset on sparc64

[Jan Engelhardt]

On Thursday 2009-11-05 11:36, Jozsef Kadlecsik wrote:
>> > The lack of cheap access to big-endian, alignment-sensitive hardware
>> > means many codes do not get the testing they deserve :-/
>> 
>> Yes, that's exaxtly. Funnily enough a few years ago I toyed the idea to 
>> buy a thrown out SPARCCenter2000 but I didn't have enough power in my 
>> place to boot up such a machine...
>
>In a few days I'll be able to use an Ultra 10 for testing - that'll settle 
>the validating on big endian hardware.

Does not Dave have some 64-bit sparks in the basement that may
be shared and given remote access to?
(It seems Netfilter is one of the subsystems most plagued by endianess, 
aligning and sizeof(long) variances ;-)

Re: Problem with ipset on sparc64

[Jozsef Kadlecsik]

On Thu, 5 Nov 2009, Jan Engelhardt wrote:

> On Thursday 2009-11-05 11:36, Jozsef Kadlecsik wrote:
> >> > The lack of cheap access to big-endian, alignment-sensitive hardware
> >> > means many codes do not get the testing they deserve :-/
> >> 
> >> Yes, that's exaxtly. Funnily enough a few years ago I toyed the idea to 
> >> buy a thrown out SPARCCenter2000 but I didn't have enough power in my 
> >> place to boot up such a machine...
> >
> >In a few days I'll be able to use an Ultra 10 for testing - that'll settle 
> >the validating on big endian hardware.
> 
> Does not Dave have some 64-bit sparks in the basement that may
> be shared and given remote access to?
> (It seems Netfilter is one of the subsystems most plagued by endianess, 
> aligning and sizeof(long) variances ;-)

Dave don't need to dig into his SPARC collection :-) - I'll setup this 
machine as a testbed for netfilter/ipset.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Problem with ipset on sparc64

[Jan Engelhardt]

On Thursday 2009-11-05 12:21, Jozsef Kadlecsik wrote:
>> >In a few days I'll be able to use an Ultra 10 for testing - that'll settle 
>> >the validating on big endian hardware.
>> 
>> Does not Dave have some 64-bit sparks in the basement that may
>> be shared and given remote access to?
>> (It seems Netfilter is one of the subsystems most plagued by endianess, 
>> aligning and sizeof(long) variances ;-)
>
>Dave don't need to dig into his SPARC collection :-) - I'll setup this 
>machine as a testbed for netfilter/ipset.

But since the Ultra10 is just 32-bit IIRC, you would not have a
chance to hit the rare 64-bit alignment problems (both in terms of
SIGBUS and "invalid match size 16 != 12"), should there be any.

Another issue with ipset on sparc64

[Chini, Georg (HP App Services)]

Hello,

I found another issue with ipset on sparc64 (Ultra2, 2 CPU, 2.6.31.5,
Debian5).
When I flush an iptreemap, one (of two) ksoftirqd goes up to 25% CPU
load and remains there until I delete the set. I don't have to place
anything in the map, just doing "ipset -N abc iptreemap; ipset -F abc" is
enough. Doing that again with another map will add 25% load to the
second ksoftirqd. Adding more maps will not change things further.

Regards
       Georg Chini

Re: Another issue with ipset on sparc64

[Jozsef Kadlecsik]

On Thu, 5 Nov 2009, Chini, Georg (HP App Services) wrote:

> I found another issue with ipset on sparc64 (Ultra2, 2 CPU, 2.6.31.5,
> Debian5).
> When I flush an iptreemap, one (of two) ksoftirqd goes up to 25% CPU
> load and remains there until I delete the set. I don't have to place
> anything in the map, just doing "ipset -N abc iptreemap; ipset -F abc" is
> enough. Doing that again with another map will add 25% load to the
> second ksoftirqd. Adding more maps will not change things further.

Thanks the reports! 

Tomorrow I'll setup the testbed and I'll be able to run the full test 
suite in ipset. Then I can work on cleaning up all bigendian issues.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Another issue with ipset on sparc64

[Jozsef Kadlecsik]

On Thu, 5 Nov 2009, Jozsef Kadlecsik wrote:

> On Thu, 5 Nov 2009, Chini, Georg (HP App Services) wrote:
> 
> > I found another issue with ipset on sparc64 (Ultra2, 2 CPU, 2.6.31.5,
> > Debian5).
> > When I flush an iptreemap, one (of two) ksoftirqd goes up to 25% CPU
> > load and remains there until I delete the set. I don't have to place
> > anything in the map, just doing "ipset -N abc iptreemap; ipset -F abc" is
> > enough. Doing that again with another map will add 25% load to the
> > second ksoftirqd. Adding more maps will not change things further.
> 
> Thanks the reports! 
> 
> Tomorrow I'll setup the testbed and I'll be able to run the full test 
> suite in ipset. Then I can work on cleaning up all bigendian issues.

Please give a try to the new ipset release - it should fix all of the 
issues you reported.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

AW: Another issue with ipset on sparc64

[Chini, Georg (HP App Services)]

Hi Jozsef,

-----Ursprüngliche Nachricht-----
Von: Jozsef Kadlecsik [mailto:kadlec@blackhole.kfki.hu] 
Gesendet: Dienstag, 10. November 2009 22:18
An: Chini, Georg (HP App Services)
Cc: netfilter-devel@vger.kernel.org
Betreff: Re: Another issue with ipset on sparc64


> Please give a try to the new ipset release - it should fix all of the 
> issues you reported.

Works nicely! Both issues are fixed. Thanks a lot.

Do you have any idea when you will have IPv6 support implemented?

Regards
       Georg
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AW: Another issue with ipset on sparc64

[Jozsef Kadlecsik]

On Wed, 11 Nov 2009, Chini, Georg (HP App Services) wrote:

> > Please give a try to the new ipset release - it should fix all of the 
> > issues you reported.
> 
> Works nicely! Both issues are fixed. Thanks a lot.

Great!
 
> Do you have any idea when you will have IPv6 support implemented?

I hope by the end of year, if nothing defers me.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Problem with ipset on sparc64

[Jozsef Kadlecsik]

On Thu, 5 Nov 2009, Jan Engelhardt wrote:

> On Thursday 2009-11-05 12:21, Jozsef Kadlecsik wrote:
> >> >In a few days I'll be able to use an Ultra 10 for testing - that'll settle 
> >> >the validating on big endian hardware.
> >> 
> >> Does not Dave have some 64-bit sparks in the basement that may
> >> be shared and given remote access to?
> >> (It seems Netfilter is one of the subsystems most plagued by endianess, 
> >> aligning and sizeof(long) variances ;-)
> >
> >Dave don't need to dig into his SPARC collection :-) - I'll setup this 
> >machine as a testbed for netfilter/ipset.
> 
> But since the Ultra10 is just 32-bit IIRC, you would not have a
> chance to hit the rare 64-bit alignment problems (both in terms of
> SIGBUS and "invalid match size 16 != 12"), should there be any.

SUN Ultra 10 has got a 300, 333, 360, or 440-MHz UltraSPARC[tm]-IIi 
processor. So it's definitely a bigendian machine.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Problem with ipset on sparc64

[Jan Engelhardt]

On Thursday 2009-11-05 19:36, Jozsef Kadlecsik wrote:
>> >
>> >Dave don't need to dig into his SPARC collection :-) - I'll setup this 
>> >machine as a testbed for netfilter/ipset.
>> 
>> But since the Ultra10 is just 32-bit IIRC, you would not have a
>> chance to hit the rare 64-bit alignment problems (both in terms of
>> SIGBUS and "invalid match size 16 != 12"), should there be any.
>
>SUN Ultra 10 has got a 300, 333, 360, or 440-MHz UltraSPARC[tm]-IIi 
>processor. So it's definitely a bigendian machine.

Note that I did not mention endianess at all in the ">>" level.

Re: Problem with ipset on sparc64

[David Miller]

From: Jan Engelhardt <jengelh@medozas.de>
Date: Thu, 5 Nov 2009 12:30:55 +0100 (CET)

> But since the Ultra10 is just 32-bit IIRC, you would not have a
> chance to hit the rare 64-bit alignment problems (both in terms of
> SIGBUS and "invalid match size 16 != 12"), should there be any.

Ultra10 is sparc64 and thus 64-bit

Re: Problem with ipset on sparc64

[Jozsef Kadlecsik]

On Wed, 4 Nov 2009, Jan Engelhardt wrote:

> To workaround the alignedness issue, you could take an x86_64 machine
> and compile a strictly 32-bit ipset on it, and see whether the values
> are also off.

On x86_64 using a 32-bit ipset, the listed values are correct.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Problem with ipset on sparc64

[Jan Engelhardt]

On Thursday 2009-11-05 21:03, Jozsef Kadlecsik wrote:

>On Wed, 4 Nov 2009, Jan Engelhardt wrote:
>
>> To workaround the alignedness issue, you could take an x86_64 machine
>> and compile a strictly 32-bit ipset on it, and see whether the values
>> are also off.
>
>On x86_64 using a 32-bit ipset, the listed values are correct.

But that would not tell you if there are 64-bit quantities that
do not fulfill the 64-bit alignment, because x86 handles misaligned
reads transparently in hardware. Then again, the number of 64-bit
items is probably manageable and statically analyzable.