Messages in this thread | | | Date | Fri, 4 Jun 1999 05:32:01 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: removing the global lock from sys_brk() |
| |
On Thu, 3 Jun 1999, Linus Torvalds wrote:
> > > 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/
| |