#1961 Issues in Opensaf PLMS services with openHPI

[Subrata Nath]

Hello,

I have installed opensaf 5.0.0 without the PLMS fine for contoller node HA purpose and it's works fine. Now I would like to use opensaf PLMS with the openHPI.

My configure script command is -

./configure CPPFLAGS=-DRUNASROOT OSAF_HARDEN_FLAGS="-fstack-protector-all -D_FORTIFY_SOURCE=2" HPI_LIBS="-L/usr/local/lib -lopenhpimarshal -lopenhpiutils -lopenhpi" --enable-hpi --with-openhpi --with-hpi-interface=B03 --enable-tipc=yes --enable-imm-pbe=yes --enable-ais-plm --enable-ais-smf --enable-ais-msg --enable-ais-lck --enable-ais-evt --enable-ais-ckpt --enable-ntf-imcn

Following issue is observed. have made a work around code fix but i would like to check if these issues were found already and fix is planned in next releases -

opensaf-5.0.0/osaf/services/saf/plmsv/plms/plms_main.c the global declaration of

static PLMSCB _plms_cb;
PLMSCB plms_cb = &_plms_cb;

is being masked out by the line 558 in /opensaf-5.0.0/osaf/libs/common/plmsv/include/plms.h which declares the same var. So with this, /osaf/services/saf/plmsv/plms/hpi_intf/hpi_hsm getting NULL value for the plms_cb pointer.

Similar issue is applicable for the following global variable as well

HSM_HA_STATE hsm_ha_state = {PTHREAD_MUTEX_INITIALIZER,
PTHREAD_COND_INITIALIZER,
SA_AMF_HA_ACTIVE};
HRB_HA_STATE hrb_ha_state = {PTHREAD_MUTEX_INITIALIZER,
PTHREAD_COND_INITIALIZER,
SA_AMF_HA_ACTIVE};

They are defined in plms.h without extern and hence /osaf/services/saf/plmsv/plms/hpi_intf/hpi_hsm.c or plms_hrb.c, is not able to find the same values as assigined by plms_main.c

WA fix i made is as described below. But please let me know if it's known issue or not and if there is any correction in upcoming releases.

1. Declare with extern in opensaf-5.0.0/osaf/libs/common/plmsv/include/plms.h.
2. Make the two separate global copies with the same name – one in osaf/services/saf/plmsv/plms/plms_main.c (PLMS_CB plms_cb; ) and another one in /home/system/opensaf-5.0.0/osaf/services/saf/plmsv/plms/hpi_intf/plms_hsm.c(PLMS_CB plms_cb;). So all the files in osaf/services/saf/plmsv/plms/ will see the global copy from osaf/services/saf/plmsv/plms/plms_main.c and all the files under 5.0.0/osaf/services/saf/plmsv/plms/hpi_intf/ will see the global copy in 5.0.0/osaf/services/saf/plmsv/plms/hpi_intf/plms_hsm.c.

3. Now osaf/services/saf/plmsv/plms/plms_main.c allocates the memory for it’s own copy of the global variable and during the first function call to 5.0.0/osaf/services/saf/plmsv/plms/hpi_intf/plms_hsm.c, pass the point as pointer argument. This function parameter now assigned to the 5.0.0/osaf/services/saf/plmsv/plms/hpi_intf/plms_hsm.c – global variable.

           SaUint32T plms_hsm_initialize(PLMS_HPI_CONFIG *hpi_cfg,PLMS_CB **plms_cb1) -----------newly added parameters
        {
                    plms_cb = *plms_cb1;
   

4. Now both the global variables are pointing to the same memory location.

Similar correction is made for HSM_HA_STATE hsm_ha_state and HRB_HA_STATE hrb_ha_state as well.

Regards,
Subrata

[Alex Jones]

This issue has been addressed in 5.1 with the virtualization patch (ticket 1431).

[Alex Jones]

This works in 5.18.04 on CentOS 7.