> On 31 Jan 2023, at 21:29, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> It turns out there have been some latent memory corruption bugs and other
> errors in the bindings since they were first introduced.
>
> These were discovered after realising that we'd introduced other memory
> corruption bugs as part of the Ocaml 5 fixes, and in the case of the evtchn
> bindings, backported this as part of the oxenstored-lu fixes.
>
> This series addresses all the memory corrupution issues we're aware of that
> can occur in an entirely well-formed program.
>
> Deferred for now are the (hopefully latent) memory corruption errors which
> happen due to bad parameter passing, and a substantial pile of related cleanup.
>
> Andrew Cooper (3):
> tools/ocaml/libs: Allocate the correct amount of memory for Abstract_tag
> tools/ocaml/evtchn: Misc cleanup
> tools/ocaml/xc: Don't reference Abstract_Tag objects with the GC lock released
>
> Edwin Török (4):
> tools/ocaml/libs: Don't declare stubs as taking void
> tools/ocaml/evtchn: Don't reference Custom objects with the GC lock released
> tools/ocaml/xc: Fix binding for xc_domain_assign_device()
> tools/ocaml/xc: Don't reference Custom objects with the GC lock released
>
> tools/ocaml/libs/eventchn/xeneventchn_stubs.c | 89 ++---
> tools/ocaml/libs/mmap/Makefile | 2 +
> tools/ocaml/libs/mmap/xenmmap_stubs.c | 6 +-
> tools/ocaml/libs/xb/xenbus_stubs.c | 5 +-
> tools/ocaml/libs/xc/xenctrl_stubs.c | 494 ++++++++++++++------------
> 5 files changed, 323 insertions(+), 273 deletions(-)
>
> --
> 2.11.0
>
Really pleased with the attention to this.
Acked-by: Christian Lindig <christian.lindig@citrix.com>