Am 13.01.2017 um 19:40 hat Al Viro geschrieben: > 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? 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 from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
