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

[Avi Kivity]

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.

-
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/