[lkml]   [2000]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: bug in count_open_files() or a strange granularity?
Hi Alexander,

Thank you for the useful comments.

On Tue, 28 Nov 2000, Alexander Viro wrote:
> On Tue, 28 Nov 2000, Tigran Aivazian wrote:
> > /* switch the open fds from old_user to new_user */
> > read_lock(&files->file_lock);
> > nr_open = close_files(files, 0); /* 0 means don't close them */
> > atomic_sub(nr_open, &old_user->files);
> > atomic_add(nr_open, &new_user->files);
> > read_unlock(&files->file_lock);
> That makes no sense - how do you count the descriptors in shared ->files?
> And how on the Earth do you count SCM_RIGHTS packets? Because they make
> a great way to fool any use of that stuff for resource-limit type of
> applications (stash the descriptors into SCM_RIGHTS cookie, send them to
> yourself and close them).

Yes, both the shared file struct and the SCM_RIGHTS are not so easy to
account. I never said this is ready -- just work in progress. If you have
already done this, please let me know -- there is plenty of other things
to do and I don't wish to step on your toes.

> Basically, I don't see what are you counting.

it is not basic at all. The problems you point out are extremely complex
(at least the fd in transit issue, definitely is).

So, yes it requires a bit more thought. I will come back when the issues
you pointed out are dealt with. Someone has added the 'files' field to the
'struct user_struct' so someone must have meant to put support for this
field to be something other than the meaningless 0 it currently is.


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 12:47    [W:0.043 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site