Skip to content

Pass plugin key from embedders to PluginBase. #178

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.

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

Merged
merged 3 commits into from
Jul 11, 2021

Conversation

mathetake
Copy link
Contributor

This PR allows embedders to pass plugin_key for PluginBases in order for it to include host specific information (e.g. listener info in Envoy).

ref envoyproxy/envoy#17243 (comment)

Signed-off-by: Takeshi Yoneda [email protected]

@mathetake mathetake requested a review from PiotrSikora as a code owner July 10, 2021 01:53
Signed-off-by: Takeshi Yoneda <[email protected]>
Signed-off-by: Takeshi Yoneda <[email protected]>
Copy link
Member

@PiotrSikora PiotrSikora left a comment

Choose a reason for hiding this comment

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

Thanks!

@mathetake mathetake changed the title Pass plugin_key by embedders Pass plugin key from embedders to PluginBase. Jul 11, 2021
@mathetake mathetake merged commit c9760d1 into proxy-wasm:master Jul 11, 2021
@mathetake mathetake deleted the plugin-key branch July 11, 2021 23:33
lizan pushed a commit to envoyproxy/envoy that referenced this pull request Jul 12, 2021
This is the follow up on #16795.

## Bug description

If the same plugin/rootcontext is shared across multiple listeners, then there is a race in listener information.

Before  #16795,  this was not a problem  for stream contexts since given listener information is from *where* it is created (`Plugin: plugin_` member created in the factory instance) https://github.com/envoyproxy/envoy/pull/16795/files#diff-90e133f83d91e5c22d1f7c7e8c0cf8017536a23765978bf81c7efd0482be0d81L43
But after that being merged, the `Plugin` passed to stream context constructor is the one from `PluginHandle::plugin()` which is potentially shared across multiple listeners.

For root contexts, this has been a problem since the beginning because the root context has been already potentially shared across multiple listeners, and pointing to the listener's info which is created first.


## Change in this PR

Combined with proxy-wasm/proxy-wasm-cpp-host#178, we explicitly include listener information into the plugin key so that if two plugins have different info to each other, different plugin instances will be created.

## Note

- Maybe we could drop the support for sharing 1 Plugin across multiple listeners (or filters), then this race condition would be resolved in a different way. I think it is worth discussion.
- This race is originally reported by Istio istio/proxy#3395 (comment)

Signed-off-by: Takeshi Yoneda <[email protected]>
leyao-daily pushed a commit to leyao-daily/envoy that referenced this pull request Sep 30, 2021
)

This is the follow up on envoyproxy#16795.

## Bug description

If the same plugin/rootcontext is shared across multiple listeners, then there is a race in listener information.

Before  envoyproxy#16795,  this was not a problem  for stream contexts since given listener information is from *where* it is created (`Plugin: plugin_` member created in the factory instance) https://github.com/envoyproxy/envoy/pull/16795/files#diff-90e133f83d91e5c22d1f7c7e8c0cf8017536a23765978bf81c7efd0482be0d81L43
But after that being merged, the `Plugin` passed to stream context constructor is the one from `PluginHandle::plugin()` which is potentially shared across multiple listeners.

For root contexts, this has been a problem since the beginning because the root context has been already potentially shared across multiple listeners, and pointing to the listener's info which is created first.


## Change in this PR

Combined with proxy-wasm/proxy-wasm-cpp-host#178, we explicitly include listener information into the plugin key so that if two plugins have different info to each other, different plugin instances will be created.

## Note

- Maybe we could drop the support for sharing 1 Plugin across multiple listeners (or filters), then this race condition would be resolved in a different way. I think it is worth discussion.
- This race is originally reported by Istio istio/proxy#3395 (comment)

Signed-off-by: Takeshi Yoneda <[email protected]>
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.

2 participants