Path resolution improvements #90
Merged
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
tpapagian
force-pushed
the
pr/apapag/path_resolution
branch
9 times, most recently
from
2d67b7a
to
86b7533
Compare
tpapagian
changed the title
tpapagian
force-pushed
the
pr/apapag/path_resolution
branch
from
43af9ed
to
8131dd6
Compare
jrfastab
reviewed
Jun 1, 2022
| "r3 = *(u64 *)%[symbol];\n" \ | ||
| "call 4;\n" CWD_OFFSET_REG " += 1;\n" | ||
|
|
||
| #define MARK_UNRESOLVED_PATH_IF_NEEDED \ |
There was a problem hiding this comment.
hurray slowly but surely deleting all my asm hacks.
tpapagian
force-pushed
the
pr/apapag/path_resolution
branch
from
8131dd6
to
d3de434
Compare
go test -gcflags="" -c ./pkg/metrics -o go-tests/metrics.test ? github.com/cilium/tetragon/pkg/metrics [no test files] Signed-off-by: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>
tpapagian
force-pushed
the
pr/apapag/path_resolution
branch
from
d3de434
to
8440084
Compare
This commit introduces __d_path_local function that is mainly based on d_path kernel function (https://elixir.bootlin.com/linux/v5.10/source/fs/d_path.c#L262). The main difference is that we get the path in the correct order inside the kernel and thus we can do path filtering inside the kernel a bit more easier. We also removed all assembly code from path resolution. This makes the code easier to understand and maintain. Regarding the limitations the main differences compared to d_path (and bpf_d_path) is that we should have a finite number of iterations and the error handling is not as complete as in the kernel. The advantage is that we can use that in older kernels as well (tested for >= 4.19). Regarding the limitation on the path components: before: 1. Up to 2 mount point with 11 path components each of them (kernels <= 5.3) 2. Up to 32 mount points and 32 path components for each of them (kernels > 5.4) now:: 1. Up to 11 path components independently of mount points (i.e. we can have from 1 up to 10 mount points) (kernels <= 5.3) 2. Up to 128 path components independently of mount points (kernels > 5.4) Signed-off-by: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>
This commit also includes the required changes in the user space (i.e. not reversing the path). Signed-off-by: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>
This commit also includes the required changes in the user space (i.e. not reversing the path). Signed-off-by: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>
Signed-off-by: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>
The new approach allows us to do so. Signed-off-by: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>
The increase in path components and mount point limits requires also changes in the tests. Signed-off-by: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>
Now we have only limitations due to path components not mount points. So remove all of this code. Signed-off-by: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>
tpapagian
force-pushed
the
pr/apapag/path_resolution
branch
from
8440084
to
0724bf4
Compare
tpapagian
added a commit
that referenced
this pull request
Jun 23, 2022
Signed-off-by: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>
tpapagian
added a commit
that referenced
this pull request
Jun 23, 2022
Signed-off-by: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>
kkourt
pushed a commit
that referenced
this pull request
Jun 28, 2022
Signed-off-by: Anastasios Papagiannis <tasos.papagiannnis@gmail.com>
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.
This approach is based on
d_pathkernel function (https://elixir.bootlin.com/linux/v5.10/source/fs/d_path.c#L262).The main difference is that we get the path in the correct order inside the kernel and thus we can do path filtering inside the kernel a bit more easier. We also removed all assembly code from path resolution. This makes the code easier to understand and maintain.
Regarding the limitations the main differences compared to
d_path(andbpf_d_path) is that we should have a finite number of iterations and the error handling is not as complete as in the kernel. The advantage is that we can use that in older kernels as well (tested for >= 4.19).Regarding the limitation on the path components:
before:
now:
Signed-off-by: Anastasios Papagiannis tasos.papagiannnis@gmail.com