lkml.org 
[lkml]   [2004]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Userspace filesystems (WAS: Encrypted Filesystem)

> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:00    [W:0.297 / U:25.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site