From: Igor Munkin <imun@tarantool.org> To: Alexander Turenko <alexander.turenko@tarantool.org> Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v2 1/3] merger: fix NULL dereference when called via iproto Date: Wed, 1 Jul 2020 23:36:33 +0300 [thread overview] Message-ID: <20200701203633.GA5559@tarantool.org> (raw) In-Reply-To: <e66291b80cb7ad79d82c7ac7ca5824fdc45000d3.1592416673.git.alexander.turenko@tarantool.org> Sasha, Thanks for the patch! It LGTM except the couple of nits I left below. On 18.06.20, Alexander Turenko wrote: <snipped> > A particular source implementation may use a Lua state internally, but > it is not part of the API and should be hidden under hood. In fact all Typo: s/under hood/under the hood/ or s/under hood/under its hood/. > sources we have now (except merger itself) store some references in > LUA_REGISTRYINDEX and need a temporary Lua stack to work with them in > the next() virtual method. <snipped> > A few words about the implementation. I have added three functions, > which acquire a temporary Lua state, call a function and release the > state. It may be squashed into one function that would accept a function > pointer and variable number of arguments. However GCC does not > devirtualize such calls at -O2 level, so it seems it is better to avoid > this. It maybe possible to write some weird macro that will technically > reduce code duplication, but I prefer to write in C, not some macro > based meta-language. Side note: No one pushes you to create a particular DSL for this case, but I see nothing criminal to use macros sometimes. I personally prefer to generalize the occurrences you mentioned above. On the second thought I guess performance deviation is negligible and the benefits for the further maintenance are doubtful. > <snipped> > --- > src/box/lua/merger.c | 189 ++++++++++++++++-- > .../gh-4954-merger-via-net-box.test.lua | 129 ++++++++++++ > 2 files changed, 297 insertions(+), 21 deletions(-) > create mode 100755 test/box-tap/gh-4954-merger-via-net-box.test.lua > > diff --git a/src/box/lua/merger.c b/src/box/lua/merger.c > index 1b155152b..cc5626cbc 100644 > --- a/src/box/lua/merger.c > +++ b/src/box/lua/merger.c > @@ -149,6 +149,74 @@ luaT_gettuple(struct lua_State *L, int idx, struct tuple_format *format) > return tuple; > } > > +/** > + * Get a temporary Lua state. > + * > + * Use case: a function does not accept a Lua state as an argument > + * to allow using from C code, but uses a Lua value, which is > + * referenced in LUA_REGISTRYINDEX. A temporary Lua stack is needed > + * to get and process the value. > + * > + * The returned state shares LUA_REGISTRYINDEX with `tarantool_L`. Pardon, I don't get this line. > + * > + * This Lua state should be used only from one fiber: otherwise > + * one fiber may change the stack and another one will access a > + * wrong stack slot when it will be scheduled for execution after > + * yield. > + * > + * Return a Lua state on success and set @a coro_ref. This > + * reference should be passed to `luaT_release_temp_luastate()`, > + * when the state is not needed anymore. > + * > + * Return NULL and set a diag at failure. > + */ > +static struct lua_State * > +luaT_temp_luastate(int *coro_ref) > +{ > + if (fiber()->storage.lua.stack != NULL) { > + *coro_ref = LUA_REFNIL; It definitely doesn't affect the implemented behaviour (considering you're not referencing a <nil> value within <luaT_temp_luastate>); I'm just too pedantic here: LUA_REFNIL is the ref value obtained from <luaL_ref> call anchoring a <nil> slot. At the same time there is another special ref value for your purposes -- LUA_NOREF[1]. Furthermore, it's the way more convenient to use it for *all* initial ref values below. > + return fiber()->storage.lua.stack; > + } > + > + /* > + * luaT_newthread() pops the new Lua state from > + * tarantool_L and it is right thing to do: if we'll push > + * something to it and yield, then another fiber will not > + * know that a stack top is changed and may operate on a > + * wrong slot. It seems to relate more to <luaT_newthread> contract, so you can just mention that it leaves no garbage on the given coroutine stack, ergo nothing need to be popped in the caller function. > + * > + * Second, many requests that push a value to tarantool_L > + * and yield may exhaust available slots on the stack. Pardon, I don't get this line. > + */ > + struct lua_State *L = luaT_newthread(tarantool_L); > + if (L == NULL) > + return NULL; > + /* > + * The new state is not referenced from anywhere (reasons > + * are above), so we should keep a reference to it in the > + * registry while it is in use. > + */ > + *coro_ref = luaL_ref(tarantool_L, LUA_REGISTRYINDEX); > + return L; > +} > + > +/** > + * Release a temporary Lua state. > + * > + * It is the other half of `luaT_temp_luastate()`. It's not a half, it's a complement for <luaT_temp_luastate> function. > + */ <snipped> > -- > 2.25.0 > [1]: https://www.lua.org/manual/5.1/manual.html#pdf-LUA_NOREF -- Best regards, IM
next prev parent reply other threads:[~2020-07-01 20:46 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-17 21:06 [Tarantool-patches] [PATCH v2 0/3] Merger's NULL defererence Alexander Turenko 2020-06-17 21:06 ` [Tarantool-patches] [PATCH v2 1/3] merger: fix NULL dereference when called via iproto Alexander Turenko 2020-06-18 22:48 ` Vladislav Shpilevoy 2020-06-19 8:50 ` Alexander Turenko 2020-06-19 23:32 ` Vladislav Shpilevoy 2020-06-21 18:28 ` Alexander Turenko 2020-07-01 20:36 ` Igor Munkin [this message] 2020-07-16 20:10 ` Alexander Turenko 2020-07-16 21:42 ` Igor Munkin 2020-07-16 22:44 ` Igor Munkin 2020-07-17 3:08 ` Alexander Turenko 2020-06-17 21:06 ` [Tarantool-patches] [PATCH v2 2/3] merger: clean fiber-local Lua stack after next() Alexander Turenko 2020-06-19 8:50 ` Alexander Turenko 2020-07-01 20:36 ` Igor Munkin 2020-07-16 20:11 ` Alexander Turenko 2020-07-16 22:07 ` Igor Munkin 2020-07-17 3:08 ` Alexander Turenko 2020-06-17 21:06 ` [Tarantool-patches] [PATCH v2 3/3] lua: expose temporary Lua state for iproto calls Alexander Turenko 2020-07-01 20:37 ` Igor Munkin 2020-07-16 20:11 ` Alexander Turenko 2020-07-16 22:33 ` Igor Munkin 2020-07-17 3:09 ` Alexander Turenko 2020-06-22 20:38 ` [Tarantool-patches] [PATCH v2 0/3] Merger's NULL defererence Vladislav Shpilevoy 2020-07-17 11:28 ` Alexander Turenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200701203633.GA5559@tarantool.org \ --to=imun@tarantool.org \ --cc=alexander.turenko@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v2 1/3] merger: fix NULL dereference when called via iproto' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox