[Sbcl-devel] GC write-protected mappings vs. the OS kernel

[Samium G. <_de...@fe...>]

Good day,

While debugging mysterious ioctl() failures in lh-usb on SBCL,
I have discovered that using CFFI:WITH-POINTER-TO-VECTOR-DATA
doesn't guarantee that the vector is in a writable region.

Normally, with userspace code, this isn't a problem, because,
as pointed on #lisp, the SEGV is handled by the lisp runtime
and the user code is resumed.

However this, understandably, interacts badly with kernel's
expectations, which simply refuses to write to a write-protected
region.

That is where my discovery ended, and a discussion on #lisp ensued,
including, among others, Alastair Bridgewater, James Knight and
Paul Khuong.  The rough consensus seemed to be (correct me if I got this
wrong) that SBCL needs to provide an abstraction for the missing
operation, as the chances of kernel adopting a mechanism allowing
to perform syscall continuation[1] through invocation of user-provided
fault handlers are pretty slim.


While thinking about this I have stumbled upon:

  http://common-lisp.net/project/cffi/darcs/cffi/doc/shareable-vectors.txt

which says:

  The implementation must guarantee the memory pointed to by PTR-VAR
  will not be moved during the dynamic contour of this operator, either
  by creating the vector in a static area or temporarily disabling the
  garbage collector.

IMO, this could be extended with specification of required protections.


regards,
  Samium Gromoff
--
1. We can't just restart the syscall, as we might be unwilling to
reexecute the side-effects which happened in-kernel up to the fault point.
Of course this leads us to PCLSRing..


                                 _deepfire-at-feelingofgreen.ru
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org