On Mon, Mar 27, 2006 at 11:33:37PM +0100, Blaisorblade wrote:
> Especially maybe_map must pin the pages (see implementation of 4G/4G
> copy_*_user from Ingo Molnar).
Yup, looks like we can follow Ingo's implementation on this one.
> I'll work on this, I had come up with a nice design time ago, if you merge a
> lockless filehandle I'll be glad to add locking to it. If you have a somehow
> stable code base on it, let me know and I'll work on the patches.
I believe that the filehandle that's in my patchset is stable. I've
beat on it with hostfs with no problems. humfs is less healthy, but
it looks like the problems don't have anything to do with filehandle.
> My design was that you:
> a) take the list lock
> b) remove the fd from the list
> c) drop the list lock
> instead of simply bringing the fd upfront
> d) call read (or whatever) on the interested fd
> e) redo a)-c) but now to _add_ the fd on list, on the front
Which was pretty much the get_fh() and put_fh() I was considering.
It's just a pain to have to wrap that around every file access.
> This may also need a reference count if in step b) the fd may already be on
> the list.
The scenario I think you have in mind is
one process gets an fd for file I/O
so does another one
the first process finishes and sticks the thing back on the
list
it is reclaimed, screwing the second process, which hasn't
made the system call yet
In this case, get_fh should just increment a count, put_fh should
decrement it, and the only list operation should be to move it to the
end of the list so it's last to be reclaimed. The reclaimer would not
reclaim filehandles with non-zero counts. I see no point in removing
it from the list and adding it back, as that seems not to protect
against anything.
> *) when _any_ fd API of the existing set (os_*) is called, it detects
> -EMFILE/-ENFILE and closes fd's on the back of the list (i.e. we do LRU on
> the list)
You're envisioning the os_* interfaces calling back into filehandle.c
to get a descriptor if needed? That would make this whole thing less
"layery", which I can see.
> *) using new APIs is only needed to register an fd as "reclaimable" - this is
> optional since it can be used only for file-based fds (not for pipes,
> probably not for sockets)
Which is how things work now, as is_reclaimable is called only when it
is known that a file has been opened.
Jeff
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
