views:

18

answers:

1

Hello, I'm dealing with a problem in a kernel module that get data from userspace using a /proc entry.

I set open/write/release entries for my own defined /proc entry, and manage well to use it to get data from userspace. I handle errors in open/write functions well, and they are visible to user as open/fopen or write/fwrite/fprintf errors.

But some of the errors can only be checked at close (because it's the time all the data is available). In these cases I return something different than 0, which I supposed to be in some way the value 'close' or 'fclose' will return to user.

But whatever the value I return my close behave like if all is fine. To be sure I replaced all the release() code by a simple 'return(-1);' and wrote a program that open/write/close the /proc entry, and prints the close return value (and the errno). It always return '0' whatever the value I give.

Behavior is the same with 'fclose', or by using shell mechanism (echo "..." >/proc/my/entry).

Any clue about this strange behavior that is not the one claimed in many tutorials I found?

BTW I'm using RHEL5 kernel (2.6.18, redhat modified), on a 64bit system.

Thanks.

Regards,

Yannick

A: 

The release() isn't allowed to cause the close() to fail.

You could require your userspace programs to call fsync() on the file descriptor before close(), if they want to find out about all possible errors; then implement your final error checking in the fsync() handler.

caf
Thanks for this answer. It confirms what I have seen from other sources. What is curious is that several tutorials found on the net use the returned value as if it is an error code (i.e. by returning -EBUSY or other errorcodes).I changed my code to handle most of the error cases in the write() function (which propagates errors). I will look at fsync() call for the remaining ones.Thanks,--Yannick
Yannick