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
Samium Gromoff _deepfire@feelingofgreen.ru writes:
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.
I thought we'd never write protect specialized raw arrays (either they are in the nursery, or they're tenured into an unboxed region which never get wpd). And passing generic arrays to ffi doesn't feel right. What's the use case?
From: Juho Snellman jsnell@iki.fi
Samium Gromoff _deepfire@feelingofgreen.ru writes:
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.
I thought we'd never write protect specialized raw arrays (either they are in the nursery, or they're tenured into an unboxed region which never get wpd). And passing generic arrays to ffi doesn't feel right. What's the use case?
Array element type is (unsigned-byte 8), use case is shovelling data in/out a USB device using bulk transfers via ioctl().
regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
From: Samium Gromoff _deepfire@feelingofgreen.ru
From: Juho Snellman jsnell@iki.fi
Samium Gromoff _deepfire@feelingofgreen.ru writes:
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.
I thought we'd never write protect specialized raw arrays (either they are in the nursery, or they're tenured into an unboxed region which never get wpd). And passing generic arrays to ffi doesn't feel right. What's the use case?
Array element type is (unsigned-byte 8), use case is shovelling data in/out a USB device using bulk transfers via ioctl().
A missing detail: while the vector is created in a live core all /seems/ to be well[1]. But when it comes from a dumped core, it gets a chance (there doesn't appears to be a determinism there) of being in a write-protected region.
regards, Samium Gromoff -- 1. It might be just that I didn't have enough statistics, as I'm working mainly with cores of my own dumping. Eh, hehe.
_deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Samium Gromoff _deepfire@feelingofgreen.ru writes:
A missing detail: while the vector is created in a live core all /seems/ to be well[1]. But when it comes from a dumped core, it gets a chance (there doesn't appears to be a determinism there) of being in a write-protected region.
Yeah, that'd explain it. We don't correctly restore information about whether a page is boxed or unboxed when loading a core (relevant bits in coreparse.c, and in gencgc.c:gencgc_pickup_dynamic).
2009/11/10 Juho Snellman jsnell@iki.fi:
Samium Gromoff _deepfire@feelingofgreen.ru writes:
A missing detail: while the vector is created in a live core all /seems/ to be well[1]. But when it comes from a dumped core, it gets a chance (there doesn't appears to be a determinism there) of being in a write-protected region.
Yeah, that'd explain it. We don't correctly restore information about whether a page is boxed or unboxed when loading a core (relevant bits in coreparse.c, and in gencgc.c:gencgc_pickup_dynamic).
By a happy coincidence, I've been working on this area recently. Expect to see a commit that keeps track of unboxed pages in saved cores soonish...
Cheers,
-- Nikodemus
-
Juho Snellman -
Nikodemus Siivola -
Samium Gromoff