INTERFACE_MAX is not proper

Bug #176299 reported by Fabio Massimo Di Nitto
2
Affects Status Importance Assigned to Milestone
openais (Fedora)
Fix Released
Medium
openais (Ubuntu)
Fix Released
Undecided
Soren Hansen

Bug Description

Binary package hint: openais

Description of problem:

exec/totem.h defines INTERFACE_MAX to 2. This is very limiting and it is not
coherent with the rest of the cluster stack.

openais limits to 2
kernel dlm to 3
dlm_controld to 4

Those values should be at least alligned to 4 or higher.

In theory a dynamic allocation here would be the winner.

with the default set to 2, configuring 3 rings in openais.conf (passive mode,
since active it totally broken), will lead openais to crash because of memory
corruption (there is no protection within the code to try to init and config
only INTERFACE_MAX).

Version-Release number of selected component (if applicable):

trunk

How reproducible:

always

Steps to Reproduce:
1. given default svn checkout
2. configure INTERFACE_MAX + 1 rings in passive mode
3. fire up aisexec.

(tested on amd64 with glibc-2.7 will report memory corruption detected by glibc)

Actual results:

aisexec crashes and dies.

Expected results:

should work no matter how many rings i configure. hardcoded limitations are bad
and it is not even documented.

Additional info:

Related branches

Revision history for this message
In , Fabio (fabio-redhat-bugs) wrote :

Description of problem:

exec/totem.h defines INTERFACE_MAX to 2. This is very limiting and it is not
coherent with the rest of the cluster stack.

openais limits to 2
kernel dlm to 3
dlm_controld to 4

Those values should be at least alligned to 4 or higher.

In theory a dynamic allocation here would be the winner.

with the default set to 2, configuring 3 rings in openais.conf (passive mode,
since active it totally broken), will lead openais to crash because of memory
corruption (there is no protection within the code to try to init and config
only INTERFACE_MAX).

Version-Release number of selected component (if applicable):

trunk

How reproducible:

always

Steps to Reproduce:
1. given default svn checkout
2. configure INTERFACE_MAX + 1 rings in passive mode
3. fire up aisexec.

(tested on amd64 with glibc-2.7 will report memory corruption detected by glibc)

Actual results:

aisexec crashes and dies.

Expected results:

should work no matter how many rings i configure. hardcoded limitations are bad
and it is not even documented.

Additional info:

Changed in openais:
assignee: nobody → shawarma
Revision history for this message
Fabio Massimo Di Nitto (fabbione) wrote :
Revision history for this message
Soren Hansen (soren) wrote :

openais (0.82-0ubuntu7) hardy; urgency=low

  [ Fabio M. Di Nitto ]
  * Update to SVN trunk in preparation of 0.83.
  * rediff all patches.

  [ Soren Hansen ]
  * 004_increase_max_rings.dpatch: Increase INTERFACE_MAX to 4 (LP: #176299)
    Thanks Fabio!

 -- Soren Hansen <email address hidden> Fri, 14 Dec 2007 09:34:53 +0100

Changed in openais:
status: New → Fix Released
Changed in openais:
status: Unknown → Confirmed
Revision history for this message
In , Lon (lon-redhat-bugs) wrote :

*** Bug 424671 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Fabio (fabio-redhat-bugs) wrote :

The cman crash has been fixed.

Time to address the inconsistency.

Fabio

Revision history for this message
In , Steven (steven-redhat-bugs) wrote :

breaks compatability will not be changed in rhel5.

Revision history for this message
In , Fabio (fabio-redhat-bugs) wrote :

It does not need to be fixed in rhel5 but can be done in trunk and forward releases.

Changed in openais:
status: Confirmed → Fix Released
Changed in openais (Fedora):
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.