Re: [LSF/MM TOPIC] I/O error handling and fsync()

Am 13.01.2017 um 19:40 hat Al Viro geschrieben:

On Fri, Jan 13, 2017 at 12:09:59PM +0100, Kevin Wolf wrote:

quoted

I had assumed that there is a way to get back from the file to all file
descriptors that are open for it, but looking at the code I don't see
one indeed. Is this an intentional design decision or is it just that
nobody needed it?

The locking required for that would be horrible.  Ditto for the memory
*and* dirty cache footprint.  Besides, what kind of locking would the
callers need, simply to keep the answer from going stale by the time
they see it?  System-wide exclusion of operations that might affect
descriptors (including fork and exit, BTW)?

And that's aside of the fact that an opened file might have no descriptors
whatsoever - e.g. stuff it into SCM_RIGHTS, send to another process (or
to yourself) and close the descriptor you've used.  recvmsg() will reattach
it to descriptor table nicely...

If you are not actually talking about the descriptors and want all
struct file associated with given... inode, presumably?  That one is
merely a nasty headache from dirty cache footprint on a bunch of
hot paths.  That, and the same "how do you keep the results valid by the
time they are returned to caller" problem - e.g. how do you know that
another process has not opened the same thing just as you'd been examining
the set of opened files with that inode?

Sorry, yes, I was really thinking of struct file rather than the
descriptors per se.

I kind of expected that locking might play a role, but I was curious
whether there's more to it, so thanks for explaining.

Kevin

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>