Re: bug in count_open_files() or a strange granularity?

From: Alexander Viro (viro@math.psu.edu)
Date: Tue Nov 28 2000 - 10:55:54 EST


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/



This archive was generated by hypermail 2b29 : Thu Nov 30 2000 - 21:00:20 EST