feat(wasm): proxy-wasm property getters/setters #11856
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
hishamhm
force-pushed
the
feat/wasm-dynamic-properties
branch
3 times, most recently
from
df17f42
to
aeb256d
Compare
hishamhm
force-pushed
the
feat/wasm-dynamic-properties
branch
3 times, most recently
from
2bc0a7e
to
c45beac
Compare
hishamhm
force-pushed
the
feat/wasm-dynamic-properties
branch
2 times, most recently
from
fb453b1
to
f4d9780
Compare
|
|
thibaultcha
reviewed
Nov 28, 2023
hishamhm
force-pushed
the
feat/wasm-dynamic-properties
branch
3 times, most recently
from
06853b5
to
5cc2f77
Compare
flrgh
reviewed
Dec 4, 2023
|
note: we should rebase this instead of squashing to preserve the history on commits like 5cc2f77 |
…67ca53aa * chore(deps): bump ngx_wasm_module to b51a15fc972540e6b8964e2fe1d86ebf67ca53aa Changes since ddb3fa8f7cacc81557144cf22706484eabd79a84: * b51a15f - chore(*) add a .gitattributes file * 9959389 - fix(*) resolve a possible segfault in the FFI * 8c45ad1 - fix(*) proper filter modules order in dynamic OpenResty builds * 33157a8 - feat(proxy-wasm) custom host properties getters/setters * 81c703e - docs(*) minor fix for a title level * db88b15 - fix(proxy-wasm) free dispatch calls during resume edge-case * 5553ae0 - feat(proxy-wasm) strengthen host functions context checks
Co-Authored-By: Hisham Muhammad <hisham@gobolinux.org>
This prevents triggering a LuaJIT issue when attempting to call an FFI
callback with an ongoing trace further down the stack; attempting to do so can
trigger a "bad callback" assertion.
Stack trace demonstrating the issue in question:
```
from /home/zhongweiyao/projects/kong/bazel-bin/build/kong-dev/openresty/nginx/sbin/../modules/ngx_wasm_module.so
at /home/zhongweiyao/.cache/bazel/_bazel_zhongweiyao/7df4419a5ca351a16fa75df771d28bc8/execroot/kong/external/ngx_wasm_module/src/wasm/wrt/ngx_wrt_wasmtime.c:657
at /home/zhongweiyao/.cache/bazel/_bazel_zhongweiyao/7df4419a5ca351a16fa75df771d28bc8/execroot/kong/external/ngx_wasm_module/src/wasm/vm/ngx_wavm.c:1107
at /home/zhongweiyao/.cache/bazel/_bazel_zhongweiyao/7df4419a5ca351a16fa75df771d28bc8/execroot/kong/external/ngx_wasm_module/src/wasm/vm/ngx_wavm.c:1184
at /home/zhongweiyao/.cache/bazel/_bazel_zhongweiyao/7df4419a5ca351a16fa75df771d28bc8/execroot/kong/external/ngx_wasm_module/src/wasm/vm/ngx_wavm.c:1287
at /home/zhongweiyao/.cache/bazel/_bazel_zhongweiyao/7df4419a5ca351a16fa75df771d28bc8/execroot/kong/external/ngx_wasm_module/src/http/proxy_wasm/ngx_http_proxy_wasm.c:40
at /home/zhongweiyao/.cache/bazel/_bazel_zhongweiyao/7df4419a5ca351a16fa75df771d28bc8/execroot/kong/external/ngx_wasm_module/src/http/proxy_wasm/ngx_http_proxy_wasm.c:411
at /home/zhongweiyao/.cache/bazel/_bazel_zhongweiyao/7df4419a5ca351a16fa75df771d28bc8/execroot/kong/external/ngx_wasm_module/src/common/proxy_wasm/ngx_proxy_wasm.c:658
at /home/zhongweiyao/.cache/bazel/_bazel_zhongweiyao/7df4419a5ca351a16fa75df771d28bc8/execroot/kong/external/ngx_wasm_module/src/common/proxy_wasm/ngx_proxy_wasm.c:783
at /home/zhongweiyao/.cache/bazel/_bazel_zhongweiyao/7df4419a5ca351a16fa75df771d28bc8/execroot/kong/external/ngx_wasm_module/src/wasm/ngx_wasm_ops.c:417
at /home/zhongweiyao/.cache/bazel/_bazel_zhongweiyao/7df4419a5ca351a16fa75df771d28bc8/execroot/kong/external/ngx_wasm_module/src/wasm/ngx_wasm_ops.c:290
at /home/zhongweiyao/.cache/bazel/_bazel_zhongweiyao/7df4419a5ca351a16fa75df771d28bc8/execroot/kong/external/ngx_wasm_module/src/common/lua/ngx_wasm_lua_ffi.c:164
at ../ngx_lua-0.10.25/src/ngx_http_lua_util.c:1184
respawn=-3) at src/os/unix/ngx_process.c:199
```
The problem arises when Wasm code eventually calls the FFI callback which triggers Lua code while having an ongoing
trace in the stack (see frame 12, `TRACE_1054`, in the example above).
Eventually the LuaJIT callback crashes like this:
```
at /home/zhongweiyao/.cache/bazel/_bazel_zhongweiyao/7df4419a5ca351a16fa75df771d28bc8/execroot/kong/external/ngx_wasm_module/src/common/proxy_wasm/ngx_proxy_wasm_properties.c:1058
at /home/zhongweiyao/.cache/bazel/_bazel_zhongweiyao/7df4419a5ca351a16fa75df771d28bc8/execroot/kong/external/ngx_wasm_module/src/common/proxy_wasm/ngx_proxy_wasm_host.c:780
at /home/zhongweiyao/.cache/bazel/_bazel_zhongweiyao/7df4419a5ca351a16fa75df771d28bc8/execroot/kong/external/ngx_wasm_module/src/wasm/vm/ngx_wavm_host.c:265
from /home/zhongweiyao/projects/kong/bazel-bin/build/kong-dev/openresty/nginx/sbin/../modules/ngx_wasm_module.so
from /home/zhongweiyao/projects/kong/bazel-bin/build/kong-dev/openresty/nginx/sbin/../modules/ngx_wasm_module.so
from /home/zhongweiyao/projects/kong/bazel-bin/build/kong-dev/openresty/nginx/sbin/../modules/ngx_wasm_module.so
from /home/zhongweiyao/projects/kong/bazel-bin/build/kong-dev/openresty/nginx/sbin/../modules/ngx_wasm_module.so
...
```
Here's some sample minimal code to reproduce the LuaJIT issue outside of the Gateway:
```lua
-- Lua code
local ffi = require("ffi")
local C = ffi.C
ffi.cdef [[
typedef int (*my_fn_t)(int, int, int);
int f2();
void setup(my_fn_t f, int, int, int);
]]
local lib = ffi.load("test")
function setup(cb, a, b, c)
lib.setup(cb, a, b, c)
end
function f0()
return lib.f2() + 1
end
do
local cb = ffi.cast("my_fn_t", function(a, b, c)
return a+b+c
end)
setup(cb, 10, 99, 13)
print(f0())
for i=1,300 do
if i > 60 then f0() end
end
end
```
```c
/* C code */
typedef int (*my_fn_t)(int, int, int);
my_fn_t gf = 0;
int ga;
int gb;
int gc;
void setup(my_fn_t f, int a, int b, int c) {
gf = f;
ga = a;
gb = b;
gc = c;
}
int f2() {
return gf(ga, gb, gc) + 1;
}
```
The issue in question has been a known for a long time. See:
https://luajit.freelists.narkive.com/sdhSLJSr/how-to-make-bad-callback-more-deterministic
```
The bad callback error happens because some JIT-compiled Lua code calls a C
function which in turn calls an FFI callback.
```
https://lua-l.lua.narkive.com/qXJrNlpP/luajit-ffi-windows-bad-callback-error-in-msgwaitformultipleobjects-proof-of-concept
From Mike Pall:
```
The problem is that a FFI callback cannot safely be called from a
C function which is itself called via the FFI from JIT-compiled
code. In your case this is the call to MsgWaitForMultipleObjects.
I've put in a lot of heuristics to detect this, and it usually
succeeds in disabling compilation for such a function. However in
your case the loop is compiled before the callback is ever called,
so the detection fails.
The straighforward solution is to put the message loop into an
extra Lua function and use jit.off(func)
```
Signed-off-by: Hisham Muhammad <hisham@gobolinux.org>
locao
force-pushed
the
feat/wasm-dynamic-properties
branch
from
5cc2f77
to
6e4acb6
Compare
bungle
added
the
cherry-pick kong-ee
|
Cherry-pick failed for Please cherry-pick the changes locally. git remote add upstream https://github.com/kong/kong-ee
git fetch upstream master
git worktree add -d .worktree/cherry-pick-11856-to-master-to-upstream upstream/master
cd .worktree/cherry-pick-11856-to-master-to-upstream
git checkout -b cherry-pick-11856-to-master-to-upstream
ancref=$(git merge-base 8e5cb497b73512afa972c18eda07232c8a94ead6 6e4acb68a7cdd4bf7ea5a56259271bf66157b953)
git cherry-pick -x $ancref..6e4acb68a7cdd4bf7ea5a56259271bf66157b953 |
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.
Summary
Adds support for proxy-wasm properties in the
kong.*namespace, making a number of Kong PDK functions available for Wasm filters, using the support for dynamic property getters/setters introduced in Kong/ngx_wasm_module#431.Checklist
changelog/unreleased/kongorskip-changeloglabel added on PR if changelog is unnecessary. README.mdThere is a user-facing docs PR against https://github.com/Kong/docs.konghq.com- beta feature