On Mon, Apr 27, 2020 at 5:18 PM Rainer Jung <[email protected]> wrote: > > Hi Yann, > > Am 27.04.2020 um 16:40 schrieb Yann Ylavic: > > Hi Rainer, > > > > On Mon, Apr 27, 2020 at 3:17 PM Rainer Jung <[email protected]> wrote: > >>> > >>> Thanks for this. > >>> Could you please create this as a PR on github as well? This ensures that > >>> all the Travis tests are run for your patch. > >> > >> Thanks Rüdiger. Done and indeed Travis found one not that I fixed but we > >> need to discuss. > > > > Thanks Rainer, looks very nice. > > > > Could we avoid the "ap_sload_t *sload" pointer in ap_mon_snap_t somehow? > > I'm asking because snap0 and snap1 in global_score (SHM) end up > > containing a pointer now. > > My initial version had the fields of ap_sload_t directly inside > ap_mon_snap_t instead of the pointer. > > I changed it, because > > - it allowed to more safely copy the whole ap_sload_t without relying on > keeping two struct definitions in sync > > - it allowed to extend ap_sload_t and ap_mon_snap_t at their respective > ends and stay compatible. > > You have a problem with the pointers because of possible alignment > issues or what kind of trouble might we run into? Or is it just hard to > understand (and more comments in the code will help)?
My concern is more about security, e.g. CVE-2019-0211 kind of things, with an unprivileged user (child) playing with this pointer and making the main process (monitor?) at best crash, at worst do anything they want (root privilege escalation). Regards, Yann.
