Skip to content

Use shared_ptr for SSL context objects#3754

Merged
lizan merged 12 commits intoenvoyproxy:masterfrom
qiwzhang:shared_ctx_ptr
Jul 16, 2018
Merged

Use shared_ptr for SSL context objects#3754
lizan merged 12 commits intoenvoyproxy:masterfrom
qiwzhang:shared_ctx_ptr

Conversation

@qiwzhang
Copy link
Contributor

Description: This is one of PR to support dynamic secret for SDS. The master design is in this PR #3748.
This PR only changes Ssl context to use shared_ptr.

  1. ssl_socket is holding one ref_count of ctx;
  2. socketFactory is holding another ref_count, but this one can be updated if dynamic secret is changed.
    With shared_ptr, existing sockets still work since they are holding ref_count to the old ctx so it will not be deleted.

Risk Level: Low

Testing: all unit tests passed.

Docs Changes: None

Release Notes: None
[Optional Fixes #Issue]
[Optional Deprecated:]

@qiwzhang
Copy link
Contributor Author

@lizan @PiotrSikora Could you help to review it? Thanks.

@mattklein123
Copy link
Member

I thought we discussed changing the context directly with appropriate locking? Why do we need this? Will that not work?

@qiwzhang
Copy link
Contributor Author

Thanks for pointing that out, will try. Close this for now

@qiwzhang qiwzhang closed this Jun 28, 2018
@qiwzhang qiwzhang deleted the shared_ctx_ptr branch June 28, 2018 23:52
@qiwzhang qiwzhang restored the shared_ctx_ptr branch June 29, 2018 22:50
@qiwzhang qiwzhang reopened this Jun 29, 2018
@qiwzhang
Copy link
Contributor Author

@mattklein123 Please look at the comments at #3765. Due to that, I re-open this PR

@mattklein123
Copy link
Member

@qiwzhang yup agreed this is a cleaner approach. We can review this one.

@qiwzhang
Copy link
Contributor Author

qiwzhang commented Jul 3, 2018

@PiotrSikora @lizan please disregard the mac test failure. This PR is ready for review.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do you need this in the interface?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed it. Please see my other comment

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

update the comment above about rename if we do the rename.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reverted it. Please see my other comment

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in ~ContextImpl it already calls removeContext, isn't this removing twice? since remove doesn't raise exceptions when there is nothing to remove, you may want to add an ASSERT in removeContext.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. It was added in the final PR with secret update code to fix some integration test failures. I reverted the changes for now.

@qiwzhang
Copy link
Contributor Author

qiwzhang commented Jul 9, 2018

@mattklein123 @lizan @PiotrSikora This PR is ready for review. PTAL. Thanks

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: make_shared (throughout all news)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to make ctx_ as std::shared_ptr<Ssl::ContextImpl> and use std::dynamic_pointer_cast? It will eliminates dynamic_casts below.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since now contexts are shared_ptr, shouldn't contexts_ be a list of weak_ptr?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is not easy way to remove the item in the list after its weak_ptr ref_count is 0. Then there will be weak_ptr leak.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

weak_ptr wouldn't be leaked, actually with a list of weak_ptr we can eliminates the releaseContext logic and erase the weak_ptrs when the weak_ptrs are expired when iterating over them. With dynamic secret there will be more inefficient erase call of list which is O(n), so that might be more efficient. I'm OK to make that as a follow up PR later.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. releaseContext is removed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you need createSslClientContext_ any more because shared_ptr is copyable. You can use MOCK_METHOD2 directly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Member

@lizan lizan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you take a look on CI failure?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since iterateContexts is not const method, consider remove empty context here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@lizan
Copy link
Member

lizan commented Jul 11, 2018

@qiwzhang can you merge master and fix tests?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use std::list::remove_if

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer calling removeEmptyContexts instead of inline remove. It will iterate twice but cleaner code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use const ref for parameter

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I'm taking back my previous comment, let's not do this since we're removing in each create. shared_lock above is not enough to perform this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@qiwzhang
Copy link
Contributor Author

@mattklein123 @PiotrSikora Could you help to review this PR? Thanks

lizan
lizan previously approved these changes Jul 12, 2018
Copy link
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks. 1 question.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this lock needed anymore? I'm pretty sure all operations happen on the main thread now...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this PR changed the thread models calling this, no? To minimize risks, I'll defer removing this mutex to #3700.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it did change the thread model. Previously, the lock was only required because IIRC the context was indirectly owned by ClusterInfo, which can be released on any thread. With this change I'm pretty sure that all of the interactions with the context list/map only happen on the main thread, thus the lock is no longer necessary (which is a really nice improvement IMO). If that's the case, I would remove the lock as part of this change as IMO it's a logical part of this change and we can deploy/test it discretely.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah you're right, now when the context is released we're not immediately removing it from contexts_ but wait until next create, which happens in main thread. So we do not need a lock for contexts_ any more. @qiwzhang can you remove this mutex and lock?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@mattklein123
Copy link
Member

@qiwzhang please merge master for flake fixes.

qiwzhang added 12 commits July 16, 2018 20:49
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
@lizan lizan merged commit 445f365 into envoyproxy:master Jul 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants