lkml.org 
[lkml]   [2004]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] [Request for inclusion] Filesystem in Userspace
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@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:08    [W:1.437 / U:0.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site