sigkill and write() with containers

[Marcus Brinkmann]

Hi,

(for lurkers: this connects to our online discussion at:
 http://walfield.org/pub/people/neal/memory-server.txt
 It's probably a good idea for you to just wait until its integrated in my
 hurd-on-l4.tex notes)

here is my idea, we will have to cross check in more detail at some time:

We don't use timeouts with containers.  DMA is exempted because its trusted,
so it can take an explicit lock for as long as it wants.

All users of untrusted container memory must guard against page faults.
If the user destroys the container, it is revoked.  This means that all
mappings of the container content are unmapped.  This affects other users,
like filesystems.  SIGKILL will implicitely destroy the container.
If a filesystem page faults, it basically treats it as if the operation was
interrupted by a signal.  It will abort the operation and return the number
of bytes written/read so far.  (Of course, if this was due to SIGKILL, it
will not return anything).

This is almost sanctioned by POSIX, I think.  POSIX says that writes must be
atomic, ie not interleaved with other writes.  This is the case here.  The
write is just not complete.  POSIX allows interrupting writes, in which case
the number of written bytes must be returned, which we do (or attempt).  The
user can then restart the operation (maybe :).  [One can make the same
argument for string items, in case we want to use them for short writes, so
we don't even need to pin buffer pages for that.]

There is an exception: Pipes are different.  Now, for pipes we would want to
use string items anyway (this is ok because pipe server is our own and thus 
mutual
trusts exists - even the server can receive and send string items _with_
infinite timeout!).  For other pipe like items, a write of PIPE_BUF might be 
required
to succeed completely or not.  I am not sure.  Even if it is the case, we
can copy the PIPE_BUF bytes to a local buffer before really doing the
operation.  This will be fine, because PIPE_BUF is small.

I am not sure if PIPE_BUF is a problem, so I am mentioning it for
completeness.  The reason why I think we can make all writes interruptible
is this sentence in POSIX:

36795              The issue of which files or file types are interruptible is 
considered an implementation design
36796              issue. This is often affected primarily by hardware and 
reliability issues.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/