>
>
> On Fri, 4 Jun 1999, Alexander Viro wrote:
> >
> > Linus, what do you think of the following trick:
> >
> > void fput(struct file *file)
>
> All of the file handling needs to be validated wrt SMP threading, and I'm
> not ready to do that yet. We have a bigger project underway to try to make
> the page cache do proper writebacks, and that's taking priority.
I did it about a month ago, when guys had problems with fput()-type races
(I've found a bunch of that stuff in the arch/*, but their problem was
outside of the main kernel - iBCS). It took two weeks and was not a
pleasant job ;-/ I believe that I've kept the records. The bottom line:
we ought to do struct file layer first, since dcache and inode layers are
much more convoluted. The worst offenders are RPC-type schedulers in
network file systems, mostly due to the fact that they do not bypass the
struct file layer. I believe that they should go straight to sockets - it
would simplify the life big way.
> Your approaches look reasonable. I don't think we need the compatibility
> thing you have in fput() though - it should rather be just done right, and
> I don't think lazy_fput should be needed.
If by 'compatibility thing' you mean atomic_inc() - yes,
it can be trivially removed. No problem. But distinction between the
forced and lazy semantics on fput() is needed - think of kernel threads.
BTW, maybe we need a generic AST-type thing for that kind of stuff.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/