Hi:
Forgive me if I'm not completely understanding this, but isn't release()
only called when the refcount of the file structure drops to zero? e.g.:
[18]Note that release isn't invoked every time a process calls close.
Whenever a file structure is shared (for example, after a fork or a
dup), release won't be invoked until all copies are closed. If you need
to flush pending data when any copy is closed, you should implement the
flush method.
Seems to me that even /with/ a change in semantics of close(), only the
last call to close() would actually get notified of the failure.
Thinking to NFS, would flush() be a better file_operation to use?
Regards,
- Dave
dave@codewhore.org
On Thu, Mar 21, 2002 at 03:13:39AM -0500, Jeff Garzik wrote:
> Axel Kittenberger wrote:
>
> >Here goes my liitle patchy, once again :o)
> >
> >Whats it's about?
> >
> >When close()ing an charcter device one expects the return value of the
> >charcter drivers release() call to be forwarded to the close() called in
> >userspace. However thats not the case, the kernel swallows the release()
> >value, and always returns 0 to the userspace's close(). (tha char drivers
> >release() function is called in fput() as it would have a void return value)
> >
> >It may sound weired at first but there are actually device drivers than can
> >fail on close(), in my case it's a driver to program a LCA, the userspace
> >application signals end of data by closing the device, the driver finalizes
> >the download, and the LCA reports if it has accepted it's new program, if not
> >close() should return a non-zero value, indicating the operation did not
> >complete successfully.
> >
>
> Do you see how many places call fput() ? Are you going to audit
> __all__ those paths and prove to us that changing the semantics of
> close(2) in Linux doesn't break things in the kernel or in userland?
>
> Your driver is buggy, if it thinks it can fail f_op->release.
>
> Jeff
This archive was generated by hypermail 2b29 : Sat Mar 23 2002 - 22:00:25 EST