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