Re: [RFC][PATCH 8/9] vfs: Implement generic revoked file operations

[Eric W. Biederman]

ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes:

> Jamie Lokier <jamie@xxxxxxxxxxxxx> writes:
>
>>> revoked_file_ops return 0 from reads (aka EOF). Tell poll the file is
>>> always ready for I/O and return -EIO from all other operations.
>>
>> I think read should return -EIO too.  If a program is reading from a
>> /proc file (say), and the thing it's reading suddenly disappears, EOF
>> gives the false impression that it's read to the end of formatted data
>> from that file and it can process the data as if it's complete, which
>> is wrong.

I just thought about that some more and I am not convinced.

In general the current return values from proc after an I/O operation
are suspect.  seek returns -EINVAL instead of -EIO. poll returns
DEFAULT_POLLMASK (which doesn't set POLLERR).  So I am not convinced
that the existing proc return values on error are correct, and they
are recent additions so the historical precedent is not especially
large.

EOF does give the impression that you have read all of the data from
the /proc file, and that is in fact the case.  There is no more
data coming from that proc file.

That the data is stale is well know.

That the data is not atomic, anything that spans more than a single
read is not atomic.

So I don't see what returning EIO adds to the equation.  Perhaps
that your fragile user space string parser may break?

EOF gives a clear indication the application should stop reading
the data, because there is no more.

EIO only says that the was a problem.

I don't know of anything that depends on the rmmod behavior either
way.  But if we can get away with it I would like to use something
that is generally useful instead of something that only makes
sense in the context of proc.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/