Re: Userspace filesystems (WAS: Encrypted Filesystem)

[Miklos Szeredi]

> Jean-Luc wrote:
> >    app wants to read data from a file ->
> >    userspace application requires memory allocation to provide this data ->
> >    VM tries to write out dirty data associated with the Coda mountpoint ==
> >    deadlock
> 
> How do you solve this one?

1) In FUSE normal writes go through the cache, so no dirty pages are
   created.  The only possibility to create dirty pages is with shared
   writable mapping, and this is rare

2) Userspace filesystem app can be multithreaded, so probably write
   can be satisfied even if read is pending.

3) The 2.6 kernel provides asynchronous page writeback, so even if a
   writeback is blocking forever the VM will continue to try to free
   up memory.

4) If no memory can be freed, then the allocation will fail, so the
   read will fail: no deadlock.

5) Even if the memory allocation was caused by a page fault, which
   cannot fail, the worst case is that the OOM killer is invoked, and
   memory is freed up: no deadlock.

So with the asynchronous page writeback mechanism the 2.6 kernel is
very immune to this kind of deadlock.  I have tested this with a
little program which behaves very nastily in this respect (I can send
you this if you're interested).  And I was able to invoke the OOM
killer if there was no swap, but there was never a deadlock.

Miklos

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/