[lkml]   [2001]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
On Tue, 16 Jan 2001, Ingo Molnar wrote:

> But even user-space code could use 'native files', via the following, safe
> mechanizm:

so here's an alternative to ingo's proposal which i think solves some of
the other objections raised. it's something i've proposed in the past
under the name "extended file handles".

struct extended_file_permission {
int refcount;
some form of mutex to protect refcount;
some list structure head;

struct extended_file {
struct file *file;
struct extended_file_permission *perm;
whatever list foo is needed to link with extended_file_perm above;

if you allocate a few huge arrays of struct extended_file, then you can
verify if a pointer passed from user space fits into one of those arrays
pretty quickly.

struct task has a struct extended_file_permission * added to it to
indicate which perm struct that task is associated with.

so you just compare the f->perm to current->extended_file_perm and you
know if the task is allowed to use it or not.

clone() allows you to create tasks sharing the same

fork()/exec() would create new extended_file_perms -- which implicitly
causes all those files to be closed. this gives you pretty light cgi
fork()/exec() off a main "process" which is handling thousands of sockets.

i also proposed various methods of doing O_foo flag inheritance... but the
above is more interesting.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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