Messages in this thread |  | | From | (Richard Henderson) | Subject | Re: CLONE_FILES problem. | Date | Mon, 19 Aug 1996 10:02:35 -0500 (CDT) |
| |
Alexey Kuznetsov wrote: > > A separate issue is that the kernel should be prepared to handle > > such situations in such a way that it does not crash but gracefully > > returns an error from the system call. (I don't know that such > > checks aren't there -- I havn't looked.) > > > > Yes, yes. It is the thing that I wanted to say. > > Kernel really does not protect files, I found it when > got crash with cloned socket. Initially I thought that it > is socket level bug, but found that it can occur with any > file.
Ah. I had not properly understood you then.
My initial reaction is to want the close to interrupt a blocking read. However, it does not appear that the drivers are really set up for that sort of thing.
With your filp->f_count idea, at least there is the apperance of serializing the read and close. It also localizes the changes to the main system-call entry points rather than sprinkling them all through the driver code. In implementing this though, one should not forget to use the functions in <asm/atomic.h> for manipulating the count.
r~
|  |