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.

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

Handle director loop #3899

Open
nigoroll opened this issue Mar 3, 2023 · 0 comments
Open

Handle director loop #3899

nigoroll opened this issue Mar 3, 2023 · 0 comments

Comments

@nigoroll
Copy link
Member

nigoroll commented Mar 3, 2023

This ticket is to take a related, but different issue out of #3895

We do not currently handle director loops, which can cause an infinite recursion on resolution, inevitably leading to a stack overflow.

Two options are on the table right now

  • when adding a src backend to a dst, ask src via a new callback if dst is reachable. The callback would iterate over all backends. If any matches dst, that would fail the add operation. Otherwise the callback would be called recursively.

  • Limit the number of layers which director resolution can pass through.

nigoroll added a commit to nigoroll/varnish-cache that referenced this issue Mar 3, 2023
Before this patch, layered directors needed to be destroyed top to
bottom, and whenever that order was missed, we would panic, because a
to-be-destroyed director still had references to it.

One special case where this issue would always trigger are looped
directors. Those should not be used and will cause havoc, which is a
separate issue varnishcache#3899. But we should still be able to unconfigure such
a configuration.

We solve the destruction order issue by making it a two step process:

When a director is destroyed through VRT_DelDirector, a new release
function is called, which has to disassociate any backends. The
director then loses a reference, and when all references are gone, the
destroy function is called.

The new callback would not be necessary for the cases in varnish-cache
today, directors could simply disassociate any backends before calling
VRT_DelDirector. But this would complicate or even make impossible
transfer of director ownership, where the code responsible for
creating a director is not the same as the one calling
VRT_DelDirector(). As a side effect, it also helps clarity.

Fixes varnishcache#3895
nigoroll added a commit to nigoroll/varnish-cache that referenced this issue Mar 6, 2023
Before this patch, layered directors needed to be destroyed top to
bottom, and whenever that order was missed, we would panic, because a
to-be-destroyed director still had references to it.

One special case where this issue would always trigger are looped
directors. Those should not be used and will cause havoc, which is a
separate issue varnishcache#3899. But we should still be able to unconfigure such
a configuration.

We solve the destruction order issue by making it a two step process:

When a director is destroyed through VRT_DelDirector, a new release
function is called, which has to disassociate any backends. The
director then loses a reference, and when all references are gone, the
destroy function is called.

The new callback would not be necessary for the cases in varnish-cache
today, directors could simply disassociate any backends before calling
VRT_DelDirector. But this would complicate or even make impossible
transfer of director ownership, where the code responsible for
creating a director is not the same as the one calling
VRT_DelDirector(). As a side effect, it also helps clarity.

Fixes varnishcache#3895
nigoroll added a commit to nigoroll/varnish-cache that referenced this issue Mar 6, 2023
Before this patch, layered directors needed to be destroyed top to
bottom, and whenever that order was missed, we would panic, because a
to-be-destroyed director still had references to it.

One special case where this issue would always trigger are looped
directors. Those should not be used and will cause havoc, which is a
separate issue varnishcache#3899. But we should still be able to unconfigure such
a configuration.

We solve the destruction order issue by making it a two step process:

When a director is destroyed through VRT_DelDirector, a new release
function is called, which has to disassociate any backends. The
director then loses a reference, and when all references are gone, the
destroy function is called.

The new callback would not be necessary for the cases in varnish-cache
today, directors could simply disassociate any backends before calling
VRT_DelDirector. But this would complicate or even make impossible
transfer of director ownership, where the code responsible for
creating a director is not the same as the one calling
VRT_DelDirector(). As a side effect, it also helps clarity.

Fixes varnishcache#3895
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

No branches or pull requests

1 participant