>> I have found enough time to have a quick look at the code, and I've >> found a code path that looks like what I was looking for: something >> that blocks until a git subprocess finishes without handling >> filesystem requests in the meantime. I'll need to reorganize the >> code a little to fix that.
> Doesn't thie problem need a deeper fix? It is annoying that a poorly > programmed userland process can kill the system. No more so than a puffs backing process that mounts the filesystem and then goes into an infinite loop. This sort of failure mode is one of the risks of userland-backed filesystems. It just took me a while to track it down, largely for complete lack of prior experience with anything of the sort. Or consider while (1) { fork(); }. Also, and not directly related to your remark, I now suspect that if I'd told ddb to kill the gitfs process(es), the system would have come unstuck. I don't see this as fundamentally different (though admittedly less severe than) dd if=/dev/urandom of=/dev/mem: if root does something sloppy, Bad Things can happen. I think you will have trouble completely preventing userland from wedging or crashing the system while still preserving a useful system. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B