lkml.org 
[lkml]   [2000]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: bug in count_open_files() or a strange granularity?


On Tue, 28 Nov 2000, Tigran Aivazian wrote:

> On Tue, 28 Nov 2000, David S. Miller wrote:
> > What you want is something like:
> >
> > static int num_open_files(struct files_struct *files, int size)
> > {
> > total = 0;
> > for (i = size / (8 * sizeof(long)); i > 0; )
> > total += count_bits(files->open_fds->fds_bits[--i]);
> >
> > return total;
> > }
>
> Ok, since we have to walk the sets and test the bits anyway, I propose to
> make close_files() to return 'nr_open_fds' and accept an extra argument
> 'doclose=0 or 1' which will specify whether we want to close the 'fd' or
> whether we just want to count them.

What for? I smell a bunch of races here - as soon as you release ->files_lock
the value of the function (it can be called only with that lock held) becomes
meaningless.

Besides, locking rules like that (you must hold the files->files_lock if
doclose is 0 and you must NOT hold it is doclose is 1) are sick. We could
make the function itself grab the spinlock, but then the return value
becomes junk before the thing returns it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:47    [W:0.035 / U:14.724 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site