Re: [devel] Review request log: Update LOG PR document with version 5.2 enhancements [#2200]

[Vu Minh Nguyen]

Hi Lennart,

 

Ack with one minor comment:

Consider to add caption for the table in section 2.1.1

 

Regards, Vu

 

From: Lennart Lund [mailto:lennart.l...@ericsson.com] 
Sent: Monday, March 6, 2017 3:59 PM
To: Vu Minh Nguyen ; Canh Van Truong
; 'A V Mahesh' ;
opensaf-devel@lists.sourceforge.net
Subject: RE: Review request log: Update LOG PR document with version 5.2
enhancements [#2200]

 

Hi

 

I have done a number of updates because of comments including the ones
below. Attached is an updated version of the document

 

Thanks

Lennart

 

From: Vu Minh Nguyen [mailto:vu.m.ngu...@dektech.com.au] 
Sent: den 2 mars 2017 08:41
To: Lennart Lund  >; Canh Van Truong
 >; 'A V
Mahesh'  >;
opensaf-devel@lists.sourceforge.net
 
Subject: RE: Review request log: Update LOG PR document with version 5.2
enhancements [#2200]

 

Hi Lennart,

 

Ack with few comments.

 

1) The "Contents" table has not been updated (not have chapter #4 in)

 

2) In table 14

VERSION: 1 (as it is currently specified in rfc5424)

-> Consider to change uppercase "rfc".

 

3) Correct the table 14 caption

"NFC 5424 protocol field usage" to "RFC 5424 protocol field usage"

 

Regards, Vu

 

> -Original Message-

> From: Lennart Lund [mailto:lennart.l...@ericsson.com]

> Sent: Wednesday, March 1, 2017 6:33 PM

> To: Vu Minh Nguyen  >; Canh Van Truong

>  >; A V
Mahesh (mahesh.va...@oracle.com  )

>  >;
opensaf-devel@lists.sourceforge.net
 

> Subject: Review request log: Update LOG PR document with version 5.2

> enhancements [#2200]

> 

> Update the document because of the following enhancements:

> #2146 log: implement SaLogFilterSetCallback

> #2258 log: add alternative destinations of log records

> 

> Document with recorded changes attached. Activate "Show Changes" to see

> them [Edit/Track Changes/Show Changes]

> 

> Thanks

> Lennart

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] amfnd: avoid null pointer access [#2213]

[Hans Nordebäck]

Ack, code review only/Thanks HansN

-Original Message-
From: nagendr...@oracle.com [mailto:nagendr...@oracle.com] 
Sent: den 7 mars 2017 07:31
To: Hans Nordebäck ; praveen.malv...@oracle.com; 
Minh Hon Chau ; Gary Lee 
Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 1 of 1] amfnd: avoid null pointer access [#2213]

 src/amf/amfnd/comp.cc |  4 
 1 files changed, 4 insertions(+), 0 deletions(-)


diff --git a/src/amf/amfnd/comp.cc b/src/amf/amfnd/comp.cc
--- a/src/amf/amfnd/comp.cc
+++ b/src/amf/amfnd/comp.cc
@@ -2650,6 +2650,10 @@ void avnd_comp_cmplete_all_csi_rec(AVND_
/* generate csi-remove-done event... csi may be 
deleted */
(void)avnd_comp_csi_remove_done(cb, comp, curr);
 
+   /* Avoid nullptr access. */
+   if (curr == nullptr)
+   break;
+
if (0 == m_AVND_COMPDB_REC_CSI_GET(*comp, 
curr->name.c_str())) {
curr =
(prv) ?

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

[devel] [PATCH 0 of 1] Review Request for amfnd: avoid null pointer access [#2213]

[nagendra . k]

Summary: amfnd: avoid null pointer access [#2213]
Review request for Trac Ticket(s): #2213
Peer Reviewer(s): Amf Dev
Pull request to: <>
Affected branch(es): All 
Development branch: Default


Impacted area   Impact y/n

 Docsn
 Build systemn
 RPM/packaging   n
 Configuration files n
 Startup scripts n
 SAF servicesy
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


Comments (indicate scope for each "y" above):
-
 <>

changeset 0a81abe9cd0056c937eba0f9edb14a42200ea792
Author: Nagendra Kumar
Date:   Tue, 07 Mar 2017 11:58:24 +0530

amfnd: avoid null pointer access [#2213]


Complete diffstat:
--
 src/amf/amfnd/comp.cc |  4 
 1 files changed, 4 insertions(+), 0 deletions(-)


Testing Commands:
-
Compiled.

Testing, Expected Results:
--
Compiled.

Conditions of Submission:
-
Ack

Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  y  y
powerpc n  n
powerpc64   n  n


Reviewer Checklist:
---
[Submitters: make sure that your review doesn't trigger any checkmarks!]


Your checkin has not passed review because (see checked entries):

___ Your RR template is generally incomplete; it has too many blank entries
that need proper data filled in.

___ You have failed to nominate the proper persons for review and push.

___ Your patches do not have proper short+long header

___ You have grammar/spelling in your header that is unacceptable.

___ You have exceeded a sensible line length in your headers/comments/text.

___ You have failed to put in a proper Trac Ticket # into your commits.

___ You have incorrectly put/left internal data in your comments/files
(i.e. internal bug tracking tool IDs, product names etc)

___ You have not given any evidence of testing beyond basic build tests.
Demonstrate some level of runtime or other sanity testing.

___ You have ^M present in some of your files. These have to be removed.

___ You have needlessly changed whitespace or added whitespace crimes
like trailing spaces, or spaces before tabs.

___ You have mixed real technical changes with whitespace and other
cosmetic code cleanup changes. These have to be separate commits.

___ You need to refactor your submission into logical chunks; there is
too much content into a single commit.

___ You have extraneous garbage in your review (merge commits etc)

___ You have giant attachments which should never have been sent;
Instead you should place your content in a public tree to be pulled.

___ You have too many commits attached to an e-mail; resend as threaded
commits, or place in a public tree for a pull.

___ You have resent this content multiple times without a clear indication
of what has changed between each re-send.

___ You have failed to adequately and individually address all of the
comments and change requests that were proposed in the initial review.

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

___ Your computer have a badly configured date and time; confusing the
the threaded patch review.

___ Your changes affect IPC mechanism, and you don't present any results
for in-service upgradability test.

___ Your changes affect user manual and documentation, your patch series
do not contain the patch that updates the Doxygen manual.


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

[devel] [PATCH 1 of 1] amfnd: avoid null pointer access [#2213]

[nagendra . k]

 src/amf/amfnd/comp.cc |  4 
 1 files changed, 4 insertions(+), 0 deletions(-)


diff --git a/src/amf/amfnd/comp.cc b/src/amf/amfnd/comp.cc
--- a/src/amf/amfnd/comp.cc
+++ b/src/amf/amfnd/comp.cc
@@ -2650,6 +2650,10 @@ void avnd_comp_cmplete_all_csi_rec(AVND_
/* generate csi-remove-done event... csi may be 
deleted */
(void)avnd_comp_csi_remove_done(cb, comp, curr);
 
+   /* Avoid nullptr access. */
+   if (curr == nullptr)
+   break;
+
if (0 == m_AVND_COMPDB_REC_CSI_GET(*comp, 
curr->name.c_str())) {
curr =
(prv) ?

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

[devel] [PATCH 1 of 1] nid: OpenSAF failed to start on controller randomly [#2346]

[Hans Nordeback]

 src/nid/nodeinit.cc |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/src/nid/nodeinit.cc b/src/nid/nodeinit.cc
--- a/src/nid/nodeinit.cc
+++ b/src/nid/nodeinit.cc
@@ -1436,7 +1436,7 @@ int handle_data_request(struct pollfd *f
 }
 fifo_fd = open(fifo_file.c_str(), O_WRONLY | O_NONBLOCK);
   } while ((fifo_fd == -1) &&
-   (retry_cnt++ < 5 && (errno == EINTR || errno == ENXIO)));
+   (retry_cnt++ < 50 && (errno == EINTR || errno == ENXIO)));
 
   if (fifo_fd == -1) {
 LOG_ER("Failed to open %s, error: %s", fifo_file.c_str(),

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

[devel] [PATCH 0 of 1] Review Request for nid: OpenSAF failed to start on controller randomly [#2346]

[Hans Nordeback]

Summary: nid: OpenSAF failed to start on controller randomly
Review request for Trac Ticket(s): #2346
Peer Reviewer(s): Ramesh, AndersW
Pull request to: 
Affected branch(es): default
Development branch: default


Impacted area   Impact y/n

 Docsn
 Build systemn
 RPM/packaging   n
 Configuration files n
 Startup scripts n
 SAF servicesn
 OpenSAF servicesn
 Core libraries  n
 Samples y
 Tests   n
 Other   n


Comments (indicate scope for each "y" above):
-
 <>

changeset 5d33c17b8fd755fda0e21abb63234b79f7be6e1b
Author: Hans Nordeback 
Date:   Tue, 07 Mar 2017 08:17:36 +0100

nid: OpenSAF failed to start on controller randomly [#2346]


Complete diffstat:
--
 src/nid/nodeinit.cc |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


Testing Commands:
-
 <>


Testing, Expected Results:
--
 <>


Conditions of Submission:
-
 <>


Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  n  n
powerpc n  n
powerpc64   n  n


Reviewer Checklist:
---
[Submitters: make sure that your review doesn't trigger any checkmarks!]


Your checkin has not passed review because (see checked entries):

___ Your RR template is generally incomplete; it has too many blank entries
that need proper data filled in.

___ You have failed to nominate the proper persons for review and push.

___ Your patches do not have proper short+long header

___ You have grammar/spelling in your header that is unacceptable.

___ You have exceeded a sensible line length in your headers/comments/text.

___ You have failed to put in a proper Trac Ticket # into your commits.

___ You have incorrectly put/left internal data in your comments/files
(i.e. internal bug tracking tool IDs, product names etc)

___ You have not given any evidence of testing beyond basic build tests.
Demonstrate some level of runtime or other sanity testing.

___ You have ^M present in some of your files. These have to be removed.

___ You have needlessly changed whitespace or added whitespace crimes
like trailing spaces, or spaces before tabs.

___ You have mixed real technical changes with whitespace and other
cosmetic code cleanup changes. These have to be separate commits.

___ You need to refactor your submission into logical chunks; there is
too much content into a single commit.

___ You have extraneous garbage in your review (merge commits etc)

___ You have giant attachments which should never have been sent;
Instead you should place your content in a public tree to be pulled.

___ You have too many commits attached to an e-mail; resend as threaded
commits, or place in a public tree for a pull.

___ You have resent this content multiple times without a clear indication
of what has changed between each re-send.

___ You have failed to adequately and individually address all of the
comments and change requests that were proposed in the initial review.

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

___ Your computer have a badly configured date and time; confusing the
the threaded patch review.

___ Your changes affect IPC mechanism, and you don't present any results
for in-service upgradability test.

___ Your changes affect user manual and documentation, your patch series
do not contain the patch that updates the Doxygen manual.


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] imm:changing clm indicating object to CLMS node up [#2330] V2

[Neelakanta Reddy]

Hi Zoran,

You are using older version of the patch, please use V2(the problem has 
been resolved).

The following is the syslog message, when same test is performed:

Apr  3 16:15:19 PL4 osafimmnd[17434]: NO Re-introduce-me 
highestProcessed:1109 highestReceived:1109
Apr  3 16:15:19 PL4 osafimmnd[17434]: WA MDS Send Failed to service:IMMD 
rc:2
Apr  3 16:15:20 PL4 osafimmnd[17434]: NO Re-introduce-me 
highestProcessed:1109 highestReceived:1109
Apr  3 16:15:20 PL4 osafimmnd[17434]: WA MDS Send Failed to service:IMMD 
rc:2
Apr  3 16:15:21 PL4 osafimmnd[17434]: NO IMMD service is UP ... 
ScAbsenseAllowed?:900 introduced?:2
Apr  3 16:15:21 PL4 osafimmnd[17434]: NO Re-introduce-me 
highestProcessed:1109 highestReceived:1109
Apr  3 16:15:21 PL4 osafimmnd[17434]: NO This IMMND is now the NEW Coord
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO Announce sync, epoch:3
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO SERVER STATE: IMM_SERVER_READY 
--> IMM_SERVER_SYNC_SERVER
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO NODE STATE-> IMM_NODE_R_AVAILABLE
Apr  3 16:15:22 PL4 osafimmloadd: NO Sync starting
Apr  3 16:15:22 PL4 osafimmloadd: IN Synced 382 objects in total
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO NODE STATE-> 
IMM_NODE_FULLY_AVAILABLE 18511
Apr  3 16:15:22 PL4 osafimmloadd: NO Sync ending normally
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO Epoch set to 3 in ImmModel
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO Implementer connected: 14 
(MsgQueueService132111) <51, 2040f>
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO Implementer connected: 15 
(safLogService) <0, 2010f>
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO Implementer (applier) 
connected: 16 (@safLogService_appl) <0, 2010f>
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO SERVER STATE: 
IMM_SERVER_SYNC_SERVER --> IMM_SERVER_READY
Apr  3 16:15:22 PL4 osafmsgnd[17466]: ER saClmDispatch Failed with error 9
Apr  3 16:15:22 PL4 osafckptnd[17495]: NO Bad CLM handle. Reinitializing.
Apr  3 16:15:22 PL4 osafclmna[17424]: NO 
safNode=PL-4,safCluster=myClmCluster Joined cluster, nodeid=2040f
Apr  3 16:15:22 PL4 osafamfnd[17444]: NO AVD NEW_ACTIVE, adest:1
Apr  3 16:15:22 PL4 osafimmnd[17434]: ER saClmDispatch failed: 9
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO Re-initializing with CLMS
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO Implementer connected: 17 
(safClmService) <0, 2010f>
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO Implementer connected: 18 
(safAmfService) <0, 2010f>
Apr  3 16:15:22 PL4 osafamfnd[17444]: NO saClmDispatch BAD_HANDLE
Apr  3 16:15:22 PL4 osafamfnd[17444]: NO 1 SISU states sent
Apr  3 16:15:22 PL4 osafamfnd[17444]: NO 1 SU states sent
Apr  3 16:15:22 PL4 osafamfnd[17444]: NO 7 CSICOMP states sent
Apr  3 16:15:22 PL4 osafamfnd[17444]: NO 7 COMP states sent
Apr  3 16:15:22 PL4 osafamfnd[17444]: NO Sending node up due to 
NCSMDS_NEW_ACTIVE
Apr  3 16:15:24 PL4 osafckptnd[17495]: NO CLM selection object was 
updated. (15)
Apr  3 16:15:34 PL4 osafimmnd[17434]: NO Implementer connected: 19 
(MsgQueueService131343) <0, 2010f>
Apr  3 16:15:34 PL4 osafimmnd[17434]: NO Implementer connected: 20 
(safMsgGrpService) <0, 2010f>
Apr  3 16:15:34 PL4 osafimmnd[17434]: NO Implementer connected: 21 
(safEvtService) <0, 2010f>
Apr  3 16:15:34 PL4 osafimmnd[17434]: NO Implementer connected: 22 
(safLckService) <0, 2010f>
Apr  3 16:15:34 PL4 osafimmnd[17434]: NO Implementer connected: 23 
(safSmfService) <0, 2010f>
Apr  3 16:15:34 PL4 osafimmnd[17434]: NO Implementer (applier) 
connected: 24 (@safSmf_applier1) <0, 2010f

Thanks,
Neel.

On 2017/03/06 08:17 PM, Zoran Milinkovic wrote:
> Hi Neelakanta,
>
> After applying the patch, immnd on payloads crashing after coming from 
> headless state.
> Before the patch, immnd was more stable.
>
> This is a test with one SC and one PL with SC absence allowed.
> 1. Bring both SC-1 and PL-3 up
> 2. Take SC-1 down to go to headless state
> 3. Take SC-1 up, and after the sync, PL-3 reboots
>
> These are logs from PL-3 when the sync was announced:
>
> Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO Announce sync, epoch:45
> Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO SERVER STATE: IMM_SERVER_READY --> 
> IMM_SERVER_SYNC_SERVER
> Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO NODE STATE-> IMM_NODE_R_AVAILABLE
> Mar  6 15:37:08 PL-3 osafimmloadd: NO Sync starting
> Mar  6 15:37:08 PL-3 osafimmloadd: IN Synced 382 objects in total
> Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO NODE STATE-> 
> IMM_NODE_FULLY_AVAILABLE 18511
> Mar  6 15:37:08 PL-3 osafimmloadd: NO Sync ending normally
> Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO Epoch set to 45 in ImmModel
> Mar  6 15:37:08 PL-3 osafimmpbed: NO Update epoch 45 committing with 
> ccbId:1000d/4294967309
> Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO Implementer connected: 37 
> (MsgQueueService131855) <53, 2030f>
> Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO Implementer connected: 38 
> (safLogService) <0, 2010f>
> Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO Implementer (applier) connected: 39 
> (@safLogService_appl) <0, 2010f>
> Mar  6 15:37:08 

Re: [devel] [PATCH 1 of 1] mds: reduce log level to Err for TIPC_ERR_OVERLOAD in syslog [#2350]

[Hans Nordebäck]

Ack, code review only/Thanks HansN

-Original Message-
From: mahesh.va...@oracle.com [mailto:mahesh.va...@oracle.com] 
Sent: den 7 mars 2017 03:39
To: Hans Nordebäck 
Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 1 of 1] mds: reduce log level to Err for TIPC_ERR_OVERLOAD in 
syslog [#2350]

 src/mds/mds_dt_tipc.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


Note : MDS still maintained as MDS_LOG_CRITICAL

diff --git a/src/mds/mds_dt_tipc.c b/src/mds/mds_dt_tipc.c
--- a/src/mds/mds_dt_tipc.c
+++ b/src/mds/mds_dt_tipc.c
@@ -590,7 +590,7 @@ ssize_t recvfrom_connectionless (int sd,
if (anc->cmsg_type == TIPC_ERRINFO) {
anc_data[0] = *((unsigned 
int*)(CMSG_DATA(anc) + 0));
if (anc_data[0] == TIPC_ERR_OVERLOAD) {
-   LOG_CR("MDTM: undelivered 
message condition ancillary data: TIPC_ERR_OVERLOAD");
+   LOG_ER("MDTM: undelivered 
message condition ancillary data: 
+TIPC_ERR_OVERLOAD");
m_MDS_LOG_CRITICAL("MDTM: 
undelivered message condition ancillary data: TIPC_ERR_OVERLOAD");
} else {
/* TIPC_ERRINFO - TIPC error 
code associated with a returned data message or a connection termination 
message */ @@ -600,7 +600,7 @@ ssize_t recvfrom_connectionless (int sd,
/* If we set TIPC_DEST_DROPPABLE off 
message (configure TIPC to return rejected messages to the sender )
   we will hit this when we implement 
MDS retransmit lost messages, can be replaced with flow control logic */
/* TIPC_RETDATA -The contents of a 
returned data message */
-   LOG_CR("MDTM: undelivered message 
condition ancillary data: TIPC_RETDATA");
+   LOG_ER("MDTM: undelivered message 
condition ancillary data: 
+TIPC_RETDATA");
m_MDS_LOG_CRITICAL("MDTM: undelivered 
message condition ancillary data: TIPC_RETDATA");
} else if (anc->cmsg_type == TIPC_DESTNAME) {
if (sz == 0) {

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] AMFND: Ensure su operational message synchronizes with component failover sequence [#2233]

[praveen malviya]

Hi Minh,

Is there any harm if both the patches are merged? One patch adds strict 
checks for message ordering in case of comp-failover recovery of 
assigned or non-assigned component. Another patch ensures that if an 
assigned or non-assigned comp faults with comp-faiover recovery then 
first AMF will switchover whole SU (current implementation irrespective 
of red models) and after completion of switchover re-instantiation of 
failed comp will be attempted.
Also, I think, from headless perspective, the strict check of patch V1 
is important when comp-failover occurs in the absence of SCs.
So I have a minor query here: Is there any impact of late instantiation 
of comp when comp-failover occurs in SCs Absence?


Also I think now an enhancement ticket should be raised for 
implementation of comp-failover recovery as per spec for N-Way and N-Way 
active model.


Thanks,
Praveen



On 07-Mar-17 4:10 AM, minh chau wrote:
> Hi Praveen,
>
> Please see comments with [Minh5]
>
> Thanks,
> Minh
>
> On 06/03/17 17:52, praveen malviya wrote:
>> Hi Minh,
>>
>> Please see inline with [Praveen].
>>
>> Thanks,
>> Praveen
>>
>> On 03-Mar-17 5:39 PM, minh chau wrote:
>>> Hi Praveen,
>>>
>>> I have two comments with [Minh4].
>>>
>>> Thanks
>>> Minh
>>>
>>> On 02/03/17 20:49, praveen malviya wrote:
 Hi Minh,
 Please see response with [Praveen].

 Thanks,
 Praveen



 On 02-Mar-17 1:43 PM, minh chau wrote:
> Hi,
>
> Thanks Gary.
> @Nagu, Praveen: Have you had time to check the example in my previous
> email?
> The ticket #2179 is about to document that full escalation is
> supported
> for SC absence feature, it is waiting for fix of #2233.
> I think there's not big change in code for #2233, it's a matter of
> decision to make for re-instantiation of failed component.
>
> Thanks,
> Minh
>
> On 01/03/17 15:42, Gary Lee wrote:
>> Hi
>>
>> It seems the component should be re-instantiated if it has no CSI.
>> Whether or not there is an SI assigned should be irrelevant?
>>
>> Thanks
>> Gary
>>
>> -Original Message-
>> From: minh chau 
>> Date: Thursday, 23 February 2017 at 3:16 pm
>> To: Nagendra Kumar , Praveen Malviya
>> 
>> Cc: , gary ,
>> ,
>> 
>> Subject: Re: [devel] [PATCH 1 of 1] AMFND: Ensure su operational
>> message synchronizes with component failover sequence [#2233]
>>
>>  Hi Nagu, Praveen,
>>   Please find my comment in [Minh3]
>>   Thanks,
>>  Minh
>>   On 22/02/17 19:34, Nagendra Kumar wrote:
>>  >>> Since in spec there is no specific discussion for
>> comp-failover recovery for an unassigned comp, I will encourage other
>> maintainers also to provide inputs.
>>  > I do agree for not instantiating failed component before
>> recovery, this keeps the approach similar to SU failover also.
>>  [Minh3]: There's one example of component failover that I would
>> like us
>>  to have a look
>>  - 2N application, SU4/SU5 has active/standby assignment
>> respectively,
>>  each SU has 3 components
>>  - Add a sleep of 10 seconds in clc script start command of first
>>  component C41 of SU4
>>  Steps:
>>  1- Kill C41 to trigger component failover
>>  2- SU4 goes for quiesced assignment
>>  3- SU5 goes for active assignment
>>  4- SU4 is removed its assignment
>>  5- Now there's a pause of 10 seconds due to clc script start, to
>> ensure
>>  that C41 is healthy
>>  6- Next SU4 has standby assignment.
>>From the above example, I think we can see some
>> problems if
>> the
>>  re-instantiation of C41 is delayed:
>>  - Because C41 is faulty, it needs to be restarted ok because its
>> SU has
>>  assignment
>>  - Moving re-instantiation of C41 is further down that means the
>> recovery
>>  will take longer
>>  - What if re-instantiation of C41 leads to instantation-failed
 [Praveen] If AMFND re-instantiate C41 after removal of assignment and
 it moves to instantiation-failed then:
 -Node will be rebooted if nodefailfastonterminationfaioure=true.
 -ifnodefailfastonterminationfaioure=false then as per section 4.6 page
 212, SU will be marked INST_FAILED and AMF will have to terminate all
 the components. Termination of other components will be easier if they
 do not have assignments or pending assignments.

 If C41 is instantiated before removal of assignments and it moves to
 INST_FAILED state, then AMFND will be terminating other comps of SU

Re: [devel] [PATCH 1 of 1] log: fix leak memory in socket destination handler [#2344]

[A V Mahesh]

Hi Vu,

ACK

-AVM


On 3/6/2017 5:41 PM, Vu Minh Nguyen wrote:
>   src/log/logd/lgs_dest.cc |  4 
>   1 files changed, 4 insertions(+), 0 deletions(-)
>
>
> DestinationHandler::UpdateRtDestStatus() uses lgs_cfgupd_mutival_replace()
> to update logRecordDestinationStatus but not freeing buffer
> at the end of the function.
>
> This fix does freeing that buffer.
>
> diff --git a/src/log/logd/lgs_dest.cc b/src/log/logd/lgs_dest.cc
> --- a/src/log/logd/lgs_dest.cc
> +++ b/src/log/logd/lgs_dest.cc
> @@ -184,6 +184,10 @@ void DestinationHandler::UpdateRtDestSta
> if (ret == -1) {
>   LOG_WA("%s lgs_cfg_update Fail", __func__);
> }
> +
> +  // Free memory allocated for the config_data buffer
> +  if (config_data.ckpt_buffer_ptr != nullptr)
> +free(config_data.ckpt_buffer_ptr);
>   }
>   
>   void DestinationHandler::FormCfgDestMsg(


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] log: Fix all Cppcheck 1.77 issues [#2326] V1

[A V Mahesh]

Hi Vu,

pushed.

changeset:   8650:b1794d3c341d
tag: tip
user:Hoang Vo 
date:Tue Mar 07 09:57:48 2017 +0530
summary: mdstest: correct test cases [#2178]


-AVM


On 3/7/2017 10:01 AM, Vu Minh Nguyen wrote:
> Hi Mahesh,
>
> Ok. I have no comment with your fix for cppcheck 1.77's report.
>
> Regards, Vu
>
>> -Original Message-
>> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
>> Sent: Tuesday, March 7, 2017 5:11 AM
>> To: Vu Minh Nguyen ;
>> canh.v.tru...@dektech.com.au; lennart.l...@ericsson.com
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: Re: [PATCH 1 of 1] log: Fix all Cppcheck 1.77 issues [#2326] V1
>>
>>Hi Vu,
>>
>>I did check, LOG code still using lgs_cb as structure not as a class,
>> may that conversion we can address in a separate new #ticket,
>>and fixing that issue in Cppcheck 1.77 errors doesn't look appropriate
>> even.
>>
>>If you don't have any other comments specific  to  Cppcheck 1.77
>> errors, as if i have already recive ACK for Lennart  and  Canh
>>I would lie to push .
>>
>> -AVM
>>
>> On 3/6/2017 8:48 AM, A V Mahesh wrote:
>>> Hi Vu,
>>>
>>> Ok I will check & match with other DB definitions .
>>>
>>> -AVM
>>>
>>>
>>> On 3/3/2017 12:49 PM, Vu Minh Nguyen wrote:
 Hi Mahesh,

 In #1984 ticket, I had comments on clientMap data type, have you looked
 them?:

> +extern void *client_db;   /* used for C++ STL map */
 [Vu] Any reason not using ClientMap* client_db?

> +  /* Loop through Client DB */
> +  ClientMap *clientMap(reinterpret_cast(client_db));
 [Vu] Any reason why not using "ClientMap* client_db" to avoid typecast?

 Regards, Vu

> -Original Message-
> From: mahesh.va...@oracle.com [mailto:mahesh.va...@oracle.com]
> Sent: Thursday, March 2, 2017 11:16 AM
> To: canh.v.tru...@dektech.com.au; lennart.l...@ericsson.com;
> vu.m.ngu...@dektech.com.au
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] log: Fix all Cppcheck 1.77 issues [#2326] V1
>
>src/log/agent/lga_api.c  |   3 +--
>src/log/agent/lga_mds.c  |   6 ++
>src/log/agent/lga_state.c|   3 +--
>src/log/agent/lga_util.c |   4 +---
>src/log/logd/lgs_clm.cc  |   8 +++-
>src/log/logd/lgs_config.cc   |  36
> +---
>src/log/logd/lgs_config.h|  10 +-
>src/log/logd/lgs_evt.cc  |  17 +++--
>src/log/logd/lgs_filehdl.cc  |   4 
>src/log/logd/lgs_fmt.cc  |   3 +--
>src/log/logd/lgs_imm.cc  |  25 -
>src/log/logd/lgs_imm_gcfg.cc |  21 +++--
>src/log/logd/lgs_main.cc |   2 +-
>src/log/logd/lgs_mbcsv.cc|  21 -
>src/log/logd/lgs_mds.cc  |   3 +--
>src/log/logd/lgs_stream.cc   |   6 ++
>src/log/logd/lgs_util.cc |  10 --
>17 files changed, 73 insertions(+), 109 deletions(-)
>
>
> V1 is on 5.2 GA tag
> Except never used functions all other issues are fixed  of below,
> some UN-pushed enhancement may be using those functions.
>
>
>> ==
> 
> [staging/src/log/logd/lgs_config.h:90]: (performance) Function
> parameter
> param_name should be passed by reference.
> [staging/src/log/logd/lgs_config.h:230]: (performance) Function
> parameter
> attribute_name should be passed by reference.
> [staging/src/log/logd/lgs_config.h:231]: (performance) Function
> parameter
> value_list should be passed by reference.
> [staging/src/log/logd/lgs_config.h:238]: (performance) Function
> parameter
> attribute_name should be passed by reference.
> [staging/src/log/logd/lgs_config.h:239]: (performance) Function
> parameter
> value_list should be passed by reference.
> [staging/src/log/logd/lgs_clm.cc:137]: (style) The scope of the
> variable
> clm_node can be reduced.
> [staging/src/log/logd/lgs_clm.cc:220]: (performance) Prefer prefix
> ++/--
> operators for non-primitive types.
> [staging/src/log/logd/lgs_config.cc:401] ->
> [staging/src/log/logd/lgs_config.cc:498]: (warning) Either the
> condition
> allocmem_ptr!=NULL is redundant or there is possible null pointer
> dereference: param_ptr.
> [staging/src/log/logd/lgs_config.cc:410] ->
> [staging/src/log/logd/lgs_config.cc:498]: (warning) Either the
> condition
> allocmem_ptr!=NULL is redundant or there is possible null pointer
> dereference: param_ptr.
> [staging/src/log/logd/lgs_config.cc:184] ->
> [staging/src/log/logd/lgs_config.cc:190]: (style) Variable
> cfg_param_str
 is
> reassigned a value 

Re: [devel] [PATCH 1 of 1] log: Fix all Cppcheck 1.77 issues [#2326] V1

[Vu Minh Nguyen]

Hi Mahesh,

Ok. I have no comment with your fix for cppcheck 1.77's report.

Regards, Vu

> -Original Message-
> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
> Sent: Tuesday, March 7, 2017 5:11 AM
> To: Vu Minh Nguyen ;
> canh.v.tru...@dektech.com.au; lennart.l...@ericsson.com
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: Re: [PATCH 1 of 1] log: Fix all Cppcheck 1.77 issues [#2326] V1
> 
>   Hi Vu,
> 
>   I did check, LOG code still using lgs_cb as structure not as a class,
> may that conversion we can address in a separate new #ticket,
>   and fixing that issue in Cppcheck 1.77 errors doesn't look appropriate
> even.
> 
>   If you don't have any other comments specific  to  Cppcheck 1.77
> errors, as if i have already recive ACK for Lennart  and  Canh
>   I would lie to push .
> 
> -AVM
> 
> On 3/6/2017 8:48 AM, A V Mahesh wrote:
> > Hi Vu,
> >
> > Ok I will check & match with other DB definitions .
> >
> > -AVM
> >
> >
> > On 3/3/2017 12:49 PM, Vu Minh Nguyen wrote:
> >> Hi Mahesh,
> >>
> >> In #1984 ticket, I had comments on clientMap data type, have you looked
> >> them?:
> >>
> >>> +extern void *client_db;   /* used for C++ STL map */
> >> [Vu] Any reason not using ClientMap* client_db?
> >>
> >>> +  /* Loop through Client DB */
> >>> +  ClientMap *clientMap(reinterpret_cast(client_db));
> >> [Vu] Any reason why not using "ClientMap* client_db" to avoid typecast?
> >>
> >> Regards, Vu
> >>
> >>> -Original Message-
> >>> From: mahesh.va...@oracle.com [mailto:mahesh.va...@oracle.com]
> >>> Sent: Thursday, March 2, 2017 11:16 AM
> >>> To: canh.v.tru...@dektech.com.au; lennart.l...@ericsson.com;
> >>> vu.m.ngu...@dektech.com.au
> >>> Cc: opensaf-devel@lists.sourceforge.net
> >>> Subject: [PATCH 1 of 1] log: Fix all Cppcheck 1.77 issues [#2326] V1
> >>>
> >>>   src/log/agent/lga_api.c  |   3 +--
> >>>   src/log/agent/lga_mds.c  |   6 ++
> >>>   src/log/agent/lga_state.c|   3 +--
> >>>   src/log/agent/lga_util.c |   4 +---
> >>>   src/log/logd/lgs_clm.cc  |   8 +++-
> >>>   src/log/logd/lgs_config.cc   |  36
> >>> +---
> >>>   src/log/logd/lgs_config.h|  10 +-
> >>>   src/log/logd/lgs_evt.cc  |  17 +++--
> >>>   src/log/logd/lgs_filehdl.cc  |   4 
> >>>   src/log/logd/lgs_fmt.cc  |   3 +--
> >>>   src/log/logd/lgs_imm.cc  |  25 -
> >>>   src/log/logd/lgs_imm_gcfg.cc |  21 +++--
> >>>   src/log/logd/lgs_main.cc |   2 +-
> >>>   src/log/logd/lgs_mbcsv.cc|  21 -
> >>>   src/log/logd/lgs_mds.cc  |   3 +--
> >>>   src/log/logd/lgs_stream.cc   |   6 ++
> >>>   src/log/logd/lgs_util.cc |  10 --
> >>>   17 files changed, 73 insertions(+), 109 deletions(-)
> >>>
> >>>
> >>> V1 is on 5.2 GA tag
> >>> Except never used functions all other issues are fixed  of below,
> >>> some UN-pushed enhancement may be using those functions.
> >>>
> >>>
> ==
> >>> 
> >>> [staging/src/log/logd/lgs_config.h:90]: (performance) Function
> >>> parameter
> >>> param_name should be passed by reference.
> >>> [staging/src/log/logd/lgs_config.h:230]: (performance) Function
> >>> parameter
> >>> attribute_name should be passed by reference.
> >>> [staging/src/log/logd/lgs_config.h:231]: (performance) Function
> >>> parameter
> >>> value_list should be passed by reference.
> >>> [staging/src/log/logd/lgs_config.h:238]: (performance) Function
> >>> parameter
> >>> attribute_name should be passed by reference.
> >>> [staging/src/log/logd/lgs_config.h:239]: (performance) Function
> >>> parameter
> >>> value_list should be passed by reference.
> >>> [staging/src/log/logd/lgs_clm.cc:137]: (style) The scope of the
> >>> variable
> >>> clm_node can be reduced.
> >>> [staging/src/log/logd/lgs_clm.cc:220]: (performance) Prefer prefix
> >>> ++/--
> >>> operators for non-primitive types.
> >>> [staging/src/log/logd/lgs_config.cc:401] ->
> >>> [staging/src/log/logd/lgs_config.cc:498]: (warning) Either the
> >>> condition
> >>> allocmem_ptr!=NULL is redundant or there is possible null pointer
> >>> dereference: param_ptr.
> >>> [staging/src/log/logd/lgs_config.cc:410] ->
> >>> [staging/src/log/logd/lgs_config.cc:498]: (warning) Either the
> >>> condition
> >>> allocmem_ptr!=NULL is redundant or there is possible null pointer
> >>> dereference: param_ptr.
> >>> [staging/src/log/logd/lgs_config.cc:184] ->
> >>> [staging/src/log/logd/lgs_config.cc:190]: (style) Variable
> >>> cfg_param_str
> >> is
> >>> reassigned a value before the old one has been used.
> >>> [staging/src/log/logd/lgs_config.cc:183]: (style) The scope of the
> >> variable
> >>> prev_size can be reduced.
> >>> [staging/src/log/logd/lgs_config.cc:727]: (style) The scope of the
> >> variable
> >>> nl_cnt can be reduced.
> >>> 

Re: [devel] [PATCH 1 of 1] amfnd: update counters during switchover [#2345]

[Gary Lee]

Hi Nagu

Ack (reviewed + legacy tests passed)

Thanks
Gary

On 6/3/17, 6:47 pm, "nagendr...@oracle.com"  wrote:

 src/amf/amfnd/di.cc |  13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)


In some cases, Amfnd is getting role change event
before AVD up message, which is rare.
In avnd_evt_avd_role_change_evh, if AVD flag is
not marked up, then it is not updating the counters and
returning from there. This creates a mismatch into counters of messages
exchanged among amfd and amfnd. This leads to Amfnd reboots the node.
Since, avnd_evt_avd_role_change_evh is not a significant message for
Amfnd, so we can update the messages counters first and return from there.

diff --git a/src/amf/amfnd/di.cc b/src/amf/amfnd/di.cc
--- a/src/amf/amfnd/di.cc
+++ b/src/amf/amfnd/di.cc
@@ -1510,12 +1510,7 @@ uint32_t avnd_evt_avd_role_change_evh(AV
 
TRACE_ENTER();
 
-   /* dont process unless AvD is up */
-   if (!m_AVND_CB_IS_AVD_UP(cb)){
-   LOG_IN("AVD is not up yet");
-   return NCSCC_RC_FAILURE;
-   }
-
+   /* Correct the counters first. */
info = >info.avd->msg_info.d2n_role_change_info;
 
TRACE("MsgId: %u,NodeId:%u, role rcvd:%u role present:%u",\
@@ -1524,6 +1519,12 @@ uint32_t avnd_evt_avd_role_change_evh(AV
avnd_msgid_assert(info->msg_id);
cb->rcv_msg_id = info->msg_id;
 
+   /* dont process unless AvD is up */
+   if (!m_AVND_CB_IS_AVD_UP(cb)){
+   LOG_IN("AVD is not up yet");
+   return NCSCC_RC_FAILURE;
+   }
+
prev_ha_state = cb->avail_state_avnd;
 
/* Ignore the duplicate roles. */




--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] log: Fix all Cppcheck 1.77 issues [#2326] V1

[A V Mahesh]

  Hi Vu,

  I did check, LOG code still using lgs_cb as structure not as a class, 
may that conversion we can address in a separate new #ticket,
  and fixing that issue in Cppcheck 1.77 errors doesn't look appropriate 
even.

  If you don't have any other comments specific  to  Cppcheck 1.77 
errors, as if i have already recive ACK for Lennart  and  Canh
  I would lie to push .

-AVM

On 3/6/2017 8:48 AM, A V Mahesh wrote:
> Hi Vu,
>
> Ok I will check & match with other DB definitions .
>
> -AVM
>
>
> On 3/3/2017 12:49 PM, Vu Minh Nguyen wrote:
>> Hi Mahesh,
>>
>> In #1984 ticket, I had comments on clientMap data type, have you looked
>> them?:
>>
>>> +extern void *client_db;   /* used for C++ STL map */
>> [Vu] Any reason not using ClientMap* client_db?
>>
>>> +  /* Loop through Client DB */
>>> +  ClientMap *clientMap(reinterpret_cast(client_db));
>> [Vu] Any reason why not using "ClientMap* client_db" to avoid typecast?
>>
>> Regards, Vu
>>
>>> -Original Message-
>>> From: mahesh.va...@oracle.com [mailto:mahesh.va...@oracle.com]
>>> Sent: Thursday, March 2, 2017 11:16 AM
>>> To: canh.v.tru...@dektech.com.au; lennart.l...@ericsson.com;
>>> vu.m.ngu...@dektech.com.au
>>> Cc: opensaf-devel@lists.sourceforge.net
>>> Subject: [PATCH 1 of 1] log: Fix all Cppcheck 1.77 issues [#2326] V1
>>>
>>>   src/log/agent/lga_api.c  |   3 +--
>>>   src/log/agent/lga_mds.c  |   6 ++
>>>   src/log/agent/lga_state.c|   3 +--
>>>   src/log/agent/lga_util.c |   4 +---
>>>   src/log/logd/lgs_clm.cc  |   8 +++-
>>>   src/log/logd/lgs_config.cc   |  36 
>>> +---
>>>   src/log/logd/lgs_config.h|  10 +-
>>>   src/log/logd/lgs_evt.cc  |  17 +++--
>>>   src/log/logd/lgs_filehdl.cc  |   4 
>>>   src/log/logd/lgs_fmt.cc  |   3 +--
>>>   src/log/logd/lgs_imm.cc  |  25 -
>>>   src/log/logd/lgs_imm_gcfg.cc |  21 +++--
>>>   src/log/logd/lgs_main.cc |   2 +-
>>>   src/log/logd/lgs_mbcsv.cc|  21 -
>>>   src/log/logd/lgs_mds.cc  |   3 +--
>>>   src/log/logd/lgs_stream.cc   |   6 ++
>>>   src/log/logd/lgs_util.cc |  10 --
>>>   17 files changed, 73 insertions(+), 109 deletions(-)
>>>
>>>
>>> V1 is on 5.2 GA tag
>>> Except never used functions all other issues are fixed  of below,
>>> some UN-pushed enhancement may be using those functions.
>>>
>>> ==
>>> 
>>> [staging/src/log/logd/lgs_config.h:90]: (performance) Function 
>>> parameter
>>> param_name should be passed by reference.
>>> [staging/src/log/logd/lgs_config.h:230]: (performance) Function 
>>> parameter
>>> attribute_name should be passed by reference.
>>> [staging/src/log/logd/lgs_config.h:231]: (performance) Function 
>>> parameter
>>> value_list should be passed by reference.
>>> [staging/src/log/logd/lgs_config.h:238]: (performance) Function 
>>> parameter
>>> attribute_name should be passed by reference.
>>> [staging/src/log/logd/lgs_config.h:239]: (performance) Function 
>>> parameter
>>> value_list should be passed by reference.
>>> [staging/src/log/logd/lgs_clm.cc:137]: (style) The scope of the 
>>> variable
>>> clm_node can be reduced.
>>> [staging/src/log/logd/lgs_clm.cc:220]: (performance) Prefer prefix 
>>> ++/--
>>> operators for non-primitive types.
>>> [staging/src/log/logd/lgs_config.cc:401] ->
>>> [staging/src/log/logd/lgs_config.cc:498]: (warning) Either the 
>>> condition
>>> allocmem_ptr!=NULL is redundant or there is possible null pointer
>>> dereference: param_ptr.
>>> [staging/src/log/logd/lgs_config.cc:410] ->
>>> [staging/src/log/logd/lgs_config.cc:498]: (warning) Either the 
>>> condition
>>> allocmem_ptr!=NULL is redundant or there is possible null pointer
>>> dereference: param_ptr.
>>> [staging/src/log/logd/lgs_config.cc:184] ->
>>> [staging/src/log/logd/lgs_config.cc:190]: (style) Variable 
>>> cfg_param_str
>> is
>>> reassigned a value before the old one has been used.
>>> [staging/src/log/logd/lgs_config.cc:183]: (style) The scope of the
>> variable
>>> prev_size can be reduced.
>>> [staging/src/log/logd/lgs_config.cc:727]: (style) The scope of the
>> variable
>>> nl_cnt can be reduced.
>>> [staging/src/log/logd/lgs_config.cc:995]: (style) The scope of the
>> variable
>>> value_string can be reduced.
>>> [staging/src/log/logd/lgs_config.cc:1034]: (style) The scope of the
>> variable n
>>> can be reduced.
>>> [staging/src/log/logd/lgs_config.cc:142]: (warning) Member variable
>>> _lgs_conf_t::chkp_file_close_time is not initialized in the 
>>> constructor.
>>> [staging/src/log/logd/lgs_config.cc:293]: (performance) Function 
>>> parameter
>>> attribute_name should be passed by reference.
>>> [staging/src/log/logd/lgs_config.cc:294]: (performance) Function 
>>> parameter
>>> value_list should be passed by reference.
>>> [staging/src/log/logd/lgs_config.cc:324]: (performance) 

[devel] [PATCH 1 of 1] mds: reduce log level to Err for TIPC_ERR_OVERLOAD in syslog [#2350]

[mahesh . valla]

 src/mds/mds_dt_tipc.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


Note : MDS still maintained as MDS_LOG_CRITICAL

diff --git a/src/mds/mds_dt_tipc.c b/src/mds/mds_dt_tipc.c
--- a/src/mds/mds_dt_tipc.c
+++ b/src/mds/mds_dt_tipc.c
@@ -590,7 +590,7 @@ ssize_t recvfrom_connectionless (int sd,
if (anc->cmsg_type == TIPC_ERRINFO) {
anc_data[0] = *((unsigned 
int*)(CMSG_DATA(anc) + 0));
if (anc_data[0] == TIPC_ERR_OVERLOAD) {
-   LOG_CR("MDTM: undelivered 
message condition ancillary data: TIPC_ERR_OVERLOAD");
+   LOG_ER("MDTM: undelivered 
message condition ancillary data: TIPC_ERR_OVERLOAD");
m_MDS_LOG_CRITICAL("MDTM: 
undelivered message condition ancillary data: TIPC_ERR_OVERLOAD");
} else {
/* TIPC_ERRINFO - TIPC error 
code associated with a returned data message or a connection termination 
message */
@@ -600,7 +600,7 @@ ssize_t recvfrom_connectionless (int sd,
/* If we set TIPC_DEST_DROPPABLE off 
message (configure TIPC to return rejected messages to the sender )
   we will hit this when we implement 
MDS retransmit lost messages, can be replaced with flow control logic */
/* TIPC_RETDATA -The contents of a 
returned data message */
-   LOG_CR("MDTM: undelivered message 
condition ancillary data: TIPC_RETDATA");
+   LOG_ER("MDTM: undelivered message 
condition ancillary data: TIPC_RETDATA");
m_MDS_LOG_CRITICAL("MDTM: undelivered 
message condition ancillary data: TIPC_RETDATA");
} else if (anc->cmsg_type == TIPC_DESTNAME) {
if (sz == 0) {

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

[devel] [PATCH 0 of 1] Review Request for mds: reduce log level to Err for TIPC_ERR_OVERLOAD in syslog [#2350]

[mahesh . valla]

Summary:mds: reduce log level to Err for TIPC_ERR_OVERLOAD in syslog [#2350] 
Review request for Trac Ticket(s): #2350
Peer Reviewer(s):  Hans N
Pull request to: <>
Affected branch(es): default , 5.2, 5.1
Development branch: default


Impacted area   Impact y/n

 Docsn
 Build systemn
 RPM/packaging   n
 Configuration files n
 Startup scripts n
 SAF servicesn
 OpenSAF servicesn
 Core libraries  y
 Samples n
 Tests   n
 Other   n


Comments (indicate scope for each "y" above):
-

changeset 694b1910f8b9337cdecdded8e0908766811458c6
Author: A V Mahesh 
Date:   Tue, 07 Mar 2017 08:04:51 +0530

mds: reduce log level to Err for TIPC_ERR_OVERLOAD in syslog [#2350] 
Note :
MDS still maintained as MDS_LOG_CRITICAL


Complete diffstat:
--
 src/mds/mds_dt_tipc.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


Testing Commands:
-
 <>


Testing, Expected Results:
--
 <>


Conditions of Submission:
-
 <>


Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  y  n
powerpc n  n
powerpc64   n  n


Reviewer Checklist:
---
[Submitters: make sure that your review doesn't trigger any checkmarks!]


Your checkin has not passed review because (see checked entries):

___ Your RR template is generally incomplete; it has too many blank entries
that need proper data filled in.

___ You have failed to nominate the proper persons for review and push.

___ Your patches do not have proper short+long header

___ You have grammar/spelling in your header that is unacceptable.

___ You have exceeded a sensible line length in your headers/comments/text.

___ You have failed to put in a proper Trac Ticket # into your commits.

___ You have incorrectly put/left internal data in your comments/files
(i.e. internal bug tracking tool IDs, product names etc)

___ You have not given any evidence of testing beyond basic build tests.
Demonstrate some level of runtime or other sanity testing.

___ You have ^M present in some of your files. These have to be removed.

___ You have needlessly changed whitespace or added whitespace crimes
like trailing spaces, or spaces before tabs.

___ You have mixed real technical changes with whitespace and other
cosmetic code cleanup changes. These have to be separate commits.

___ You need to refactor your submission into logical chunks; there is
too much content into a single commit.

___ You have extraneous garbage in your review (merge commits etc)

___ You have giant attachments which should never have been sent;
Instead you should place your content in a public tree to be pulled.

___ You have too many commits attached to an e-mail; resend as threaded
commits, or place in a public tree for a pull.

___ You have resent this content multiple times without a clear indication
of what has changed between each re-send.

___ You have failed to adequately and individually address all of the
comments and change requests that were proposed in the initial review.

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

___ Your computer have a badly configured date and time; confusing the
the threaded patch review.

___ Your changes affect IPC mechanism, and you don't present any results
for in-service upgradability test.

___ Your changes affect user manual and documentation, your patch series
do not contain the patch that updates the Doxygen manual.


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] imm: updated the agent version to latest supported agent version [#2329]

[Hung Nguyen]

Hi Neel,

Reviewed the patch.
Ack from me.

BR,

Hung Nguyen - DEK Technologies



From: Neelakanta Reddy reddy.neelaka...@oracle.com
Sent: Monday, March 06, 2017 5:33PM
To: Hung Nguyen, Zoran Milinkovic
 hung.d.ngu...@dektech.com.au, zoran.milinko...@ericsson.com
Cc: Opensaf-devel
 opensaf-devel@lists.sourceforge.net
Subject: [PATCH 1 of 1] imm: updated the agent version to latest supported 
agent version [#2329]


  src/imm/agent/imma_def.h |  2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/src/imm/agent/imma_def.h b/src/imm/agent/imma_def.h
--- a/src/imm/agent/imma_def.h
+++ b/src/imm/agent/imma_def.h
@@ -22,7 +22,7 @@
  /* Macros for Validating Version */
  #define IMMA_RELEASE_CODE 'A'
  #define IMMA_MAJOR_VERSION 0x02
-#define IMMA_MINOR_VERSION 0x11
+#define IMMA_MINOR_VERSION 0x12
  
  #define IMMSV_WAIT_TIME  1000 /* Default MDS wait time in 10ms units =>10 
sec*/
  


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

[devel] [PATCH 0 of 1] Review Request for mdstest: correct test cases [#2178] V2

[Hoang Vo]

Summary: mdstest: correct test cases [#2178] V2
Review request for Trac Ticket(s): #2178
Peer Reviewer(s): mahesh.va...@oracle.com
Pull request to: mahesh.va...@oracle.com
Affected branch(es): default
Development branch: default


Impacted area   Impact y/n

 Docsn
 Build systemn
 RPM/packaging   n
 Configuration files n
 Startup scripts n
 SAF servicesn
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   y
 Other   n


Comments (indicate scope for each "y" above):
-
Resubmit for pushing

changeset 4072c28b03cfa8945ae50163cdd0718de65e2645
Author: Hoang Vo 
Date:   Tue, 07 Mar 2017 09:41:55 +0700

mdstest: correct test cases [#2178] V2

mdstest return failed in following cases:
- 13 14: message length
- 11 5, 9 5 and so on

actions:
- correct test case following new update
- wait for vdest_change_role() apply result before processing to next 
test
step


Complete diffstat:
--
 src/mds/apitest/mdstipc_api.c  |  8 ++--
 src/mds/apitest/mdstipc_conf.c |  9 +
 2 files changed, 15 insertions(+), 2 deletions(-)


Testing Commands:
-
run mdstest

Testing, Expected Results:
--
all test cases passed

Conditions of Submission:
-
ACK from maintainer

Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  y  y
powerpc n  n
powerpc64   n  n


Reviewer Checklist:
---
[Submitters: make sure that your review doesn't trigger any checkmarks!]


Your checkin has not passed review because (see checked entries):

___ Your RR template is generally incomplete; it has too many blank entries
that need proper data filled in.

___ You have failed to nominate the proper persons for review and push.

___ Your patches do not have proper short+long header

___ You have grammar/spelling in your header that is unacceptable.

___ You have exceeded a sensible line length in your headers/comments/text.

___ You have failed to put in a proper Trac Ticket # into your commits.

___ You have incorrectly put/left internal data in your comments/files
(i.e. internal bug tracking tool IDs, product names etc)

___ You have not given any evidence of testing beyond basic build tests.
Demonstrate some level of runtime or other sanity testing.

___ You have ^M present in some of your files. These have to be removed.

___ You have needlessly changed whitespace or added whitespace crimes
like trailing spaces, or spaces before tabs.

___ You have mixed real technical changes with whitespace and other
cosmetic code cleanup changes. These have to be separate commits.

___ You need to refactor your submission into logical chunks; there is
too much content into a single commit.

___ You have extraneous garbage in your review (merge commits etc)

___ You have giant attachments which should never have been sent;
Instead you should place your content in a public tree to be pulled.

___ You have too many commits attached to an e-mail; resend as threaded
commits, or place in a public tree for a pull.

___ You have resent this content multiple times without a clear indication
of what has changed between each re-send.

___ You have failed to adequately and individually address all of the
comments and change requests that were proposed in the initial review.

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

___ Your computer have a badly configured date and time; confusing the
the threaded patch review.

___ Your changes affect IPC mechanism, and you don't present any results
for in-service upgradability test.

___ Your changes affect user manual and documentation, your patch series
do not contain the patch that updates the Doxygen manual.


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

[devel] [PATCH 1 of 1] mdstest: correct test cases [#2178] V2

[Hoang Vo]

 src/mds/apitest/mdstipc_api.c  |  8 ++--
 src/mds/apitest/mdstipc_conf.c |  9 +
 2 files changed, 15 insertions(+), 2 deletions(-)


mdstest return failed in following cases:
- 13 14: message length
- 11 5, 9 5 and so on

actions:
- correct test case following new update
- wait for vdest_change_role() apply result before processing to next test step

diff --git a/src/mds/apitest/mdstipc_api.c b/src/mds/apitest/mdstipc_api.c
--- a/src/mds/apitest/mdstipc_api.c
+++ b/src/mds/apitest/mdstipc_api.c
@@ -1,6 +1,7 @@
 /*  OpenSAF
  *
  * (C) Copyright 2008 The OpenSAF Foundation
+ * Copyright Ericsson AB 2017 - All Rights Reserved.
  *
  * This program is distributed in the hope that it will be useful, but
  * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
@@ -8982,7 +8983,6 @@ void tet_direct_just_send_tp_14()
 {
   int FAIL=0;
   MDS_SVC_ID svcids[]={NCSMDS_SVC_ID_EXTERNAL_MIN};
-  char big_message[8000];
 
   /*start up*/
   if(tet_initialise_setup(false))
@@ -9010,7 +9010,9 @@ void tet_direct_just_send_tp_14()
 }
 printf("\nTest Case 14: Not able to send a message of size 
>(MDS_DIRECT_BUF_MAXSIZE) to 2000\n");
 
-memset(big_message, 's', 8000);
+char * big_message = (char*)malloc(MDS_DIRECT_BUF_MAXSIZE + 1);
+memset(big_message, 's', MDS_DIRECT_BUF_MAXSIZE + 1);
+*(big_message + MDS_DIRECT_BUF_MAXSIZE) = 0;
 if(mds_direct_send_message(gl_tet_adest.mds_pwe1_hdl,
NCSMDS_SVC_ID_EXTERNAL_MIN,
NCSMDS_SVC_ID_EXTERNAL_MIN,1,
@@ -9024,6 +9026,8 @@ void tet_direct_just_send_tp_14()
 else
   printf("\nSuccess\n");
 
+free(big_message);
+
 printf("\nCancel subscription\n");
 if(mds_service_cancel_subscription(gl_tet_adest.mds_pwe1_hdl,
NCSMDS_SVC_ID_EXTERNAL_MIN,1,
diff --git a/src/mds/apitest/mdstipc_conf.c b/src/mds/apitest/mdstipc_conf.c
--- a/src/mds/apitest/mdstipc_conf.c
+++ b/src/mds/apitest/mdstipc_conf.c
@@ -1,6 +1,7 @@
 /*  OpenSAF
  *
  * (C) Copyright 2008 The OpenSAF Foundation
+ * Copyright Ericsson AB 2017 - All Rights Reserved.
  *
  * This program is distributed in the hope that it will be useful, but
  * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
@@ -21,6 +22,7 @@
 #include "mdstipc.h"
 #include "base/osaf_poll.h"
 extern int fill_syncparameters(int);
+extern uint32_t mds_vdest_tbl_get_role(MDS_VDEST_ID vdest_id, V_DEST_RL *role);
 /** ADEST WRAPPERS ***/
 uint32_t adest_get_handle(void)
 {
@@ -273,6 +275,13 @@ uint32_t vdest_change_role(MDS_DEST vdes
 
   if(ncsvda_api(_info)==NCSCC_RC_SUCCESS)
 {
+/*Making sure vdest change role done*/
+V_DEST_RL role = 0;
+mds_vdest_tbl_get_role(vdest, );
+while(role != new_role) {
+sleep(1);
+mds_vdest_tbl_get_role(vdest, );
+}
   printf("\nVDEST_CHANGE ROLE to %d is SUCCESSFULL",new_role);
   return NCSCC_RC_SUCCESS;
 }

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] AMFND: Ensure su operational message synchronizes with component failover sequence [#2233]

[minh chau]

Hi Praveen,

Please see comments with [Minh5]

Thanks,
Minh

On 06/03/17 17:52, praveen malviya wrote:
> Hi Minh,
>
> Please see inline with [Praveen].
>
> Thanks,
> Praveen
>
> On 03-Mar-17 5:39 PM, minh chau wrote:
>> Hi Praveen,
>>
>> I have two comments with [Minh4].
>>
>> Thanks
>> Minh
>>
>> On 02/03/17 20:49, praveen malviya wrote:
>>> Hi Minh,
>>> Please see response with [Praveen].
>>>
>>> Thanks,
>>> Praveen
>>>
>>>
>>>
>>> On 02-Mar-17 1:43 PM, minh chau wrote:
 Hi,

 Thanks Gary.
 @Nagu, Praveen: Have you had time to check the example in my previous
 email?
 The ticket #2179 is about to document that full escalation is 
 supported
 for SC absence feature, it is waiting for fix of #2233.
 I think there's not big change in code for #2233, it's a matter of
 decision to make for re-instantiation of failed component.

 Thanks,
 Minh

 On 01/03/17 15:42, Gary Lee wrote:
> Hi
>
> It seems the component should be re-instantiated if it has no CSI.
> Whether or not there is an SI assigned should be irrelevant?
>
> Thanks
> Gary
>
> -Original Message-
> From: minh chau 
> Date: Thursday, 23 February 2017 at 3:16 pm
> To: Nagendra Kumar , Praveen Malviya
> 
> Cc: , gary ,
> , 
> 
> Subject: Re: [devel] [PATCH 1 of 1] AMFND: Ensure su operational
> message synchronizes with component failover sequence [#2233]
>
>  Hi Nagu, Praveen,
>   Please find my comment in [Minh3]
>   Thanks,
>  Minh
>   On 22/02/17 19:34, Nagendra Kumar wrote:
>  >>> Since in spec there is no specific discussion for
> comp-failover recovery for an unassigned comp, I will encourage other
> maintainers also to provide inputs.
>  > I do agree for not instantiating failed component before
> recovery, this keeps the approach similar to SU failover also.
>  [Minh3]: There's one example of component failover that I would
> like us
>  to have a look
>  - 2N application, SU4/SU5 has active/standby assignment
> respectively,
>  each SU has 3 components
>  - Add a sleep of 10 seconds in clc script start command of first
>  component C41 of SU4
>  Steps:
>  1- Kill C41 to trigger component failover
>  2- SU4 goes for quiesced assignment
>  3- SU5 goes for active assignment
>  4- SU4 is removed its assignment
>  5- Now there's a pause of 10 seconds due to clc script start, to
> ensure
>  that C41 is healthy
>  6- Next SU4 has standby assignment.
>From the above example, I think we can see some 
> problems if
> the
>  re-instantiation of C41 is delayed:
>  - Because C41 is faulty, it needs to be restarted ok because its
> SU has
>  assignment
>  - Moving re-instantiation of C41 is further down that means the
> recovery
>  will take longer
>  - What if re-instantiation of C41 leads to instantation-failed
>>> [Praveen] If AMFND re-instantiate C41 after removal of assignment and
>>> it moves to instantiation-failed then:
>>> -Node will be rebooted if nodefailfastonterminationfaioure=true.
>>> -ifnodefailfastonterminationfaioure=false then as per section 4.6 page
>>> 212, SU will be marked INST_FAILED and AMF will have to terminate all
>>> the components. Termination of other components will be easier if they
>>> do not have assignments or pending assignments.
>>>
>>> If C41 is instantiated before removal of assignments and it moves to
>>> INST_FAILED state, then AMFND will be terminating other comps of SU
>>> when they are in the middle of quiesced or removal of assignment. So a
>>> component will having different orders of quiesced/removal/terminate
>>> callbacks in its mailbox. This will make thing complex.
>> [Minh4]: I am not sure if I understand the complex thing you mentioned
>> as it has been working like this for long time. If we are going to
>> change the current behavior to the way that amfnd will instantiate
>> failed component after removal assignment, then I think it should be
>> addressed in another enhancement ticket. The complex thing in current
>> behavior could be improved/removed if we change to another behavior. It
>> looks like a big change not just in the code, also backward compatible
>> consideration. At this moment, let's fix the message ordering problem of
>> existing code/design (you already agreed?). I can create another
>> enhancement/discussion ticket for matter of instantiation of failed
>> component, from there more evidence of specs will be added, ... What do
>> you think?
> [Praveen] I have agreed for 

[devel] [PATCH 0 of 1] Review Request for CLM : Cluster reset does not succed as reboot now command fails on SLES [#2339]

[Hans Nordeback]

Summary: CLM : Cluster reset doesn't succed as "reboot now" command fails on 
SLES
Review request for Trac Ticket(s): #2339
Peer Reviewer(s): Ramesh, AndersW
Pull request to:
Affected branch(es): default
Development branch: default


Impacted area   Impact y/n

 Docsn
 Build systemn
 RPM/packaging   n
 Configuration files n
 Startup scripts y
 SAF servicesn
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


Comments (indicate scope for each "y" above):
-
 <>

changeset e90a52509fdd785623172f30f095e5a6b326fa4d
Author: Hans Nordeback 
Date:   Mon, 06 Mar 2017 16:17:01 +0100

CLM : Cluster reset does not succed as reboot now command fails on SLES
[#2339]


Complete diffstat:
--
 scripts/opensaf_reboot |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


Testing Commands:
-
 <>


Testing, Expected Results:
--
 <>


Conditions of Submission:
-
 <>


Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  n  n
powerpc n  n
powerpc64   n  n


Reviewer Checklist:
---
[Submitters: make sure that your review doesn't trigger any checkmarks!]


Your checkin has not passed review because (see checked entries):

___ Your RR template is generally incomplete; it has too many blank entries
that need proper data filled in.

___ You have failed to nominate the proper persons for review and push.

___ Your patches do not have proper short+long header

___ You have grammar/spelling in your header that is unacceptable.

___ You have exceeded a sensible line length in your headers/comments/text.

___ You have failed to put in a proper Trac Ticket # into your commits.

___ You have incorrectly put/left internal data in your comments/files
(i.e. internal bug tracking tool IDs, product names etc)

___ You have not given any evidence of testing beyond basic build tests.
Demonstrate some level of runtime or other sanity testing.

___ You have ^M present in some of your files. These have to be removed.

___ You have needlessly changed whitespace or added whitespace crimes
like trailing spaces, or spaces before tabs.

___ You have mixed real technical changes with whitespace and other
cosmetic code cleanup changes. These have to be separate commits.

___ You need to refactor your submission into logical chunks; there is
too much content into a single commit.

___ You have extraneous garbage in your review (merge commits etc)

___ You have giant attachments which should never have been sent;
Instead you should place your content in a public tree to be pulled.

___ You have too many commits attached to an e-mail; resend as threaded
commits, or place in a public tree for a pull.

___ You have resent this content multiple times without a clear indication
of what has changed between each re-send.

___ You have failed to adequately and individually address all of the
comments and change requests that were proposed in the initial review.

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

___ Your computer have a badly configured date and time; confusing the
the threaded patch review.

___ Your changes affect IPC mechanism, and you don't present any results
for in-service upgradability test.

___ Your changes affect user manual and documentation, your patch series
do not contain the patch that updates the Doxygen manual.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

[devel] [PATCH 1 of 1] CLM : Cluster reset does not succed as reboot now command fails on SLES [#2339]

[Hans Nordeback]

 scripts/opensaf_reboot |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/scripts/opensaf_reboot b/scripts/opensaf_reboot
--- a/scripts/opensaf_reboot
+++ b/scripts/opensaf_reboot
@@ -48,7 +48,7 @@ test $(id -u) -ne 0 && icmd=$(which sudo
 opensaf_safe_reboot()
 {
logger -t "opensaf_reboot" "Rebooting local node using $icmd 
/sbin/reboot now"
-   $icmd /sbin/reboot now
+   $icmd /sbin/shutdown -r now
 }
 
 ## Use stonith for remote fencing

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] log: fix leak memory in socket destination handler [#2344]

[Canh Van Truong]

Hi aVu,

Ack

Thanks
Canh

-Original Message-
From: Vu Minh Nguyen [mailto:vu.m.ngu...@dektech.com.au] 
Sent: Monday, March 6, 2017 1:11 PM
To: lennart.l...@ericsson.com; mahesh.va...@oracle.com;
canh.v.tru...@dektech.com.au
Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 1 of 1] log: fix leak memory in socket destination handler
[#2344]

 src/log/logd/lgs_dest.cc |  4 
 1 files changed, 4 insertions(+), 0 deletions(-)


DestinationHandler::UpdateRtDestStatus() uses lgs_cfgupd_mutival_replace()
to update logRecordDestinationStatus but not freeing buffer
at the end of the function.

This fix does freeing that buffer.

diff --git a/src/log/logd/lgs_dest.cc b/src/log/logd/lgs_dest.cc
--- a/src/log/logd/lgs_dest.cc
+++ b/src/log/logd/lgs_dest.cc
@@ -184,6 +184,10 @@ void DestinationHandler::UpdateRtDestSta
   if (ret == -1) {
 LOG_WA("%s lgs_cfg_update Fail", __func__);
   }
+
+  // Free memory allocated for the config_data buffer
+  if (config_data.ckpt_buffer_ptr != nullptr)
+free(config_data.ckpt_buffer_ptr);
 }
 
 void DestinationHandler::FormCfgDestMsg(


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] SMF: problem with suspend

[Alex Jones]

Hi Neel,

  I see this problem without my changes (2144 and 2145). If I do
"smf-adm suspend ", and the currently executing procedure has one
step left waiting for reboot, when the step completes, the procedure
will not move to "suspended" state.

  When I remove this code in the patch, everything works fine. It's not
clear to me why we can't remove it.

Alex

On 03/06/2017 03:05 AM, Neelakanta Reddy wrote:
> 
> NOTICE: This email was received from an EXTERNAL sender
> 
> 
> Hi Alex,
> 
> What problem has been observed, you mean say the campaign suspend is not
> happening after #2145 and #2144 when the component restart is found at
> the time of last step?
> 
> Thanks,
> Neel.
> 
> On 2017/03/03 11:58 PM, Alex Jones wrote:
>> Hi Guys,
>>
>> I've created ticket 2332 for a problem that I'm seeing. I'd like to
>> remove some code in SmfProcState.cc, but there's a comment there that I
>> don't understand.
>>
>> Can any of you explain the comments about "We don't want to be able to
>> suspend between ..."? I can't figure out why we can't do this.
>>
>> I've attached the proposed diff.
>>
>> Alex



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] log: Fix all Cppcheck 1.77 issues [#2326] V1

[Canh Van Truong]

Hi Mahesh,

Ack from me.

Thanks
Canh

-Original Message-
From: mahesh.va...@oracle.com [mailto:mahesh.va...@oracle.com] 
Sent: Thursday, March 2, 2017 5:16 AM
To: canh.v.tru...@dektech.com.au; lennart.l...@ericsson.com;
vu.m.ngu...@dektech.com.au
Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 1 of 1] log: Fix all Cppcheck 1.77 issues [#2326] V1

 src/log/agent/lga_api.c  |   3 +--
 src/log/agent/lga_mds.c  |   6 ++
 src/log/agent/lga_state.c|   3 +--
 src/log/agent/lga_util.c |   4 +---
 src/log/logd/lgs_clm.cc  |   8 +++-
 src/log/logd/lgs_config.cc   |  36 +---
 src/log/logd/lgs_config.h|  10 +-
 src/log/logd/lgs_evt.cc  |  17 +++--
 src/log/logd/lgs_filehdl.cc  |   4 
 src/log/logd/lgs_fmt.cc  |   3 +--
 src/log/logd/lgs_imm.cc  |  25 -
 src/log/logd/lgs_imm_gcfg.cc |  21 +++--
 src/log/logd/lgs_main.cc |   2 +-
 src/log/logd/lgs_mbcsv.cc|  21 -
 src/log/logd/lgs_mds.cc  |   3 +--
 src/log/logd/lgs_stream.cc   |   6 ++
 src/log/logd/lgs_util.cc |  10 --
 17 files changed, 73 insertions(+), 109 deletions(-)


V1 is on 5.2 GA tag
Except never used functions all other issues are fixed  of below,
some UN-pushed enhancement may be using those functions.


==
[staging/src/log/logd/lgs_config.h:90]: (performance) Function parameter
param_name should be passed by reference.
[staging/src/log/logd/lgs_config.h:230]: (performance) Function parameter
attribute_name should be passed by reference.
[staging/src/log/logd/lgs_config.h:231]: (performance) Function parameter
value_list should be passed by reference.
[staging/src/log/logd/lgs_config.h:238]: (performance) Function parameter
attribute_name should be passed by reference.
[staging/src/log/logd/lgs_config.h:239]: (performance) Function parameter
value_list should be passed by reference.
[staging/src/log/logd/lgs_clm.cc:137]: (style) The scope of the variable
clm_node can be reduced.
[staging/src/log/logd/lgs_clm.cc:220]: (performance) Prefer prefix ++/--
operators for non-primitive types.
[staging/src/log/logd/lgs_config.cc:401] ->
[staging/src/log/logd/lgs_config.cc:498]: (warning) Either the condition
allocmem_ptr!=NULL is redundant or there is possible null pointer
dereference: param_ptr.
[staging/src/log/logd/lgs_config.cc:410] ->
[staging/src/log/logd/lgs_config.cc:498]: (warning) Either the condition
allocmem_ptr!=NULL is redundant or there is possible null pointer
dereference: param_ptr.
[staging/src/log/logd/lgs_config.cc:184] ->
[staging/src/log/logd/lgs_config.cc:190]: (style) Variable cfg_param_str is
reassigned a value before the old one has been used.
[staging/src/log/logd/lgs_config.cc:183]: (style) The scope of the variable
prev_size can be reduced.
[staging/src/log/logd/lgs_config.cc:727]: (style) The scope of the variable
nl_cnt can be reduced.
[staging/src/log/logd/lgs_config.cc:995]: (style) The scope of the variable
value_string can be reduced.
[staging/src/log/logd/lgs_config.cc:1034]: (style) The scope of the variable
n can be reduced.
[staging/src/log/logd/lgs_config.cc:142]: (warning) Member variable
_lgs_conf_t::chkp_file_close_time is not initialized in the constructor.
[staging/src/log/logd/lgs_config.cc:293]: (performance) Function parameter
attribute_name should be passed by reference.
[staging/src/log/logd/lgs_config.cc:294]: (performance) Function parameter
value_list should be passed by reference.
[staging/src/log/logd/lgs_config.cc:324]: (performance) Function parameter
attribute_name should be passed by reference.
[staging/src/log/logd/lgs_config.cc:325]: (performance) Function parameter
value_list should be passed by reference.
[staging/src/log/logd/lgs_evt.cc:531] ->
[staging/src/log/logd/lgs_evt.cc:536]: (style) Variable lga_down_rec is
reassigned a value before the old one has been used.
[staging/src/log/logd/lgs_evt.cc:416]: (style) The scope of the variable
ckpt_ptr can be reduced.
[staging/src/log/logd/lgs_evt.cc:553]: (style) The scope of the variable
stream can be reduced.
[staging/src/log/logd/lgs_evt.cc:163]: (error) Mismatching allocation and
deallocation: client
[staging/src/log/logd/lgs_evt.cc:168]: (error) Mismatching allocation and
deallocation: client
[staging/src/log/logd/lgs_evt.cc:344]: (performance) Prefer prefix ++/--
operators for non-primitive types.
[staging/src/log/logd/lgs_filehdl.cc:542]: (style) Variable len is assigned
a value that is never used.
[staging/src/log/logd/lgs_fmt.cc:560]: (style) The scope of the variable
no_ch can be reduced.
[staging/src/log/logd/lgs_imm.cc:3478] ->
[staging/src/log/logd/lgs_imm.cc:3479]: (warning) Either the condition
attribute!=NULL is redundant or there is possible null pointer dereference:
attribute.
[staging/src/log/logd/lgs_imm.cc:963]: (style) The scope of the variable i
can 

Re: [devel] [PATCH 1 of 1] imm:changing clm indicating object to CLMS node up [#2330] V2

[Zoran Milinkovic]

Hi Neelakanta,

After applying the patch, immnd on payloads crashing after coming from headless 
state.
Before the patch, immnd was more stable.

This is a test with one SC and one PL with SC absence allowed.
1. Bring both SC-1 and PL-3 up
2. Take SC-1 down to go to headless state
3. Take SC-1 up, and after the sync, PL-3 reboots

These are logs from PL-3 when the sync was announced:

Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO Announce sync, epoch:45
Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO SERVER STATE: IMM_SERVER_READY --> 
IMM_SERVER_SYNC_SERVER
Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO NODE STATE-> IMM_NODE_R_AVAILABLE
Mar  6 15:37:08 PL-3 osafimmloadd: NO Sync starting
Mar  6 15:37:08 PL-3 osafimmloadd: IN Synced 382 objects in total
Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO NODE STATE-> IMM_NODE_FULLY_AVAILABLE 
18511
Mar  6 15:37:08 PL-3 osafimmloadd: NO Sync ending normally
Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO Epoch set to 45 in ImmModel
Mar  6 15:37:08 PL-3 osafimmpbed: NO Update epoch 45 committing with 
ccbId:1000d/4294967309
Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO Implementer connected: 37 
(MsgQueueService131855) <53, 2030f>
Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO Implementer connected: 38 
(safLogService) <0, 2010f>
Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO Implementer (applier) connected: 39 
(@safLogService_appl) <0, 2010f>
Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO SERVER STATE: IMM_SERVER_SYNC_SERVER 
--> IMM_SERVER_READY
Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO Implementer (applier) connected: 40 
(@OpenSafImmReplicatorA) <0, 2010f>
Mar  6 15:37:08 PL-3 osafmsgnd[2669]: ER saClmDispatch Failed with error 9
Mar  6 15:37:08 PL-3 osafckptnd[2638]: NO Bad CLM handle. Reinitializing.
Mar  6 15:37:08 PL-3 osafimmnd[2609]: src/imm/immnd/immnd_main.c:401: main: 
Assertion '!immnd_cb->clm_hdl' failed.
Mar  6 15:37:08 PL-3 osafimmpbed: WA PBE lost contact with parent IMMND - 
Exiting
Mar  6 15:37:08 PL-3 osafamfnd[2619]: NO AVD NEW_ACTIVE, adest:1
Mar  6 15:37:09 PL-3 osafamfnd[2619]: NO saClmDispatch BAD_HANDLE
Mar  6 15:37:09 PL-3 osafamfnd[2619]: NO 1 SISU states sent
Mar  6 15:37:09 PL-3 osafamfnd[2619]: NO 1 SU states sent
Mar  6 15:37:09 PL-3 osafamfnd[2619]: NO 7 CSICOMP states sent
Mar  6 15:37:09 PL-3 osafamfnd[2619]: NO 7 COMP states sent
Mar  6 15:37:09 PL-3 osafamfnd[2619]: NO Sending node up due to 
NCSMDS_NEW_ACTIVE
Mar  6 15:37:09 PL-3 osafamfnd[2619]: NO 
'safSu=PL-3,safSg=NoRed,safApp=OpenSAF' component restart probation timer 
started (timeout: 600 ns)
Mar  6 15:37:09 PL-3 osafamfnd[2619]: NO Restarting a component of 
'safSu=PL-3,safSg=NoRed,safApp=OpenSAF' (comp restart count: 1)
Mar  6 15:37:09 PL-3 osafamfnd[2619]: NO 
'safComp=IMMND,safSu=PL-3,safSg=NoRed,safApp=OpenSAF' faulted due to 'avaDown' 
: Recovery is 'componentRestart'
Mar  6 15:37:09 PL-3 osafimmnd[2748]: mkfifo already exists: 
/var/lib/opensaf/osafimmnd.fifo File exists
Mar  6 15:37:09 PL-3 osafimmnd[2748]: Started
Mar  6 15:37:09 PL-3 osafimmnd[2748]: NO Persistent Back-End capability 
configured, Pbe file:imm.db (suffix may get added)
Mar  6 15:37:09 PL-3 osafimmnd[2748]: NO IMMD service is UP ... 
ScAbsenseAllowed?:0 introduced?:0
Mar  6 15:37:09 PL-3 osafimmnd[2748]: NO Fevs count adjusted to 3118 
preLoadPid: 0
Mar  6 15:37:09 PL-3 osafimmnd[2748]: NO SERVER STATE: IMM_SERVER_ANONYMOUS --> 
IMM_SERVER_CLUSTER_WAITING
Mar  6 15:37:14 PL-3 osafimmnd[2748]: WA Resending introduce-me - problems with 
MDS ? 5.036740
Mar  6 15:37:14 PL-3 osafimmnd[2748]: WA Resending introduce-me - problems with 
MDS ? 5.146260
Mar  6 15:37:14 PL-3 osafimmnd[2748]: WA Resending introduce-me - problems with 
MDS ? 5.254418
Mar  6 15:37:14 PL-3 osafimmnd[2748]: WA Resending introduce-me - problems with 
MDS ? 5.356613
Mar  6 15:37:14 PL-3 osafimmnd[2748]: WA Resending introduce-me - problems with 
MDS ? 5.457990
Mar  6 15:37:14 PL-3 osafimmnd[2748]: WA Resending introduce-me - problems with 
MDS ? 5.566638
Mar  6 15:37:14 PL-3 osafimmnd[2748]: WA Resending introduce-me - problems with 
MDS ? 5.674698
Mar  6 15:37:15 PL-3 osafimmnd[2748]: WA Resending introduce-me - problems with 
MDS ? 5.776658
Mar  6 15:37:15 PL-3 osafimmnd[2748]: WA Resending introduce-me - problems with 
MDS ? 5.878120
Mar  6 15:37:15 PL-3 osafimmnd[2748]: WA Resending introduce-me - problems with 
MDS ? 5.986782
Mar  6 15:37:17 PL-3 kernel: [  184.318845] hrtimer: interrupt took 4383423 ns
Mar  6 15:37:19 PL-3 osafamfnd[2619]: WA saClmInitialize_4 returned 5
Mar  6 15:37:19 PL-3 osafckptnd[2638]: WA cpnd_lib_init: saClmInitialize 
returned 5
Mar  6 15:37:19 PL-3 osafimmnd[2748]: WA Resending introduce-me - problems with 
MDS ? 10.139687
Mar  6 15:37:19 PL-3 osafimmnd[2748]: WA Resending introduce-me - problems with 
MDS ? 10.249445
Mar  6 15:37:19 PL-3 osafimmnd[2748]: WA Resending introduce-me - problems with 
MDS ? 10.352214
Mar  6 15:37:19 PL-3 osafimmnd[2748]: WA Resending introduce-me - problems with 
MDS ? 10.458604
Mar  6 15:37:19 PL-3 

Re: [devel] [PATCH 1 of 1] log: fix leak memory in socket destination handler [#2344]

[Lennart Lund]

Ack

Thanks
Lennart

> -Original Message-
> From: Vu Minh Nguyen [mailto:vu.m.ngu...@dektech.com.au]
> Sent: den 6 mars 2017 13:11
> To: Lennart Lund ; mahesh.va...@oracle.com;
> Canh Van Truong 
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] log: fix leak memory in socket destination handler
> [#2344]
> 
>  src/log/logd/lgs_dest.cc |  4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> 
> DestinationHandler::UpdateRtDestStatus() uses
> lgs_cfgupd_mutival_replace()
> to update logRecordDestinationStatus but not freeing buffer
> at the end of the function.
> 
> This fix does freeing that buffer.
> 
> diff --git a/src/log/logd/lgs_dest.cc b/src/log/logd/lgs_dest.cc
> --- a/src/log/logd/lgs_dest.cc
> +++ b/src/log/logd/lgs_dest.cc
> @@ -184,6 +184,10 @@ void DestinationHandler::UpdateRtDestSta
>if (ret == -1) {
>  LOG_WA("%s lgs_cfg_update Fail", __func__);
>}
> +
> +  // Free memory allocated for the config_data buffer
> +  if (config_data.ckpt_buffer_ptr != nullptr)
> +free(config_data.ckpt_buffer_ptr);
>  }
> 
>  void DestinationHandler::FormCfgDestMsg(

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

[devel] [PATCH 0 of 1] Review Request for log: fix leak memory in socket destination handler [#2344]

[Vu Minh Nguyen]

Summary: log: fix leak memory in socket destination handler [#2344]
Review request for Trac Ticket(s): #2344
Peer Reviewer(s): Lennart, Canh, Mahesh
Pull request to: <>
Affected branch(es): Default
Development branch: Default


Impacted area   Impact y/n

 Docsn
 Build systemn
 RPM/packaging   n
 Configuration files n
 Startup scripts n
 SAF servicesy
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


Comments (indicate scope for each "y" above):
-
 <>

changeset 1444abdab7a1a62eb64f619947995099933ab94f
Author: Vu Minh Nguyen 
Date:   Mon, 06 Mar 2017 16:38:37 +0700

log: fix leak memory in socket destination handler [#2344]

DestinationHandler::UpdateRtDestStatus() uses 
lgs_cfgupd_mutival_replace()
to update logRecordDestinationStatus but not freeing buffer at the end 
of
the function.

This fix does freeing that buffer.


Complete diffstat:
--
 src/log/logd/lgs_dest.cc |  4 
 1 files changed, 4 insertions(+), 0 deletions(-)


Testing Commands:
-
 <>


Testing, Expected Results:
--
 <>


Conditions of Submission:
-
 <>


Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  n  n
powerpc n  n
powerpc64   n  n


Reviewer Checklist:
---
[Submitters: make sure that your review doesn't trigger any checkmarks!]


Your checkin has not passed review because (see checked entries):

___ Your RR template is generally incomplete; it has too many blank entries
that need proper data filled in.

___ You have failed to nominate the proper persons for review and push.

___ Your patches do not have proper short+long header

___ You have grammar/spelling in your header that is unacceptable.

___ You have exceeded a sensible line length in your headers/comments/text.

___ You have failed to put in a proper Trac Ticket # into your commits.

___ You have incorrectly put/left internal data in your comments/files
(i.e. internal bug tracking tool IDs, product names etc)

___ You have not given any evidence of testing beyond basic build tests.
Demonstrate some level of runtime or other sanity testing.

___ You have ^M present in some of your files. These have to be removed.

___ You have needlessly changed whitespace or added whitespace crimes
like trailing spaces, or spaces before tabs.

___ You have mixed real technical changes with whitespace and other
cosmetic code cleanup changes. These have to be separate commits.

___ You need to refactor your submission into logical chunks; there is
too much content into a single commit.

___ You have extraneous garbage in your review (merge commits etc)

___ You have giant attachments which should never have been sent;
Instead you should place your content in a public tree to be pulled.

___ You have too many commits attached to an e-mail; resend as threaded
commits, or place in a public tree for a pull.

___ You have resent this content multiple times without a clear indication
of what has changed between each re-send.

___ You have failed to adequately and individually address all of the
comments and change requests that were proposed in the initial review.

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

___ Your computer have a badly configured date and time; confusing the
the threaded patch review.

___ Your changes affect IPC mechanism, and you don't present any results
for in-service upgradability test.

___ Your changes affect user manual and documentation, your patch series
do not contain the patch that updates the Doxygen manual.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

[devel] [PATCH 1 of 1] log: fix leak memory in socket destination handler [#2344]

[Vu Minh Nguyen]

 src/log/logd/lgs_dest.cc |  4 
 1 files changed, 4 insertions(+), 0 deletions(-)


DestinationHandler::UpdateRtDestStatus() uses lgs_cfgupd_mutival_replace()
to update logRecordDestinationStatus but not freeing buffer
at the end of the function.

This fix does freeing that buffer.

diff --git a/src/log/logd/lgs_dest.cc b/src/log/logd/lgs_dest.cc
--- a/src/log/logd/lgs_dest.cc
+++ b/src/log/logd/lgs_dest.cc
@@ -184,6 +184,10 @@ void DestinationHandler::UpdateRtDestSta
   if (ret == -1) {
 LOG_WA("%s lgs_cfg_update Fail", __func__);
   }
+
+  // Free memory allocated for the config_data buffer
+  if (config_data.ckpt_buffer_ptr != nullptr)
+free(config_data.ckpt_buffer_ptr);
 }
 
 void DestinationHandler::FormCfgDestMsg(

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] imm: updated the agent version to latest supported agent version [#2329]

[Zoran Milinkovic]

Hi Neelakanta,

Ack from me.

Thanks,
Zoran

-Original Message-
From: reddy.neelaka...@oracle.com [mailto:reddy.neelaka...@oracle.com] 
Sent: den 6 mars 2017 11:34
To: Hung Duc Nguyen ; Zoran Milinkovic 

Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 1 of 1] imm: updated the agent version to latest supported 
agent version [#2329]

 src/imm/agent/imma_def.h |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/src/imm/agent/imma_def.h b/src/imm/agent/imma_def.h
--- a/src/imm/agent/imma_def.h
+++ b/src/imm/agent/imma_def.h
@@ -22,7 +22,7 @@
 /* Macros for Validating Version */
 #define IMMA_RELEASE_CODE 'A'
 #define IMMA_MAJOR_VERSION 0x02
-#define IMMA_MINOR_VERSION 0x11
+#define IMMA_MINOR_VERSION 0x12
 
 #define IMMSV_WAIT_TIME  1000 /* Default MDS wait time in 10ms units =>10 sec*/
 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

[devel] [PATCH 1 of 1] imm: updated the agent version to latest supported agent version [#2329]

[reddy . neelakanta]

 src/imm/agent/imma_def.h |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/src/imm/agent/imma_def.h b/src/imm/agent/imma_def.h
--- a/src/imm/agent/imma_def.h
+++ b/src/imm/agent/imma_def.h
@@ -22,7 +22,7 @@
 /* Macros for Validating Version */
 #define IMMA_RELEASE_CODE 'A'
 #define IMMA_MAJOR_VERSION 0x02
-#define IMMA_MINOR_VERSION 0x11
+#define IMMA_MINOR_VERSION 0x12
 
 #define IMMSV_WAIT_TIME  1000 /* Default MDS wait time in 10ms units =>10 sec*/
 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

[devel] [PATCH 0 of 1] Review Request for imm: updated the agent version to latest supported agent version [#2329]

[reddy . neelakanta]

Summary:imm: updated the agent version to latest supported agent version 
[#2329] 
Review request for Trac Ticket(s): 2329
Peer Reviewer(s): Zoran, Hung
Affected branch(es): default(5.2)
Development branch: default


Impacted area   Impact y/n

 Docsn
 Build systemn
 RPM/packaging   n
 Configuration files n
 Startup scripts n
 SAF servicesy
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


Comments (indicate scope for each "y" above):
-

changeset 6a7576f0c463aca91f1b44a3961456da731ecac5
Author: Neelakanta Reddy 
Date:   Mon, 06 Mar 2017 15:58:01 +0530

imm: updated the agent version to latest supported agent version [#2329]


Complete diffstat:
--
 src/imm/agent/imma_def.h |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


Testing Commands:
-
for OM/OI intialize donot specify inout parameter 

Testing, Expected Results:
--
version is not specified the inout parameter 
will be latest supported A.02.18 

Conditions of Submission:
-
Ack from Reviewers

Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  y  y
powerpc n  n
powerpc64   n  n


Reviewer Checklist:
---
[Submitters: make sure that your review doesn't trigger any checkmarks!]


Your checkin has not passed review because (see checked entries):

___ Your RR template is generally incomplete; it has too many blank entries
that need proper data filled in.

___ You have failed to nominate the proper persons for review and push.

___ Your patches do not have proper short+long header

___ You have grammar/spelling in your header that is unacceptable.

___ You have exceeded a sensible line length in your headers/comments/text.

___ You have failed to put in a proper Trac Ticket # into your commits.

___ You have incorrectly put/left internal data in your comments/files
(i.e. internal bug tracking tool IDs, product names etc)

___ You have not given any evidence of testing beyond basic build tests.
Demonstrate some level of runtime or other sanity testing.

___ You have ^M present in some of your files. These have to be removed.

___ You have needlessly changed whitespace or added whitespace crimes
like trailing spaces, or spaces before tabs.

___ You have mixed real technical changes with whitespace and other
cosmetic code cleanup changes. These have to be separate commits.

___ You need to refactor your submission into logical chunks; there is
too much content into a single commit.

___ You have extraneous garbage in your review (merge commits etc)

___ You have giant attachments which should never have been sent;
Instead you should place your content in a public tree to be pulled.

___ You have too many commits attached to an e-mail; resend as threaded
commits, or place in a public tree for a pull.

___ You have resent this content multiple times without a clear indication
of what has changed between each re-send.

___ You have failed to adequately and individually address all of the
comments and change requests that were proposed in the initial review.

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

___ Your computer have a badly configured date and time; confusing the
the threaded patch review.

___ Your changes affect IPC mechanism, and you don't present any results
for in-service upgradability test.

___ Your changes affect user manual and documentation, your patch series
do not contain the patch that updates the Doxygen manual.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 0 of 1] Review Request for imm: Sync latest ccb-id to sync clients [#2323]

[Neelakanta Reddy]

Hi Hung,

Reviewed and tested the patch.
Ack.

/Neel.

On 2017/03/01 12:32 PM, Hung Nguyen wrote:
> Summary: imm: Sync latest ccb-id to sync clients [#2323]
> Review request for Trac Ticket(s): 2323
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.0, 5.1, 5.2
> Development branch: 5.2
>
> 
> Impacted area   Impact y/n
> 
>   Docsn
>   Build systemn
>   RPM/packaging   n
>   Configuration files n
>   Startup scripts n
>   SAF servicesy
>   OpenSAF servicesn
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
>
>
> changeset bb9bc2cb99f8fa18ee3ee74094468c0bbef15ead
> Author:   Hung Nguyen 
> Date: Wed, 01 Mar 2017 14:01:14 +0700
>
>   imm: Sync latest ccb-id to sync clients [#2323]
>
>   When finalizing sync, immnd coordinator stores latest ccb-id in
>   ImmsvCcbOutcomeList. It is stored as a ccb with ccb-id being zero. The 
> sync
>   clients update mLatestCcbId when receiving ND2ND_SYNC_FINALIZE_2 
> message.
>
>   When rolling upgrading, it's not a valid case when an old-versioned node
>   joins the cluster. After rebooting, the nodes are supposed to be 
> upgraded
>   and run with new version. We don't have to worry about old-versioned 
> sync-
>   client receiving ccb-id = 0.
>
>   We don't have to sync latest admo-id and latest implementer-id because 
> amdo
>   and implementer are all "cleared" in IMMND when headless. There won't 
> be any
>   problem if IMMD reset IMMD_CB.admo_id_count and IMMD_CB.impl_count.
>
>
> Complete diffstat:
> --
>   src/imm/immnd/ImmModel.cc |  23 +++
>   src/imm/immnd/ImmModel.h  |   2 +-
>   2 files changed, 20 insertions(+), 5 deletions(-)
>
>
> Testing Commands:
> -
> See the ticket for more details.
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch 

Re: [devel] [PATCH 1 of 1] mdstest: correct test cases [#2178]

[A V Mahesh]

  Hi Hoang Vo,

  ACK , with following ,tested.

  use directly the macro   `#MDS_DIRECT_BUF_MAXSIZE  (65535 - (57 + 
_POSIX_HOST_NAME_MAX))`
   src/mds/mds_papi.h , so that in further change in MDS header will not 
effect the test case .

-AVM
On 3/6/2017 1:20 PM, Hoang Vo wrote:
>   src/mds/apitest/mdstipc_api.c  |  8 ++--
>   src/mds/apitest/mdstipc_conf.c |  9 +
>   2 files changed, 15 insertions(+), 2 deletions(-)
>
>
> mdstest return failed in following cases:
> - 13 14: message length
> - 11 5, 9 5 and so on
>
> actions:
> - correct test case following new update
> - wait for vdest_change_role() apply result before processing to next test 
> step
>
> diff --git a/src/mds/apitest/mdstipc_api.c b/src/mds/apitest/mdstipc_api.c
> --- a/src/mds/apitest/mdstipc_api.c
> +++ b/src/mds/apitest/mdstipc_api.c
> @@ -1,6 +1,7 @@
>   /*  OpenSAF
>*
>* (C) Copyright 2008 The OpenSAF Foundation
> + * Copyright Ericsson AB 2017 - All Rights Reserved.
>*
>* This program is distributed in the hope that it will be useful, but
>* WITHOUT ANY WARRANTY; without even the implied warranty of 
> MERCHANTABILITY
> @@ -8982,7 +8983,6 @@ void tet_direct_just_send_tp_14()
>   {
> int FAIL=0;
> MDS_SVC_ID svcids[]={NCSMDS_SVC_ID_EXTERNAL_MIN};
> -  char big_message[8000];
>   
> /*start up*/
> if(tet_initialise_setup(false))
> @@ -9010,7 +9010,9 @@ void tet_direct_just_send_tp_14()
>   }
>   printf("\nTest Case 14: Not able to send a message of size 
> >(MDS_DIRECT_BUF_MAXSIZE) to 2000\n");
>   
> -memset(big_message, 's', 8000);
> +char * big_message = (char*)malloc(65224);
> +memset(big_message, 's', 65224);
> +*(big_message + 65223) = 0;
>   if(mds_direct_send_message(gl_tet_adest.mds_pwe1_hdl,
>  NCSMDS_SVC_ID_EXTERNAL_MIN,
>  NCSMDS_SVC_ID_EXTERNAL_MIN,1,
> @@ -9024,6 +9026,8 @@ void tet_direct_just_send_tp_14()
>   else
> printf("\nSuccess\n");
>   
> +free(big_message);
> +
>   printf("\nCancel subscription\n");
>   if(mds_service_cancel_subscription(gl_tet_adest.mds_pwe1_hdl,
>  NCSMDS_SVC_ID_EXTERNAL_MIN,1,
> diff --git a/src/mds/apitest/mdstipc_conf.c b/src/mds/apitest/mdstipc_conf.c
> --- a/src/mds/apitest/mdstipc_conf.c
> +++ b/src/mds/apitest/mdstipc_conf.c
> @@ -1,6 +1,7 @@
>   /*  OpenSAF
>*
>* (C) Copyright 2008 The OpenSAF Foundation
> + * Copyright Ericsson AB 2017 - All Rights Reserved.
>*
>* This program is distributed in the hope that it will be useful, but
>* WITHOUT ANY WARRANTY; without even the implied warranty of 
> MERCHANTABILITY
> @@ -21,6 +22,7 @@
>   #include "mdstipc.h"
>   #include "base/osaf_poll.h"
>   extern int fill_syncparameters(int);
> +extern uint32_t mds_vdest_tbl_get_role(MDS_VDEST_ID vdest_id, V_DEST_RL 
> *role);
>   /** ADEST WRAPPERS ***/
>   uint32_t adest_get_handle(void)
>   {
> @@ -273,6 +275,13 @@ uint32_t vdest_change_role(MDS_DEST vdes
>   
> if(ncsvda_api(_info)==NCSCC_RC_SUCCESS)
>   {
> +/*Making sure vdest change role done*/
> +V_DEST_RL role = 0;
> +mds_vdest_tbl_get_role(vdest, );
> +while(role != new_role) {
> +sleep(1);
> +mds_vdest_tbl_get_role(vdest, );
> +}
> printf("\nVDEST_CHANGE ROLE to %d is SUCCESSFULL",new_role);
> return NCSCC_RC_SUCCESS;
>   }


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

[devel] [PATCH 0 of 1] Review Request for amfnd: update counters during switchover [#2345]

[nagendra . k]

Summary: amfnd: update counters during switchover [#2345]
Review request for Trac Ticket(s): #2345
Peer Reviewer(s): Amf Dev
Pull request to: <>
Affected branch(es): 5.1 and default
Development branch: Default 


Impacted area   Impact y/n

 Docsn
 Build systemn
 RPM/packaging   n
 Configuration files n
 Startup scripts n
 SAF servicesy
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


Comments (indicate scope for each "y" above):
-
 <>

changeset 3268649ae0f11819489da0d3ba7258f30773ccef
Author: Nagendra Kumar
Date:   Mon, 06 Mar 2017 13:15:11 +0530

amfnd: update counters during switchover [#2345] In some cases, Amfnd is
getting role change event before AVD up message, which is rare. In
avnd_evt_avd_role_change_evh, if AVD flag is not marked up, then it is 
not
updating the counters and returning from there. This creates a mismatch 
into
counters of messages exchanged among amfd and amfnd. This leads to Amfnd
reboots the node. Since, avnd_evt_avd_role_change_evh is not a 
significant
message for Amfnd, so we can update the messages counters first and 
return
from there.


Complete diffstat:
--
 src/amf/amfnd/di.cc |  13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)


Testing Commands:
-
As per ticket.

Testing, Expected Results:
--
No crash of Amfnd.

Conditions of Submission:
-
Ack

Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  y  y
powerpc n  n
powerpc64   n  n


Reviewer Checklist:
---
[Submitters: make sure that your review doesn't trigger any checkmarks!]


Your checkin has not passed review because (see checked entries):

___ Your RR template is generally incomplete; it has too many blank entries
that need proper data filled in.

___ You have failed to nominate the proper persons for review and push.

___ Your patches do not have proper short+long header

___ You have grammar/spelling in your header that is unacceptable.

___ You have exceeded a sensible line length in your headers/comments/text.

___ You have failed to put in a proper Trac Ticket # into your commits.

___ You have incorrectly put/left internal data in your comments/files
(i.e. internal bug tracking tool IDs, product names etc)

___ You have not given any evidence of testing beyond basic build tests.
Demonstrate some level of runtime or other sanity testing.

___ You have ^M present in some of your files. These have to be removed.

___ You have needlessly changed whitespace or added whitespace crimes
like trailing spaces, or spaces before tabs.

___ You have mixed real technical changes with whitespace and other
cosmetic code cleanup changes. These have to be separate commits.

___ You need to refactor your submission into logical chunks; there is
too much content into a single commit.

___ You have extraneous garbage in your review (merge commits etc)

___ You have giant attachments which should never have been sent;
Instead you should place your content in a public tree to be pulled.

___ You have too many commits attached to an e-mail; resend as threaded
commits, or place in a public tree for a pull.

___ You have resent this content multiple times without a clear indication
of what has changed between each re-send.

___ You have failed to adequately and individually address all of the
comments and change requests that were proposed in the initial review.

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

___ Your computer have a badly configured date and time; confusing the
the threaded patch review.

___ Your changes affect IPC mechanism, and you don't present any results
for in-service upgradability test.

___ Your changes affect user manual and documentation, your patch series
do not contain the patch that updates the Doxygen manual.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

[devel] [PATCH 1 of 1] amfnd: update counters during switchover [#2345]

[nagendra . k]

 src/amf/amfnd/di.cc |  13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)


In some cases, Amfnd is getting role change event
before AVD up message, which is rare.
In avnd_evt_avd_role_change_evh, if AVD flag is
not marked up, then it is not updating the counters and
returning from there. This creates a mismatch into counters of messages
exchanged among amfd and amfnd. This leads to Amfnd reboots the node.
Since, avnd_evt_avd_role_change_evh is not a significant message for
Amfnd, so we can update the messages counters first and return from there.

diff --git a/src/amf/amfnd/di.cc b/src/amf/amfnd/di.cc
--- a/src/amf/amfnd/di.cc
+++ b/src/amf/amfnd/di.cc
@@ -1510,12 +1510,7 @@ uint32_t avnd_evt_avd_role_change_evh(AV
 
TRACE_ENTER();
 
-   /* dont process unless AvD is up */
-   if (!m_AVND_CB_IS_AVD_UP(cb)){
-   LOG_IN("AVD is not up yet");
-   return NCSCC_RC_FAILURE;
-   }
-
+   /* Correct the counters first. */
info = >info.avd->msg_info.d2n_role_change_info;
 
TRACE("MsgId: %u,NodeId:%u, role rcvd:%u role present:%u",\
@@ -1524,6 +1519,12 @@ uint32_t avnd_evt_avd_role_change_evh(AV
avnd_msgid_assert(info->msg_id);
cb->rcv_msg_id = info->msg_id;
 
+   /* dont process unless AvD is up */
+   if (!m_AVND_CB_IS_AVD_UP(cb)){
+   LOG_IN("AVD is not up yet");
+   return NCSCC_RC_FAILURE;
+   }
+
prev_ha_state = cb->avail_state_avnd;
 
/* Ignore the duplicate roles. */

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] SMF: problem with suspend

[Neelakanta Reddy]

Hi Alex,

What problem has been observed, you mean say the campaign suspend is not 
happening after #2145 and #2144 when the component restart is found at 
the time of last step?

Thanks,
Neel.

On 2017/03/03 11:58 PM, Alex Jones wrote:
> Hi Guys,
>
>I've created ticket 2332 for a problem that I'm seeing. I'd like to
> remove some code in SmfProcState.cc, but there's a comment there that I
> don't understand.
>
>Can any of you explain the comments about "We don't want to be able to
> suspend between ..."? I can't figure out why we can't do this.
>
>I've attached the proposed diff.
>
> Alex


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

[devel] [PATCH 2 of 2] mdstest: handle memory leak [#1860]

[Hoang Vo]

 src/mds/apitest/mdstipc.h  |3 +-
 src/mds/apitest/mdstipc_api.c  |  288 
 src/mds/apitest/mdstipc_conf.c |   42 ++---
 3 files changed, 163 insertions(+), 170 deletions(-)


mdstest leak in many cases because of:
- incorrect use of input param
- wrong test sequence (cacel subscription after uninstall)
- malloc then terminate thread (cannot reach free)
- missing free on receiving message (used global pointer)
- encode wrong message length

action: fix above cases

diff --git a/src/mds/apitest/mdstipc.h b/src/mds/apitest/mdstipc.h
--- a/src/mds/apitest/mdstipc.h
+++ b/src/mds/apitest/mdstipc.h
@@ -1,6 +1,7 @@
 /*  OpenSAF
  *
  * (C) Copyright 2008 The OpenSAF Foundation
+ * Copyright Ericsson AB 2017 - All Rights Reserved.
  *
  * This program is distributed in the hope that it will be useful, but
  * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
@@ -206,7 +207,7 @@ uint32_t destroy_pwe_on_vdest(MDS_HDL);
 
 /** USER DEFINED WRAPPERS FOR MDS SERVICE APIs **/
 
-uint32_t tet_create_task(NCS_OS_CB ,NCSCONTEXT );
+uint32_t tet_create_task(NCS_OS_CB ,NCSCONTEXT *);
 uint32_t tet_release_task(void *task_handle);
 int is_adest_sel_obj_found(int );
 int is_sel_obj_found(int);
diff --git a/src/mds/apitest/mdstipc_api.c b/src/mds/apitest/mdstipc_api.c
--- a/src/mds/apitest/mdstipc_api.c
+++ b/src/mds/apitest/mdstipc_api.c
@@ -395,7 +395,7 @@ void  tet_svc_install_tp_10()
   printf("\nTest case 10:Installing the External MIN service EXTMIN in a 
seperate thread and Uninstalling it here\n");
   //Install thread
   rc = tet_create_task((NCS_OS_CB)tet_vdest_install_thread,
-   gl_tet_vdest[0].svc[0].task.t_handle);
+   _tet_vdest[0].svc[0].task.t_handle);
   if (rc !=  NCSCC_RC_SUCCESS) {
 printf("\nFail to Install thread\n");
 FAIL = 1;
@@ -403,9 +403,8 @@ void  tet_svc_install_tp_10()
 
   //Now Release the Install Thread
   rc = tet_release_task(gl_tet_vdest[0].svc[0].task.t_handle);
-  if (rc !=  NCSCC_RC_SUCCESS) {
-printf("\nFail to release thread\n");
-FAIL = 1;
+  if (rc ==  NCSCC_RC_SUCCESS) {
+printf("\nTask released\n");
   }
 
   //Counter shall be != 0
@@ -843,7 +842,7 @@ void  tet_svc_install_tp_17()
 void tet_vdest_uninstall_thread()
 {
   // Inside Thread
-  printf("tet_vdest_uninstall_thread\n");
+  printf("\ntet_vdest_uninstall_thread\n");
   test_validate(mds_service_uninstall(gl_tet_vdest[0].mds_pwe1_hdl,500), 
NCSCC_RC_SUCCESS);
 }
@@ -1009,7 +1008,7 @@ void tet_svc_unstall_tp_5()
   //Uninstalling the above service in a seperate thread
   //Uninstall thread
   rc = tet_create_task((NCS_OS_CB)tet_vdest_uninstall_thread,
-   gl_tet_vdest[0].svc[0].task.t_handle);
+   _tet_vdest[0].svc[0].task.t_handle);
   if (rc !=  NCSCC_RC_SUCCESS) {
 printf("\nFail to create the uninstall thread\n");
 FAIL = 1;
@@ -1018,8 +1017,8 @@ void tet_svc_unstall_tp_5()
 
   //Now Release the Uninstall Thread
   rc = tet_release_task(gl_tet_vdest[0].svc[0].task.t_handle);
-  if (rc !=  NCSCC_RC_SUCCESS) {
-printf("\nFail to release the uninstall thread\n");
+  if (rc ==  NCSCC_RC_SUCCESS) {
+printf("\nTask released\n");
 FAIL = 1;
   }
 
@@ -1833,16 +1832,6 @@ void tet_svc_subscr_VDEST_10()
 FAIL = 1;
   }
 
-  printf("\tUninstalling 600 and 700\n");
-  for(id=600;id<=700;id=id+100)
-  {
-if(  
mds_service_uninstall(gl_tet_vdest[0].mds_pwe1_hdl,id)!=NCSCC_RC_SUCCESS)
-{
-  printf("\nFail to uninstall service %d\n", id);
-  FAIL = 1;
-}
-  }
-
   //Cancelling the subscription
   if(mds_service_cancel_subscription(gl_tet_adest.mds_pwe1_hdl,500,2,
  svcids)!=NCSCC_RC_SUCCESS)
@@ -1850,6 +1839,17 @@ void tet_svc_subscr_VDEST_10()
 printf("\nFail cancel subscription 500\n");
 FAIL = 1;
   }
+
+  printf("\tUninstalling 600 and 700\n");
+  for(id=600;id<=700;id=id+100)
+  {
+if(  
mds_service_uninstall(gl_tet_vdest[0].mds_pwe1_hdl,id)!=NCSCC_RC_SUCCESS)
+{
+  printf("\nFail to uninstall service %d\n", id);
+  FAIL = 1;
+}
+  }
+
   if(  mds_service_uninstall(gl_tet_adest.mds_pwe1_hdl,500)!=NCSCC_RC_SUCCESS)
   {
 printf("\nFail to uninstall service 500\n");
@@ -2123,17 +2123,6 @@ void tet_svc_subscr_VDEST_12()
 FAIL=1;
   }
 
-  printf("\nAction: Uninstalling 600 \n");
-  for(i=0; i<=1;i++)
-  {
-if(  
mds_service_uninstall(gl_tet_vdest[i].mds_pwe1_hdl,600)!=NCSCC_RC_SUCCESS)
-
-{
-  printf("\nFail\n");
-  FAIL=1;
-}
-  } 
-
   printf("\nAction: Cancelling the subscription\n");
   if(mds_service_cancel_subscription(gl_tet_adest.mds_pwe1_hdl,500,1,
  svc_id_sixhd)!=NCSCC_RC_SUCCESS)
@@ -2141,6 +2130,17 @@ void tet_svc_subscr_VDEST_12()
 printf("\nFail\n");
 FAIL=1;
   }
+
+  printf("\nAction: Uninstalling 600 \n");
+  for(i=0; 

[devel] [PATCH 0 of 2] Review Request for mdstest: handle memory leak [#1860]

[Hoang Vo]

Summary: mdstest: handle memory leak [#1860]
Review request for Trac Ticket(s): #1870
Peer Reviewer(s): mahesh.va...@oracle.com; zoran.milinko...@ericsson.com
Pull request to: mahesh.va...@oracle.com
Affected branch(es): default
Development branch: default


Impacted area   Impact y/n

 Docsn
 Build systemn
 RPM/packaging   n
 Configuration files n
 Startup scripts n
 SAF servicesy
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   y
 Other   n


Comments (indicate scope for each "y" above):
-

changeset 9a1f61672dd538472bf0c1340011467a35f83a23
Author: Hoang Vo 
Date:   Mon, 06 Mar 2017 14:52:06 +0700

mds: handle memory leak [#1860]

Some error handling does not clean internal memory. Error handling in
dirrect send case clear user memory seem inconsistence, mds should let
creater manage its memory in error cases.

action: implement as proposed.

changeset 1efa643eb496a2938d1ddfecac6e91aa4a1cda88
Author: Hoang Vo 
Date:   Mon, 06 Mar 2017 14:52:08 +0700

mdstest: handle memory leak [#1860]

mdstest leak in many cases because of:
- incorrect use of input param
- wrong test sequence (cacel subscription after uninstall)
- malloc then terminate thread (cannot reach free)
- missing free on receiving message (used global pointer)
- encode wrong message length

action: fix above cases


Complete diffstat:
--
 src/base/sysf_mem.c|3 +
 src/mds/apitest/mdstipc.h  |3 +-
 src/mds/apitest/mdstipc_api.c  |  288 
---
 src/mds/apitest/mdstipc_conf.c |   42 ++---
 src/mds/mds_c_sndrcv.c |   34 +++-
 5 files changed, 181 insertions(+), 189 deletions(-)


Testing Commands:
-
G_SLICE=always-malloc G_DEBUG=gc-friendly  valgrind -v --tool=memcheck 
--leak-check=full --num-callers=40 --log-file=valgrind.log mdstest

Testing, Expected Results:
--
No definitely and indirectly lost report in valgrind.log

Conditions of Submission:
-
ACK from maintainer

Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  y  y
powerpc n  n
powerpc64   n  n


Reviewer Checklist:
---
[Submitters: make sure that your review doesn't trigger any checkmarks!]


Your checkin has not passed review because (see checked entries):

___ Your RR template is generally incomplete; it has too many blank entries
that need proper data filled in.

___ You have failed to nominate the proper persons for review and push.

___ Your patches do not have proper short+long header

___ You have grammar/spelling in your header that is unacceptable.

___ You have exceeded a sensible line length in your headers/comments/text.

___ You have failed to put in a proper Trac Ticket # into your commits.

___ You have incorrectly put/left internal data in your comments/files
(i.e. internal bug tracking tool IDs, product names etc)

___ You have not given any evidence of testing beyond basic build tests.
Demonstrate some level of runtime or other sanity testing.

___ You have ^M present in some of your files. These have to be removed.

___ You have needlessly changed whitespace or added whitespace crimes
like trailing spaces, or spaces before tabs.

___ You have mixed real technical changes with whitespace and other
cosmetic code cleanup changes. These have to be separate commits.

___ You need to refactor your submission into logical chunks; there is
too much content into a single commit.

___ You have extraneous garbage in your review (merge commits etc)

___ You have giant attachments which should never have been sent;
Instead you should place your content in a public tree to be pulled.

___ You have too many commits attached to an e-mail; resend as threaded
commits, or place in a public tree for a pull.

___ You have resent this content multiple times without a clear indication
of what has changed between each re-send.

___ You have failed to adequately and individually address all of the
comments and change requests that were proposed in the initial review.

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

___ Your computer have a badly configured date and time; confusing the
the threaded patch review.

___ Your changes affect IPC mechanism, and you don't present any results

[devel] [PATCH 1 of 2] mds: handle memory leak [#1860]

[Hoang Vo]

 src/base/sysf_mem.c|   3 +++
 src/mds/mds_c_sndrcv.c |  34 +++---
 2 files changed, 18 insertions(+), 19 deletions(-)


Some error handling does not clean internal memory.
Error handling in dirrect send case clear user memory seem inconsistence,
mds should let creater manage its memory in error cases.

action: implement as proposed.

diff --git a/src/base/sysf_mem.c b/src/base/sysf_mem.c
--- a/src/base/sysf_mem.c
+++ b/src/base/sysf_mem.c
@@ -1,6 +1,7 @@
 /*  -*- OpenSAF  -*-
  *
  * (C) Copyright 2008 The OpenSAF Foundation
+ * Copyright Ericsson AB 2017 - All Rights Reserved.
  *
  * This program is distributed in the hope that it will be useful, but
  * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
@@ -428,6 +429,8 @@ USRBUF *sysf_alloc_pkt(unsigned char poo
if (pool_id >= UB_MAX_POOLS) {
m_PMGR_UNLK(_ub_pool_mgr.lock);
m_LEAP_DBG_SINK_VOID;
+   m_NCS_MEM_FREE(ub, NCS_MEM_REGION_IO_DATA_HDR, 
NCS_SERVICE_ID_OS_SVCS, 2);
+   ub = (USRBUF *)0;
return NULL;
}
ud = (USRDATA 
*)gl_ub_pool_mgr.pools[pool_id].mem_alloc(sizeof(USRDATA), pool_id, priority);
diff --git a/src/mds/mds_c_sndrcv.c b/src/mds/mds_c_sndrcv.c
--- a/src/mds/mds_c_sndrcv.c
+++ b/src/mds/mds_c_sndrcv.c
@@ -1,6 +1,7 @@
 /*  -*- OpenSAF  -*-
  *
  * (C) Copyright 2008 The OpenSAF Foundation
+ * Copyright Ericsson AB 2017 - All Rights Reserved.
  *
  * This program is distributed in the hope that it will be useful, but
  * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
@@ -420,10 +421,6 @@ static uint32_t mds_mcm_direct_send(NCSM
memset(, 0, sizeof(req));
if ((info->info.svc_direct_send.i_priority < MDS_SEND_PRIORITY_LOW) ||
(info->info.svc_direct_send.i_priority > 
MDS_SEND_PRIORITY_VERY_HIGH)) {
-   if (info->info.svc_direct_send.i_direct_buff != NULL) {
-   
m_MDS_FREE_DIRECT_BUFF(info->info.svc_direct_send.i_direct_buff);
-   info->info.svc_direct_send.i_direct_buff = NULL;
-   }
m_MDS_LOG_ERR("MDS_SND_RCV: Priority defined is not in 
range\n");
return NCSCC_RC_FAILURE;
}
@@ -432,13 +429,11 @@ static uint32_t mds_mcm_direct_send(NCSM
m_MDS_LOG_ERR("MDS_SND_RCV: Send Message Direct Buff is 
NULL\n");
return NCSCC_RC_FAILURE;
} else if (info->info.svc_direct_send.i_direct_buff_len > 
MDS_DIRECT_BUF_MAXSIZE) {
-   mds_free_direct_buff(info->info.svc_direct_send.i_direct_buff);
m_MDS_LOG_ERR("MDS_SND_RCV: Send Message Direct Buff Len is 
greater than SEND SIZE\n");
return NCSCC_RC_FAILURE;
}
 
if ((info->info.svc_direct_send.i_to_svc == 0) || (info->i_svc_id == 
0)) {
-   
m_MDS_FREE_DIRECT_BUFF(info->info.svc_direct_send.i_direct_buff);
m_MDS_LOG_ERR("MDS_SND_RCV: Source or Dest service provided is 
Null, src svc_id = %s(%d), dest svc_id = %s(%d) \n",
  get_svc_names(info->i_svc_id), info->i_svc_id, 
get_svc_names(info->info.svc_direct_send.i_to_svc), 
info->info.svc_direct_send.i_to_svc);
return NCSCC_RC_FAILURE;
@@ -633,11 +628,6 @@ static uint32_t mds_mcm_direct_send(NCSM
status = NCSCC_RC_FAILURE;
break;
}
-   if (status == MDS_INT_RC_DIRECT_SEND_FAIL) {
-   /* Free the MDS Direct Buff */
-   
m_MDS_FREE_DIRECT_BUFF(info->info.svc_direct_send.i_direct_buff);
-   status = NCSCC_RC_FAILURE;
-   }
return status;
 }
 
@@ -2014,6 +2004,7 @@ static uint32_t mcm_process_await_active
   return Sucess; */
 
MDTM_SEND_REQ req;
+   uint32_t rc = NCSCC_RC_SUCCESS;
 
NCSMDS_CALLBACK_INFO cbinfo;
MDS_BCAST_BUFF_LIST *bcast_ptr = NULL;
@@ -2022,9 +2013,6 @@ static uint32_t mcm_process_await_active
 
if (svc_cb->i_fail_no_active_sends) {
m_MDS_LOG_ERR("MDS_SND_RCV: Returning in noactive state as the 
option is not to buffer the msgs");
-   if (to_msg->msg_type == MSG_DIRECT_BUFF) {
-   m_MDS_FREE_DIRECT_BUFF(to_msg->data.info.buff);
-   }
return MDS_RC_MSG_NO_BUFFERING;
}
 
@@ -2071,7 +2059,8 @@ static uint32_t mcm_process_await_active
if (status != NCSCC_RC_SUCCESS) {
m_MDS_LOG_ERR("MDS_SND_RCV: CALLBACK ENC failed 
for svc_id = %s(%d)\n", 
get_svc_names(svc_cb->svc_id), svc_cb->svc_id);
-   return NCSCC_RC_FAILURE;
+   rc = NCSCC_RC_FAILURE;
+   goto free_mem;
}
 
if