On Fri, Jan 13, 2017 at 12:09:59PM +0100, Kevin Wolf wrote: > 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? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
