crypto_acompress #311
crypto_acompress #311
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR replaces the synchronous compression implementation with an asynchronous one using the Linux kernel's acompress API. The change introduces a new low-level crypto.acompress module that provides asynchronous compression operations, while maintaining backward compatibility through a high-level crypto.comp Lua module that wraps the async operations to provide a synchronous interface.
Key changes:
- Replaces synchronous
luacrypto_comp.cwith asynchronousluacrypto_acompress.c - Adds high-level Lua wrapper
crypto/comp.luato maintain synchronous API compatibility - Updates build configuration to use the new acompress module
Reviewed Changes
Copilot reviewed 7 out of 8 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| lib/luacrypto_comp.c | Removed - old synchronous compression implementation |
| lib/luacrypto_acompress.c | Added - new asynchronous compression implementation using kernel acompress API |
| lib/crypto/comp.lua | Added - high-level Lua wrapper providing synchronous interface over async operations |
| tests/crypto/comp.lua | Minor error message improvement for clarity |
| config.ld | Updated documentation config to reference new files |
| Makefile | Updated build config to use acompress module |
| Kbuild | Updated kernel build config to use acompress module |
jperon
force-pushed
the
jperon_crypto_acompress
branch
from
723e663 to
1df9379
Compare
|
|
||
| static void luacrypto_acompress_docall(void *data, int err) | ||
| { | ||
| lunatik_object_t *runtime = lunatik_toruntime(((luacrypto_acompress_t *)data)->L); |
There was a problem hiding this comment.
you should actually save the runtime in your struct instead of the Lua state.. you have no guarantee that such state will be still valid when your callback is called.. you can just follow the pattern we are using in other modules
There was a problem hiding this comment.
| lua_pushinteger(L, err); | ||
|
|
||
| if (err == 0) | ||
| lua_pushlstring(L, (const char *)obj->outbuf_data, obj->req->dlen); |
There was a problem hiding this comment.
it might cause a kernel panic due to ENOMEM.. in this case, you are not running in a pcall.. you should move everything need that might raise an error to a pcall on a callback called from the kernel
| { | ||
| luacrypto_acompress_t *obj = data; | ||
|
|
||
| if (lunatik_getregistry(L, lunatik_toobject(L, 1)) != LUA_TFUNCTION) { |
There was a problem hiding this comment.
this pattern looks weird to me.. we shouldn't neve use toobject unless in the cases we are perfectly sure it's our object (e.g., after checking it).. it's not clear to me why you need it here anyway.. I would take a look in the patter we are using for acquiring Lua values in kernel callbacks, for instance, luanetfilter and luaxdp
| #include <lua.h> | ||
| #include <lualib.h> | ||
| #include <lauxlib.h> | ||
| #include <lunatik.h> |
There was a problem hiding this comment.
| #include <lunatik.h> | |
| #include <lunatik.h> |
Fixes #307