[lkml]   [1996]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: CLONE_FILES problem.
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.


 \ /
  Last update: 2005-03-22 13:37    [W:0.034 / U:4.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site