[devel] [PATCH 1 of 1] amfnd : fix nodeswitchover when faulted SU has saAmfSUFailover enabled [#729]
osaf/services/saf/amf/amfnd/clc.cc | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
In case of sufailover, AMFND disables failed component and SU. Also it calls
cleanup up scripts of all
components. When AMFND receives successful response for all the components, it
informs AMFD for sufailover. In case of nodeswitchover also if the failed
SU has sufailover flag enabled, this particular SU should be recovered
with sufailover policy.
In this issue, nodeswitchover is happening for a SU with saAmfSUFailover
enabled and the SU has both PI comps
and NPI comps. When switchover is escalated, AMFND performs cleanup of
components in the failed SU.
Problem occurs when AMFND gets cleanup success event for npi component. AMFND
is enabling the SU and trying to
access the csi. Since AMFND deletes all the SUSI record, it asserts. The
problem is not observed when for NPI
SU or for a PI SU with only PI components.
The patch includes a check to keep the SU disabled when sufailover is happening
in nodeswitchover context.
diff --git a/osaf/services/saf/amf/amfnd/clc.cc
b/osaf/services/saf/amf/amfnd/clc.cc
--- a/osaf/services/saf/amf/amfnd/clc.cc
+++ b/osaf/services/saf/amf/amfnd/clc.cc
@@ -1064,8 +1064,12 @@ uint32_t avnd_comp_clc_st_chng_prc(AVND_
goto done;
m_AVND_SEND_CKPT_UPDT_ASYNC_UPDT(cb, comp,
AVND_CKPT_COMP_OPER_STATE);
- if (sufailover_in_progress(comp->su)) {
- /*Do not reset any flag, this will be done as a
part of repair.*/
+ if (sufailover_in_progress(comp->su) ||
(sufailover_during_nodeswitchover(comp->su))) {
+ /* Do not reset any flag during:
+ -sufailover.
+ -nodeswitchover when faulted su has
sufailover flag enabled.
+ Reset of all flags will be done as a part of
repair.
+*/
}
else {
if (!m_AVND_COMP_IS_FAILED(comp)) {
@@ -1266,7 +1270,11 @@ uint32_t avnd_comp_clc_st_chng_prc(AVND_
ev = AVND_SU_PRES_FSM_EV_COMP_TERM_FAIL;
else if ((SA_AMF_PRESENCE_TERMINATING == final_st) &&
(comp->su->pres == SA_AMF_PRESENCE_RESTARTING))
ev = AVND_SU_PRES_FSM_EV_COMP_TERMINATING;
- else if (sufailover_in_progress(comp->su) &&
(SA_AMF_PRESENCE_UNINSTANTIATED == final_st))
+ else if ((sufailover_in_progress(comp->su) ||
sufailover_during_nodeswitchover(comp->su)) &&
+ (SA_AMF_PRESENCE_UNINSTANTIATED == final_st))
+ /* If sufailover flag is enabled, then SU FSM needs to
be triggered in both sufailover
+ and nodeswitchover escalation.
+*/
ev = AVND_SU_PRES_FSM_EV_COMP_UNINSTANTIATED;
}
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
___
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 : fix nodeswitchover when faulted SU has saAmfSUFailover enabled [#729]
Summary: amfnd : fix nodeswitchover when faulted SU has saAmfSUFailover enabled [#729] Review request for Trac Ticket(s): #729 Peer Reviewer(s): Hans F., Hans N., Nagendra Pull request to: <> Affected branch(es): Default and 4.4 Development branch: <> 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): - Please see commit log below. changeset 9efa8816946630a451b8c1edb07c52bb977e673c Author: praveen.malv...@oracle.com Date: Tue, 18 Feb 2014 12:12:28 +0530 amfnd : fix nodeswitchover when faulted SU has saAmfSUFailover enabled [#729] In case of sufailover, AMFND disables failed component and SU. Also it calls cleanup up scripts of all components. When AMFND receives successful response for all the components, it informs AMFD for sufailover. In case of nodeswitchover also if the failed SU has sufailover flag enabled, this particular SU should be recovered with sufailover policy. In this issue, nodeswitchover is happening for a SU with saAmfSUFailover enabled and the SU has both PI comps and NPI comps. When switchover is escalated, AMFND performs cleanup of components in the failed SU. Problem occurs when AMFND gets cleanup success event for npi component. AMFND is enabling the SU and trying to access the csi. Since AMFND deletes all the SUSI record, it asserts. The problem is not observed when for NPI SU or for a PI SU with only PI components. The patch includes a check to keep the SU disabled when sufailover is happening in nodeswitchover context. Complete diffstat: -- osaf/services/saf/amf/amfnd/clc.cc | 14 +++--- 1 files changed, 11 insertions(+), 3 deletions(-) Testing Commands: - Tested as per ticket description. Testing, Expected Results: -- No assert observed. Conditions of Submission: - Ack from any reviewer. 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 u
Re: [devel] [PATCH 1 of 1] amfnd: report failover after comp cleanup [#598]
Hi,
Testing this patch for PI SUs.
The patch works fine for component failover for PI SUs.
But in case recovery policy is configured as nodeswitchover, the patch
causes reboot of node before the removal of assignments. Thus repair is
being done before the recovery.
This happens because in node switchover escalation cleanup script is
invoked. When cleanup up is done successfully, AMFND informs AMFD for
component failover assuming it to be component failover. This should not
be done in node switchover case.
Below is the modification in if condition needed to fix it. Here oper
state of avnd is also checked to differentiate between nodeswitchover
and component
failover:
/* determine if this is a case of component failover */
if (m_AVND_COMP_IS_FAILED(comp) && m_AVND_SU_IS_FAILED(su) &&
m_AVND_SU_IS_PREINSTANTIABLE(su) &&
(su->sufailover == false) &&
(avnd_cb->oper_state !=
SA_AMF_OPERATIONAL_DISABLED) ) {
/* yes, request director to orchestrate component
failover */
rc = avnd_di_oper_send(cb, su, SA_AMF_COMPONENT_FAILOVER);
}
Will test with NPI SUs.
Thanks,
Praveen
On 14-Feb-14 6:43 PM, Hans Feldt wrote:
> osaf/services/saf/amf/amfnd/clc.cc| 9 +
> osaf/services/saf/amf/amfnd/di.cc | 2 +-
> osaf/services/saf/amf/amfnd/err.cc| 9 +
> osaf/services/saf/amf/amfnd/include/avnd_di.h | 2 +-
> 4 files changed, 16 insertions(+), 6 deletions(-)
>
>
> If a component error is detected and the recovery action is
> COMPONENT_FAILOVER,
> it is possible that a standby component gets the active assignment before the
> erroneous component has been terminated. This can cause a split brain on
> application level.
>
> The reason for this is that when the error is detected amfnd starts two
> parallel activities, component cleanup and inform director. When the director
> receives the information it starts the process of failing over the workload
> of the erroneous component.
>
> This patch informs the director after successful termination has been
> performed.
>
> diff --git a/osaf/services/saf/amf/amfnd/clc.cc
> b/osaf/services/saf/amf/amfnd/clc.cc
> --- a/osaf/services/saf/amf/amfnd/clc.cc
> +++ b/osaf/services/saf/amf/amfnd/clc.cc
> @@ -2024,6 +2024,7 @@ uint32_t avnd_comp_clc_terming_termfail_
>
> **/
> uint32_t avnd_comp_clc_terming_cleansucc_hdler(AVND_CB *cb, AVND_COMP *comp)
> {
> + const AVND_SU *su = comp->su;
> uint32_t rc = NCSCC_RC_SUCCESS;
> TRACE_ENTER2("'%s': Cleanup success event in the terminating state",
> comp->name.value);
>
> @@ -2074,6 +2075,14 @@ uint32_t avnd_comp_clc_terming_cleansucc
> m_AVND_COMP_REG_PARAM_RESET(cb, comp);
> m_AVND_SEND_CKPT_UPDT_ASYNC_UPDT(cb, comp,
> AVND_CKPT_COMP_CONFIG);
> }
> +
> + /* determine if this is a case of component failover */
> + if (m_AVND_COMP_IS_FAILED(comp) && m_AVND_SU_IS_FAILED(su) &&
> + m_AVND_SU_IS_PREINSTANTIABLE(su) && (su->sufailover ==
> false)) {
> + /* yes, request director to orchestrate component failover */
> + rc = avnd_di_oper_send(cb, su, SA_AMF_COMPONENT_FAILOVER);
> + }
> +
> TRACE_LEAVE();
> return rc;
> }
> diff --git a/osaf/services/saf/amf/amfnd/di.cc
> b/osaf/services/saf/amf/amfnd/di.cc
> --- a/osaf/services/saf/amf/amfnd/di.cc
> +++ b/osaf/services/saf/amf/amfnd/di.cc
> @@ -476,7 +476,7 @@ uint32_t avnd_evt_mds_avd_dn_evh(AVND_CB
>
> Notes : None.
>
> **/
> -uint32_t avnd_di_oper_send(AVND_CB *cb, AVND_SU *su, uint32_t rcvr)
> +uint32_t avnd_di_oper_send(AVND_CB *cb, const AVND_SU *su, uint32_t rcvr)
> {
> AVND_MSG msg;
> uint32_t rc = NCSCC_RC_SUCCESS;
> diff --git a/osaf/services/saf/amf/amfnd/err.cc
> b/osaf/services/saf/amf/amfnd/err.cc
> --- a/osaf/services/saf/amf/amfnd/err.cc
> +++ b/osaf/services/saf/amf/amfnd/err.cc
> @@ -702,9 +702,6 @@ uint32_t avnd_err_rcvr_comp_failover(AVN
> m_AVND_SU_OPER_STATE_SET(su, SA_AMF_OPERATIONAL_DISABLED);
> m_AVND_SEND_CKPT_UPDT_ASYNC_UPDT(cb, su, AVND_CKPT_SU_OPER_STATE);
>
> - /* inform AvD */
> - rc = avnd_di_oper_send(cb, su, SA_AMF_COMPONENT_FAILOVER);
> -
> /*
>* su-sis may be in assigning/removing state. signal csi
>* assign/remove done so that su-si assignment/removal algo can proceed.
> @@ -722,11 +719,15 @@ uint32_t avnd_err_rcvr_comp_failover(AVN
> if (NCSCC_RC_SUCCESS != rc)
> goto done;
>
> - /* clean the failed comp */
> + // TODO: there should be no difference between PI/NPI comps
> if (m_AVND_SU_IS_PREINSTANTIABLE(su)) {
> + /* clean the failed comp */
> rc = avnd_comp_clc_fsm_ru
[devel] [PATCH 0 of 1] Review Request for osaf: Update the commit message template [#791]
Summary: osaf: Update the commit message template [#791] Review request for Trac Ticket(s): 791 Peer Reviewer(s): TLC Pull request to: Affected branch(es): opensaf-4.2.x, opensaf-4.3.x, opensaf-4.4.x, default(4.5) 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 n Other y Comments (indicate scope for each "y" above): - changeset 27485a5e44ed4fbc542f24ecc11a6c97df9c5bc8 Author: Anders Widell Date: Mon, 17 Feb 2014 17:40:30 +0100 osaf: Update the commit message template [#791] Update the commit message template with the agreeed format for how to write commit messages in OpenSAF. Add a shell script that can be used to set the default commit message in Mercurial to the commit message template. Complete diffstat: -- tools/devel/review/00-README | 77 + tools/devel/review/commit.template | 51 ++- tools/devel/review/hgeditor.sh | 32 3 files changed, 91 insertions(+), 69 deletions(-) Testing Commands: - Execute the commands listed in tools/devel/review/00-README for setting the default commit message in Mercurial. Test it by running e.g. hg commit Testing, Expected Results: -- Default commit message in Mercurial should be the commit message template. Conditions of Submission: - Ack from TLC 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. -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk ___ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/o
[devel] [PATCH 1 of 1] osaf: Update the commit message template [#791]
tools/devel/review/00-README | 77 ++--- tools/devel/review/commit.template | 51 ++-- tools/devel/review/hgeditor.sh | 32 +++ 3 files changed, 91 insertions(+), 69 deletions(-) Update the commit message template with the agreeed format for how to write commit messages in OpenSAF. Add a shell script that can be used to set the default commit message in Mercurial to the commit message template. diff --git a/tools/devel/review/00-README b/tools/devel/review/00-README --- a/tools/devel/review/00-README +++ b/tools/devel/review/00-README @@ -1,79 +1,24 @@ Commit Message Format = -The patch review process heavily relies on properly formatted commit message. -This section will describe how commit message should be formatted and the -relation it has with the patch review process by email. - -A commit message should comply to the following template: - -* First line : 80-chars long one line short description (#ticket). Describe what -the patch is doing logically (not the bug description) -* Second line : Blank -* Third line+ : 80-chars long lines for a more complete description - --<-<-<-<-<- -example: this is a one line short description (#2000) - -This is a more elaborate description that explains your changes and the -original problem and how it got solved. - - * Blah - * Blah - -Signed-off-by: John Doe --<-<-<-<-<- - -The first line will be grabbed by the 'hg email' command and added as the -subject of the patch, hence the why it should be short and precise. Note that it -also contains the "area/module/feature" of the changes (i.e. example:). If you -have trouble identifying the unique nature of the patch, your patch is probably -way to long and should be divided in a series. - -The Ticket # in a future integration will be used on the Trac web interface to -correlate tickets and commits. It will also be used by Mercurial hooks to -close/fix tickets automatically if needed. - -The long description gives more details about the patch/changeset. - -The SOB tag is the original patch author. - +The patch review process heavily relies on properly formatted commit messages. +Use the file commit.template in this directory as a template when writing +commit messages. Make sure that your commit message contains all the necessary +parts, i.e. the component name, a short description, the ticket number and +a long description. Default Commit Message Template === -Apparently Mercurial lacks the support of customizing the default commit message -based on a template file somewhere in the repository. +Enter the following set of commands to set up the commit.template as the default +commit message in Mercurial (you need to log out and log in again for the change +to take effect): -The Qct extension can be installed and used in your ~/.hgrc profile to point to -a template file, so that you're nagged every time how to fill the commit -message properly ;) - -For instance under Red Hat/Fedora the package is called 'qct-mercurial' - - % yum install qct-mercurial - % yum install qct - -http://www.selenic.com/mercurial/wiki/index.cgi/QctExtension - -Under './tools/devel/review/commit.template', you'll find a default template that you -can use with the Qct extension. The extension automatically looks for a template -file under `hg root`/.commit.template, a copy is already placed in the OpenSAF -repository for developer that would like to use the Qct extension. - --<-<-<-<-<- -[extensions] -hgext.qct = - -[qct] -signoff = Signed-off-by: John Doe --<-<-<-<-<- - -To use the Qct Extension, you'll have to commit your changes using the 'hg -commit-tool | hg qct' command. The tool has neat features, like dynamically -deciding which files will be part of the current commit etc. But it might bug -some developers since it pops up a GUI. - +mkdir ~/bin +cp hgeditor.sh ~/bin +chmod 755 ~/bin/hgeditor.sh +echo "export HGEDITOR=~/bin/hgeditor.sh" >> ~/.bashrc +echo "setenv HGEDITOR ~/bin/hgeditor.sh" >> ~/.cshrc Mercurial Settings Needed for Email Review == diff --git a/tools/devel/review/commit.template b/tools/devel/review/commit.template --- a/tools/devel/review/commit.template +++ b/tools/devel/review/commit.template @@ -1,6 +1,47 @@ -module: this is a one line short description +component: short_description [#ticket_number] -Ticket #xxx (delete me if none) - -This is a more elaborate description that explains your changes and the -original problem and how it got solved. +long_description +HG: +HG: Enter commit message. Lines beginning with 'HG:' are removed. +HG: An empty message aborts the commit. +HG: +HG: Edit the different parts of the commit message template above as follows: +HG: +HG: component +HG: Concatenation of the "Com
Re: [devel] [PATCH 0 of 1] Review Request for IMM: Improved logging at CCB validation error [#669]
Hi AndersBj, Reviewed and tested the patch. Ack from me. /Neel. On Friday 14 February 2014 07:45 PM, Anders Bjornerstedt wrote: > Summary: IMM: Improved logging at CCB validation error [#669] > Review request for Trac Ticket(s): 669 > Peer Reviewer(s): Neel, (HansF as reporter) > Pull request to: > Affected branch(es): 4.2; 4.3; 4.4; default(4.5) > Development branch: > > > 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 87a45acdd97cfda3d6f3b54eecab083cea5d758e > Author: Anders Bjornerstedt > Date: Fri, 14 Feb 2014 15:03:27 +0100 > > IMM: Improved logging at CCB validation error [#669] > > > Complete diffstat: > -- > osaf/services/saf/immsv/immnd/ImmModel.cc | 12 +--- > 1 files changed, 5 insertions(+), 7 deletions(-) > > > Testing Commands: > - > I tested by: > > 1) Tweaking tests/immsv/implementer/applier.c > to set error string and return error in its completed-callback. > > 2) Installed the OpensafImmTest test-class. > 3) 'immpopulate -p 3 OpensafImmTest' to get a few instances. > 4) 'immapplier -a TEST-OI OpensafImmTest' to attach the test OI to the class. > 5) immcfg -m -a testInt32=1234 testRdn=0. > > > Testing, Expected Results: > -- > The CCB should get aborted with at least clearer messages to the syslog. > The error string will be deisplayed by immcfg (not really part of this test). > > > Conditions of Submission: > - > Ack from Neel. > > > > 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. > -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app i
Re: [devel] [PATCH 1 of 1] amfnd : avoid accessing csi_list in comp after removal of assignments [#739]
Ack Thanks -Nagu > -Original Message- > From: Praveen Malviya > Sent: 04 February 2014 16:07 > To: hans.nordeb...@ericsson.com; Nagendra Kumar; hans.fe...@ericsson.com > Cc: opensaf-devel@lists.sourceforge.net > Subject: [PATCH 1 of 1] amfnd : avoid accessing csi_list in comp after > removal of > assignments [#739] > > osaf/services/saf/amf/amfnd/comp.cc | 7 +++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > > When AMFND responds to AMFD for the completion of removal of assignments, > it deletes the SUSI and COMPCSI > records. Reported problem appears when a component receiving multiple CSIs > responds to AMFND for the removal > of assignments and AMFND responds to AMFD for the completion of > assignment. Since component has multiple > CSIs assigned to it, AMFND tries to again generate removal completion > indication and access csi_list in the > component which has no nodes in it. This leads to AMFND crash. > This patch assures that AMFND will not access csi_list in component after > deletion of comp_csi record. > > diff --git a/osaf/services/saf/amf/amfnd/comp.cc > b/osaf/services/saf/amf/amfnd/comp.cc > --- a/osaf/services/saf/amf/amfnd/comp.cc > +++ b/osaf/services/saf/amf/amfnd/comp.cc > @@ -1761,6 +1761,13 @@ uint32_t avnd_comp_csi_remove_done(AVND_ > break; > } > } > + > + /* When AMFND responds to AMFD for removal of > assignments for the SIs in the any SU, > +it also deletes all the SUSI and COMPCSI records. In > such a case component will > +not have any CSI in its csi_list. If removal is > completed > break the loop. > + */ > + if (comp->csi_list.n_nodes == 0) > + break; > } > > /* This is removal with TARGET_ALL. So if all CSIs in all SIs > of SU > are moved -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk ___ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
Re: [devel] [PATCH 1 of 1] amf: set comp oper state to enable when corresponding node is present [#324]
Ack.
Thanks
Praveen
On 17-Dec-13 4:05 PM, nagendr...@oracle.com wrote:
> osaf/services/saf/amf/amfd/comp.cc| 5 +
> osaf/services/saf/amf/amfd/ndfsm.cc | 7 +--
> osaf/services/saf/amf/amfnd/compdb.cc | 7 ++-
> 3 files changed, 12 insertions(+), 7 deletions(-)
>
>
> diff --git a/osaf/services/saf/amf/amfd/comp.cc
> b/osaf/services/saf/amf/amfd/comp.cc
> --- a/osaf/services/saf/amf/amfd/comp.cc
> +++ b/osaf/services/saf/amf/amfd/comp.cc
> @@ -225,6 +225,11 @@ static void comp_add_to_model(AVD_COMP *
> comp->su->saAmfSUPreInstantiable = static_cast(true);
> }
>
> + if ((comp->su->su_on_node->node_state == AVD_AVND_STATE_PRESENT) ||
> + (comp->su->su_on_node->node_state ==
> AVD_AVND_STATE_NO_CONFIG) ||
> + (comp->su->su_on_node->node_state ==
> AVD_AVND_STATE_NCS_INIT))
> + avd_comp_oper_state_set(comp, SA_AMF_OPERATIONAL_ENABLED);
> +
> /* Set runtime cached attributes. */
> avd_saImmOiRtObjectUpdate(&comp->su->name,
> const_cast("saAmfSUPreInstantiable"),
> SA_IMM_ATTR_SAUINT32T, &comp->su->saAmfSUPreInstantiable);
> diff --git a/osaf/services/saf/amf/amfd/ndfsm.cc
> b/osaf/services/saf/amf/amfd/ndfsm.cc
> --- a/osaf/services/saf/amf/amfd/ndfsm.cc
> +++ b/osaf/services/saf/amf/amfd/ndfsm.cc
> @@ -205,9 +205,12 @@ void avd_nd_ncs_su_assigned(AVD_CL_CB *c
> avd_node_oper_state_set(avnd, SA_AMF_OPERATIONAL_ENABLED);
>
> /* Make application SUs operational state ENABLED */
> - for (su = avnd->list_of_su; su != NULL; su =
> su->avnd_list_su_next)
> + for (su = avnd->list_of_su; su != NULL; su =
> su->avnd_list_su_next) {
> avd_su_oper_state_set(su, SA_AMF_OPERATIONAL_ENABLED);
> -
> + AVD_COMP *comp;
> + for (comp = su->list_of_comp; comp; comp =
> comp->su_comp_next)
> + avd_comp_oper_state_set(comp,
> SA_AMF_OPERATIONAL_ENABLED);
> + }
> /* We can now set the LEDS */
> avd_snd_set_leds_msg(cb, avnd);
>
> diff --git a/osaf/services/saf/amf/amfnd/compdb.cc
> b/osaf/services/saf/amf/amfnd/compdb.cc
> --- a/osaf/services/saf/amf/amfnd/compdb.cc
> +++ b/osaf/services/saf/amf/amfnd/compdb.cc
> @@ -1482,11 +1482,8 @@ static int comp_init(AVND_COMP *comp, co
> else
> cmd->timeout = comptype->saAmfCtDefClcCliTimeout;
> }
> -
> - if (m_AVND_COMP_TYPE_IS_PREINSTANTIABLE(comp))
> - m_AVND_COMP_OPER_STATE_SET(comp, SA_AMF_OPERATIONAL_DISABLED);
> - else
> - m_AVND_COMP_OPER_STATE_SET(comp, SA_AMF_OPERATIONAL_ENABLED);
> + /* Set oper status to enable irrespective of comp category PI or NPI. */
> + m_AVND_COMP_OPER_STATE_SET(comp, SA_AMF_OPERATIONAL_ENABLED);
>
> /* Remove any previous environment variables */
> if (comp->saAmfCompCmdEnv != NULL) {
--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
