Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

sync_repl: when completing an operation in the pending list, it can select the wrong operation #4526

Closed
tbordaz opened this issue Jan 11, 2021 · 1 comment
Closed

sync_repl: when completing an operation in the pending list, it can select the wrong operation #4526

tbordaz opened this issue Jan 11, 2021 · 1 comment
Assignees
@tbordaz
Milestone
1.4.3

Comments

@tbordaz
Copy link
Contributor

tbordaz commented Jan 11, 2021

Issue Description
With nested operations, a primary operation can trigger multiple nested operation. The pending list manages the list of nested operation. Each operation being identified in the pending list with the operation data structure. A problem with postop operation is that the same operation data structure can exist in the pending list. It can select the wrong one. In such case the pending list is never completed and flush to the sync_repl thread.

Package Version and Platform:
all versions

Steps to Reproduce
Difficult to reproduce. Sometime (1 out of 10) reproduced with IPA DNSSEC.

Expected results
A pending list should complete and DNSSEC tests should not fail
@tbordaz tbordaz added the needs triage The issue will be triaged during scrum label Jan 11, 2021
@mreynolds389 mreynolds389 removed the needs triage The issue will be triaged during scrum label Jan 14, 2021
@mreynolds389 mreynolds389 added this to the 1.4.3 milestone Jan 14, 2021
@tbordaz tbordaz mentioned this issue Jan 19, 2021
Merged
tbordaz added a commit to tbordaz/389-ds-base that referenced this issue Jan 27, 2021
@tbordaz
Issue 4526 - sync_repl: when completing an operation in the pending l…
e976bb1 
…ist, it can select the wrong operation

Bug description:
	When an operation complete, it was retrieved in the pending list with
	the address of the Operation structure. In case of POST OP nested operations
	the same address can be reused. So when completing an operation there could be
	a confusion which operation actually completed.
	A second problem is that if an update its DB_DEADLOCK, the BETXN_PREOP can
	be called several times. During retry, the operation is already in the pending
	list.

Fix description:
	The fix defines a new operation extension (sync_persist_extension_type).
	This operation extension contains an index (idx_pl) of the op_pl in the
	the pending list.

	And additional safety fix is to dump the pending list in case it becomes large (>10).
	The pending list is dumped with SLAPI_LOG_PLUGIN.

	When there is a retry (operation extension exists) the call to sync_update_persist_betxn_pre_op
	becomes a NOOP: the operation is not added again in the pending list.

relates: 389ds#4526

Reviewed by: William Brown (Thanks !!)

Platforms tested: F31 & F33
tbordaz added a commit that referenced this issue Jan 27, 2021
@tbordaz
Issue 4526 - sync_repl: when completing an operation in the pending l…
ba0e91b 
…ist, it can select the wrong operation (#4553)

Bug description:
	When an operation complete, it was retrieved in the pending list with
	the address of the Operation structure. In case of POST OP nested operations
	the same address can be reused. So when completing an operation there could be
	a confusion which operation actually completed.
	A second problem is that if an update its DB_DEADLOCK, the BETXN_PREOP can
	be called several times. During retry, the operation is already in the pending
	list.

Fix description:
	The fix defines a new operation extension (sync_persist_extension_type).
	This operation extension contains an index (idx_pl) of the op_pl in the
	the pending list.

	And additional safety fix is to dump the pending list in case it becomes large (>10).
	The pending list is dumped with SLAPI_LOG_PLUGIN.

	When there is a retry (operation extension exists) the call to sync_update_persist_betxn_pre_op
	becomes a NOOP: the operation is not added again in the pending list.

relates: #4526

Reviewed by: William Brown (Thanks !!)

Platforms tested: F31 & F33
tbordaz added a commit that referenced this issue Jan 27, 2021
@tbordaz
Issue 4526 - sync_repl: when completing an operation in the pending l…
9f9eb91 
…ist, it can select the wrong operation (#4553)

Bug description:
	When an operation complete, it was retrieved in the pending list with
	the address of the Operation structure. In case of POST OP nested operations
	the same address can be reused. So when completing an operation there could be
	a confusion which operation actually completed.
	A second problem is that if an update its DB_DEADLOCK, the BETXN_PREOP can
	be called several times. During retry, the operation is already in the pending
	list.

Fix description:
	The fix defines a new operation extension (sync_persist_extension_type).
	This operation extension contains an index (idx_pl) of the op_pl in the
	the pending list.

	And additional safety fix is to dump the pending list in case it becomes large (>10).
	The pending list is dumped with SLAPI_LOG_PLUGIN.

	When there is a retry (operation extension exists) the call to sync_update_persist_betxn_pre_op
	becomes a NOOP: the operation is not added again in the pending list.

relates: #4526

Reviewed by: William Brown (Thanks !!)

Platforms tested: F31 & F33
tbordaz added a commit that referenced this issue Jan 27, 2021
@tbordaz
Issue 4526 - sync_repl: when completing an operation in the pending l…
263a87b 
…ist, it can select the wrong operation (#4553)

Bug description:
	When an operation complete, it was retrieved in the pending list with
	the address of the Operation structure. In case of POST OP nested operations
	the same address can be reused. So when completing an operation there could be
	a confusion which operation actually completed.
	A second problem is that if an update its DB_DEADLOCK, the BETXN_PREOP can
	be called several times. During retry, the operation is already in the pending
	list.

Fix description:
	The fix defines a new operation extension (sync_persist_extension_type).
	This operation extension contains an index (idx_pl) of the op_pl in the
	the pending list.

	And additional safety fix is to dump the pending list in case it becomes large (>10).
	The pending list is dumped with SLAPI_LOG_PLUGIN.

	When there is a retry (operation extension exists) the call to sync_update_persist_betxn_pre_op
	becomes a NOOP: the operation is not added again in the pending list.

relates: #4526

Reviewed by: William Brown (Thanks !!)
@tbordaz
Copy link
Contributor Author

tbordaz commented Jan 27, 2021

abb9324..ba0e91b master
96edca8..9f9eb91 389-ds-base-1.4.4
fc16302..263a87b 389-ds-base-1.4.3

@tbordaz tbordaz self-assigned this Jan 27, 2021
@tbordaz tbordaz closed this as completed Jan 27, 2021
@tbordaz tbordaz mentioned this issue Feb 22, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@tbordaz tbordaz

Labels
None yet
Projects
None yet
Milestone
1.4.3
Development

No branches or pull requests
2 participants
@mreynolds389 @tbordaz