Re: [devel] [PATCH 2 of 2] AMFND: Fix SC failover during headless sync before standby AMFD comes up [#2162]
Hi Nagu,
I misunderstood your point, and now I get it.
In my test I see it works as expected - SU2 becomes Act and no
assignment for SU1
I guess in your test some how the cluster initiation timer has not been
started on SC2 (new active), there could be a missing case in the patch.
Could you please share me the trace?
Thanks,
Minh
On 13/01/17 21:48, Nagendra Kumar wrote:
> Hi Minh,
> Please check my response inlined with [Nagu].
>
> Thanks
> -Nagu
>> -Original Message-
>> From: minh chau [mailto:minh.c...@dektech.com.au]
>> Sent: 13 January 2017 03:53
>> To: Nagendra Kumar; hans.nordeb...@ericsson.com; Praveen Malviya;
>> gary@dektech.com.au
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: Re: [PATCH 2 of 2] AMFND: Fix SC failover during headless sync
>> before standby AMFD comes up [#2162]
>>
>> Hi Nagu,
>>
>> Thanks for reviewing, please see comments inline.
>>
>> Thanks,
>> Minh
>>
>> On 12/01/17 21:48, Nagendra Kumar wrote:
>>> Hi Minh,
>>> Though I am not able to simulate the problem, I tested as below:
>>> 1. Start SC1, SC2, PL-3 and PL-4. Configure SU1 on PL-3 as Act and SU2 on
>> PL-4 as Standby.
>>> 2. Stop SC1 and SC2 and then stop PL-3.
>>> 3. Start SC-1 and SC-2. When SC-2 prints Cold sync complete, stop SC1. SC2
>> becomes Act.
>> [M]: As SU1 is on PL3, SU2 is on PL4, and If PL-3 is stopped, then only
>> SU2 has active assignment
> [Nagu]: PL-3 is stopped in step #2.
>>> In this case, SC-2 contains both SU1(Act) and SU2(Standby) assignments.
>>> Ideally, SU2 assignments should have been Act and there shouldn't be SU1
>> assignment.
>> [M]: This seems to be another test where SU1 and SU2 are hosted on SC2,
>> then both SU1 and SU2 should get assignment
> [Nagu]: I mean to say command 'amf-state siass' run on SC-1 displays both SU1
> and SU2 assignments.
> SU1 and SU2 are hosted on PL-3 and PL-4 respectively.
> This is similar test case, which is mentioned in the ticket?
>>>
>> safSISU=safSu=SU1\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe
>> mo,safApp=AmfDemo1
>>> saAmfSISUHAState=ACTIVE(1)
>>> saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
>>>
>> safSISU=safSu=SU2\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe
>> mo,safApp=AmfDemo1
>>> saAmfSISUHAState=STANDBY(2)
>>> saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
>>>
>>> Please check.
>>>
>>> Thanks
>>> -Nagu
>>>
-Original Message-
From: Minh Hon Chau [mailto:minh.c...@dektech.com.au]
Sent: 08 November 2016 08:53
To: hans.nordeb...@ericsson.com; Nagendra Kumar; Praveen Malviya;
gary@dektech.com.au; minh.c...@dektech.com.au
Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 2 of 2] AMFND: Fix SC failover during headless sync
before standby AMFD comes up [#2162]
osaf/services/saf/amf/amfnd/di.cc | 7 +--
osaf/services/saf/amf/amfnd/susm.cc | 6 ++
2 files changed, 11 insertions(+), 2 deletions(-)
This case of SC failover causes new active AMFD getting stuck in
node_up messages
Say first active controller is SC1, which goes down during headless sync.
Therefore, the amfnd on SC2 receives mds_down of AVD, then both
is_avd_down and amfd_sync_required are set to true. When SC2 takes
over active role, amfnd on SC2 receives mds_up, but only is_avd_down
is set to false and the variable amfd_sync_required remains true.
When amfnd-SC2 finishes initiating middleware SU, it needs to send
su_oper message to AMFD, but it is failed to send out due to
>> amfd_sync_required.
In this scenario of SC failover, amfd_sync_required needs to set to
false when amfnd on SC2 receives su_pres message on middleware SUs.
That means amfnd on active controller does not need to wait for
set_leds message, to be informed that cluster initiation is done, so
that amfnd can sen su_oper messages to AMFD. This logic also aligns
with normal headless scenario, where amfnd on active controller has
amfd_sync_required initially marked as false because no middleware
SUs are initiated. When amfd_sync_required is true that means amfnd
all middleware SUs are initiated and assigned before headless, thus
amfnd needs to wait for cluster initiation after headless.
diff --git a/osaf/services/saf/amf/amfnd/di.cc
b/osaf/services/saf/amf/amfnd/di.cc
--- a/osaf/services/saf/amf/amfnd/di.cc
+++ b/osaf/services/saf/amf/amfnd/di.cc
@@ -748,7 +748,8 @@ uint32_t avnd_di_oper_send(AVND_CB *cb,
if (avnd_diq_rec_add(cb, &msg) == nullptr) {
rc = NCSCC_RC_FAILURE;
}
- LOG_NO("avnd_di_oper_send() deferred as AMF director is
offline");
+ LOG_NO("avnd_di_oper_send() deferred as AMF director is
offline(%d),"
+ " or sync is required(%d)", cb->is_avd_d
Re: [devel] [PATCH 1 of 1] ckpt: fix extended name issues in the library [#2128]
Hi Zoran,
ACK from me.
Sincerely,
Hoang
-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com]
Sent: Friday, January 13, 2017 10:15 AM
To: Zoran Milinkovic
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [devel] [PATCH 1 of 1] ckpt: fix extended name issues in the
library [#2128]
Hi Zora,
ACK.
LONG DN not tested .
-AVM
On 1/10/2017 8:57 PM, Zoran Milinkovic wrote:
> src/ckpt/agent/cpa_api.c | 26 +++---
> src/ckpt/ckptnd/cpnd_evt.c | 12
> 2 files changed, 19 insertions(+), 19 deletions(-)
>
>
> Fix string temination issues when SaNameT value is provided to
saCkptCheckpointOpen(), saCkptCheckpointOpenAsync() and
saCkptCheckpointUnlink().
>
> diff --git a/src/ckpt/agent/cpa_api.c b/src/ckpt/agent/cpa_api.c
> --- a/src/ckpt/agent/cpa_api.c
> +++ b/src/ckpt/agent/cpa_api.c
> @@ -871,13 +871,17 @@ SaAisErrorT saCkptCheckpointOpen(SaCkptH
> SaTimeT time_out=0;
> CPA_GLOBAL_CKPT_NODE *gc_node = NULL;
> SaConstStringT ckpt_name = NULL;
> + size_t ckpt_name_len;
>
> TRACE_ENTER2("SaCkptCheckpointHandleT passed is %llx",ckptHandle);
> if ((checkpointName == NULL) || (checkpointHandle == NULL) ||
(osaf_extended_name_length(checkpointName) == 0)) {
> TRACE_4("Cpa CkptOpen Api failed with return
value:%d,ckptHandle:%llx", SA_AIS_ERR_INVALID_PARAM, ckptHandle);
> TRACE_LEAVE2("API return code = %u",
SA_AIS_ERR_INVALID_PARAM);
> return SA_AIS_ERR_INVALID_PARAM;
> - } else if (osaf_extended_name_length(checkpointName) >
kOsafMaxDnLength) {
> + }
> +
> + ckpt_name_len = osaf_extended_name_length(checkpointName);
> + if (ckpt_name_len > kOsafMaxDnLength) {
> TRACE_4("Cpa CkptOpen Api failed with return
value:%d,ckptHandle:%llx", SA_AIS_ERR_TOO_BIG, ckptHandle);
> TRACE_LEAVE2("API return code = %u", SA_AIS_ERR_TOO_BIG);
> return SA_AIS_ERR_TOO_BIG;
> @@ -962,7 +966,7 @@ SaAisErrorT saCkptCheckpointOpen(SaCkptH
> lc_node->cl_hdl = ckptHandle;
> lc_node->open_flags = checkpointOpenFlags;
>
> - lc_node->ckpt_name = strdup(ckpt_name);
> + lc_node->ckpt_name = strndup(ckpt_name, ckpt_name_len);
>
> /* Add CPA_LOCAL_CKPT_NODE to lcl_ckpt_hdl_tree */
> proc_rc = cpa_lcl_ckpt_node_add(&cb->lcl_ckpt_tree, lc_node); @@
> -981,7 +985,7 @@ SaAisErrorT saCkptCheckpointOpen(SaCkptH
> evt.info.cpnd.info.openReq.client_hdl = ckptHandle;
> evt.info.cpnd.info.openReq.lcl_ckpt_hdl = lc_node->lcl_ckpt_hdl;
>
> - osaf_extended_name_lend(ckpt_name,
&evt.info.cpnd.info.openReq.ckpt_name);
> + osaf_extended_name_lend(lc_node->ckpt_name,
> +&evt.info.cpnd.info.openReq.ckpt_name);
>
> if (checkpointCreationAttributes) {
> evt.info.cpnd.info.openReq.ckpt_attrib =
> *checkpointCreationAttributes; @@ -1178,6 +1182,7 @@ SaAisErrorT
saCkptCheckpointOpenAsync(Sa
> CPA_CLIENT_NODE *cl_node = NULL;
> uint32_t proc_rc = NCSCC_RC_SUCCESS;
> SaConstStringT ckpt_name = NULL;
> + size_t ckpt_name_len;
>
> TRACE_ENTER2("SaCkptCheckpointHandleT passed is %llx",ckptHandle);
>
> @@ -1185,7 +1190,10 @@ SaAisErrorT saCkptCheckpointOpenAsync(Sa
> TRACE_4("cpa CkptOpenAsync Api failed with return
value:%d,ckptHandle:%llx", SA_AIS_ERR_INVALID_PARAM, ckptHandle);
> TRACE_LEAVE2("API return code = %u",
SA_AIS_ERR_INVALID_PARAM);
> return SA_AIS_ERR_INVALID_PARAM;
> - } else if (osaf_extended_name_length(checkpointName) >
kOsafMaxDnLength) {
> + }
> +
> + ckpt_name_len = osaf_extended_name_length(checkpointName);
> + if (ckpt_name_len > kOsafMaxDnLength) {
> TRACE_4("Cpa CkptOpenAsync Api failed with return
value:%d,ckptHandle:%llx", SA_AIS_ERR_TOO_BIG, ckptHandle);
> TRACE_LEAVE2("API return code = %u", SA_AIS_ERR_TOO_BIG);
> return SA_AIS_ERR_TOO_BIG;
> @@ -1262,7 +1270,7 @@ SaAisErrorT saCkptCheckpointOpenAsync(Sa
> lc_node->lcl_ckpt_hdl = NCS_PTR_TO_UNS64_CAST(lc_node);
> lc_node->cl_hdl = ckptHandle;
> lc_node->open_flags = checkpointOpenFlags;
> - lc_node->ckpt_name = strdup(ckpt_name);
> + lc_node->ckpt_name = strndup(ckpt_name, ckpt_name_len);
>
> /* Add CPA_LOCAL_CKPT_NODE to lcl_ckpt_hdl_tree */
> proc_rc = cpa_lcl_ckpt_node_add(&cb->lcl_ckpt_tree, lc_node); @@
> -1281,7 +1289,7 @@ SaAisErrorT saCkptCheckpointOpenAsync(Sa
> evt.info.cpnd.info.openReq.client_hdl = ckptHandle;
> evt.info.cpnd.info.openReq.lcl_ckpt_hdl = lc_node->lcl_ckpt_hdl;
>
> - osaf_extended_name_lend(ckpt_name,
&evt.info.cpnd.info.openReq.ckpt_name);
> + osaf_extended_name_lend(lc_node->ckpt_name,
> +&evt.info.cpnd.info.openReq.ckpt_name);
>
> if (checkpointCreationAttributes) {
> evt.info.cpnd.info.openReq.ckpt_attrib =
> *checkpointCreationAttributes; @@ -1585,7
Re: [devel] [PATCH 1 of 1] ckpt: fix memory leak in saCkptCheckpointRead [#2256]
Hi Zoran,
ACK.
Sincerely,
Hoang
-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com]
Sent: Wednesday, January 11, 2017 11:07 AM
To: Zoran Milinkovic
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [devel] [PATCH 1 of 1] ckpt: fix memory leak in
saCkptCheckpointRead [#2256]
Hi Zoran,
ACK Not tested.
-AVM
On 1/10/2017 9:58 PM, Zoran Milinkovic wrote:
> src/ckpt/agent/cpa_proc.c | 22 --
> 1 files changed, 16 insertions(+), 6 deletions(-)
>
>
> Allocated memory in cpa_proc_build_data_access_evt() is freed.
>
> diff --git a/src/ckpt/agent/cpa_proc.c b/src/ckpt/agent/cpa_proc.c
> --- a/src/ckpt/agent/cpa_proc.c
> +++ b/src/ckpt/agent/cpa_proc.c
> @@ -1124,11 +1124,13 @@ uint32_t cpa_proc_build_data_access_evt(
>SaSizeT maxSectionSize, SaUint32T
*errflag, CPSV_CKPT_DATA **ckpt_data)
> {
> CPSV_CKPT_DATA *tmp_ckpt_data = NULL;
> + *ckpt_data = NULL;
> if (numberOfElements > 0) {
> while (numberOfElements > 0) {
> tmp_ckpt_data = m_MMGR_ALLOC_CPSV_CKPT_DATA;
> - if (tmp_ckpt_data == NULL)
> - return NCSCC_RC_FAILURE;
> + if (tmp_ckpt_data == NULL) {
> + goto free_mem;
> + }
> memset(tmp_ckpt_data, '\0', sizeof(CPSV_CKPT_DATA));
>
> switch (data_access_type) {
> @@ -1150,7 +1152,7 @@ uint32_t cpa_proc_build_data_access_evt(
> ioVector[numberOfElements -
1].dataSize) > maxSectionSize) {
> if (errflag != NULL)
> *errflag =
(numberOfElements - 1);
> - return NCSCC_RC_FAILURE;
> + goto free_mem;
> } else
> tmp_ckpt_data->dataSize =
ioVector[numberOfElements - 1].dataSize;
> }
> @@ -1159,7 +1161,7 @@ uint32_t cpa_proc_build_data_access_evt(
> break;
>
> default:
> - return NCSCC_RC_FAILURE;
> + goto free_mem;
> }
>
> if (*ckpt_data == NULL)
> @@ -1171,9 +1173,17 @@ uint32_t cpa_proc_build_data_access_evt(
> numberOfElements--;
> }
> return NCSCC_RC_SUCCESS;
> - } else {
> - return NCSCC_RC_FAILURE;
> }
> +
> +free_mem:
> + free(tmp_ckpt_data);
> + while(*ckpt_data) {
> + tmp_ckpt_data = *ckpt_data;
> + *ckpt_data = tmp_ckpt_data->next;
> + m_MMGR_FREE_CPSV_CKPT_DATA(tmp_ckpt_data);
> + }
> +
> + return NCSCC_RC_FAILURE;
> }
>
>
> /*
> ***
--
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon
Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
Re: [devel] [PATCH 1 of 1] ckpt: fix memory leak in cpd_a2s_ckpt_usr_info [#2257]
Hi Zoran,
ACK.
Sincerely,
Hoang
-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com]
Sent: Wednesday, January 11, 2017 10:59 AM
To: Zoran Milinkovic
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [devel] [PATCH 1 of 1] ckpt: fix memory leak in
cpd_a2s_ckpt_usr_info [#2257]
Hi Zoran,
ACK Not tested.
-AVM
On 1/10/2017 9:18 PM, Zoran Milinkovic wrote:
> src/ckpt/ckptd/cpd_red.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
>
> Fix memory leak in cpd_a2s_ckpt_usr_info() in cpd_red.c
>
> diff --git a/src/ckpt/ckptd/cpd_red.c b/src/ckpt/ckptd/cpd_red.c
> --- a/src/ckpt/ckptd/cpd_red.c
> +++ b/src/ckpt/ckptd/cpd_red.c
> @@ -339,5 +339,8 @@ void cpd_a2s_ckpt_usr_info(CPD_CB *cb, C
> TRACE_4("cpd A2S ckpt user info async update failed");
> else
> TRACE_1("cpd A2S ckpt user info async update success");
> +
> + free(cpd_msg.info.usr_info_2.node_list);
> +
> TRACE_LEAVE();
> }
--
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon
Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
