-
Notifications
You must be signed in to change notification settings - Fork 151
libbpf: move arena variables out of the zero page #10319
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
base: bpf-next_base
Are you sure you want to change the base?
Conversation
|
Upstream branch: 4722981 |
4a6b8b7 to
1efb39d
Compare
|
Upstream branch: 7dc211c |
66bc771 to
af1e7a8
Compare
1efb39d to
5b97b4a
Compare
|
Upstream branch: ec12ab2 |
af1e7a8 to
45dd3f1
Compare
5b97b4a to
7b6b51d
Compare
|
Upstream branch: d6ec090 |
45dd3f1 to
42f87c7
Compare
7b6b51d to
2412df8
Compare
|
Upstream branch: d6ec090 |
42f87c7 to
04480e6
Compare
2412df8 to
bfb0726
Compare
|
Upstream branch: d088da9 |
04480e6 to
55f3e2d
Compare
bfb0726 to
b0a5b86
Compare
|
Upstream branch: e0940c6 |
The big_alloc1 test in verifier_arena_large assumes that the arena base and the first page allocated by bpf_arena_alloc_pages are identical. This is not the case, because the first page in the arena is populated by global arena data. The test still passes because the code makes the tacit assumption that the first page is on offset PAGE_SIZE instead of 0. Make this distinction explicit in the code, and adjust the page offsets requested during the test to count from the beginning of the arena instead of using the address of the first allocated page. Signed-off-by: Emil Tsalapatis <[email protected]>
Add a stub function for reporting in which offset within a mapping libbpf places the map's data. This will be used in a subsequent patch to support offsetting arena variables within the mapped region. Adjust skeleton generation to account for the new arena memory layout by adding padding corresponding to the offset into the arena map. Add a libbbpf API function to get the data offset within the map's mapping during skeleton generation. Signed-off-by: Emil Tsalapatis <[email protected]>
Currently, libbpf places global arena data at the very beginning of the arena mapping. Stray NULL dereferences into the arena then find valid data and lead to silent corruption instead of causing an arena page fault. The data is placed in the mapping at load time, preventing us from reserving the region using bpf_arena_reserve_pages(). Adjust the arena logic to attempt placing the data from an offset within the arena (currently 16 pages in) instead of the very beginning. If placing the data at an offset would lead to an allocation failure due to global data being as large as the entire arena, progressively reduce the offset down to 0 until placement succeeds. Adjust existing arena tests in the same commit to account for the new global data offset. New tests that explicitly consider the new feature are introduced in the next patch. Signed-off-by: Emil Tsalapatis <[email protected]>
Add tests for the new libbpf globals arena offset logic. The tests cover all three cases: The globals being small enough to be placed at the maximum possible offset, being as large as the arena itself and being placed at the very beginning, and requiring an intermediate offset into the arena. Signed-off-by: Emil Tsalapatis <[email protected]>
55f3e2d to
69324ab
Compare
Pull request for series with
subject: libbpf: move arena variables out of the zero page
version: 2
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=1024622