GC write-protected mappings vs. the OS kernel
Samium Gromoff <_deepfire <at> feelingofgreen.ru>
2009-11-10 15:26:30 GMT
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
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 through invocation of user-provided
fault handlers are pretty slim.
While thinking about this I have stumbled upon:
The implementation must guarantee the memory pointed to by PTR-VAR
will not be moved during the dynamic contour of this operator, either