v1.8 backports 2020-10-07 #13438
Merged
v1.8 backports 2020-10-07 #13438
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[ upstream commit edd0552 ] Signed-off-by: Tom Payne <tom@isovalent.com> Signed-off-by: Quentin Monnet <quentin@isovalent.com>
[ upstream commit e22ee43 ] This makes it clear that the L7 filter builds on the L3/L4 filter. Signed-off-by: Tom Payne <tom@isovalent.com> Signed-off-by: Quentin Monnet <quentin@isovalent.com>
…ed guide [ upstream commit 803f283 ] Signed-off-by: Tom Payne <tom@isovalent.com> Signed-off-by: Quentin Monnet <quentin@isovalent.com>
[ upstream commit ada53a9 ] When a tcp SYN packet hits a conntrack entry that is in close-wait state, the entry timeout will be modified and the entry will be reopened. But because the return code is CT_ESTABLISHED, policy-verdict event will not be generated even this is a new connection. The patch fix the issue by returning the code CT_REOPENED instead in this case. Except for policy verdict events, all other handlings are the same as if CT_ESTABLISHED is returned. Signed-off-by: Zang Li <zangli@google.com> Signed-off-by: Quentin Monnet <quentin@isovalent.com>
[ upstream commit a03e1a6 ] This commit fixes a typo in the IPV4_FRAGMENTS constant in the BPF host filewall, which should have been named ENABLE_IPV4_FRAGMENTS. As IPV4_FRAGMENTS was never defined, this bug caused the `is_untracked_fragment` variable in `ipv4_host_policy_ingress` to be set to `true` even when IPv4 fragment tracking was effectively enabled. This in turn caused the host firewall to always fail the L4 policy lookup for all IPv4 fragment and to always fall back to the L3 policy lookup, potentially returning the incorrect DROP_FRAG_NOSUPPORT error in case no policy allowing the traffic was in place. Signed-off-by: Gilberto Bertin <gilberto@isovalent.com> Signed-off-by: Quentin Monnet <quentin@isovalent.com>
[ upstream commit 4a66961 ] It has been observed that the "sessionSuccess <- true" statement can block forever. E.g. Cilium v1.7.9: goroutine 742 [chan send, 547 minutes]: github.com/cilium/cilium/pkg/kvstore.(*etcdClient).renewLockSession(0xc000f66000, 0x2790b40, 0xc000e247c0, 0x0, 0x0) /go/src/github.com/cilium/cilium/pkg/kvstore/etcd.go:657 +0x3e2 github.com/cilium/cilium/pkg/kvstore.connectEtcdClient.func6(0x2790b40, 0xc000e247c0, 0x3aae820, 0x2) /go/src/github.com/cilium/cilium/pkg/kvstore/etcd.go:819 +0x3e github.com/cilium/cilium/pkg/controller.(*Controller).runController(0xc000f42500) /go/src/github.com/cilium/cilium/pkg/controller/controller.go:205 +0xa2a created by github.com/cilium/cilium/pkg/controller.(*Manager).updateController /go/src/github.com/cilium/cilium/pkg/controller/manager.go:120 +0xb09 This can happen when the context cancellation timer fires after a function which consumes the context has returned, but before "sessionSuccess <- true" is executed. After the timeout, the receiving goroutine is closed, making the sending block forever. Fix this by making the sessionSuccess channel buffered. Note that after sending we don't check whether the context has been cancelled, as we expect that any subsequent functions which consume the context will check for the cancellation. Fixes: 0262854 ("etcd: Fix incorrect context usage in session renewal") Signed-off-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Quentin Monnet <quentin@isovalent.com>
qmonnet
added
backport/1.8
kind/backports
|
test-backport-1.8 |
pchaigno
approved these changes
Oct 7, 2020
gandro
approved these changes
Oct 7, 2020
|
LGTM for my changes, thanks! |
lzang
approved these changes
Oct 9, 2020
|
test-1.18-4.9 |
maintainer-s-little-helper
bot
added
the
ready-to-merge
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Once this PR is merged, you can update the PR labels via: