Re: [PATCH] [Request for inclusion] Filesystem in Userspace

[Avi Kivity <avi@argo.co.il>]

Miklos Szeredi wrote:

>>>And I firmly believe that this can be done without having to special
>>>case filesystem serving processes.
>>> 
>>>
>>>      
>>>
>>I firmly believe the opposite. When a userspace process calls the kernel 
>>which (directly or indirectly) calls the userspace filesystem, the 
>>filesystem must have elevated priviledges, or it can deadlock when 
>>calling back in.
>>    
>>
>
>No.
>
>Just by making the filesystem not contribute to the dirty counters
>(like ramfs), the deadlock problem can be solved.  In this case you
>simply could not get a deadlock, because all those dirty pages
>produced by the filesystem look just like normal allocations, which
>simply cannot be touched when the userspace filesystem wants to
>allocate more memory.
>
>In this case the allocation would just fail.  Deadlock doesn't happen,
>though the filesystem wasn't given any elevated privileges.
>
>Of course this isn't a good situation: the memory is filled in with
>dirty data of the filesystem which it cannot write back.  All sorts of
>  
>
you're describing the deadlock here: all memory is full, no process 
which allocates memory can make any progress. This is not a true oom 
situation: there can be plenty of memory in dirty pagecache which we 
could reclaim if we had that tiny bit of reserve memory.

>I looked at ramfs, it isn't even limited.  You can easily crash your
>system just by filling it up with data, but no deadlock will happen.
>  
>
Right. But ramfs doesn't call a userspace process which calls the kernel 
right back.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.