Neil, Bruce, and others, I want to see if we can improve cache_listeners_exist() to not be fooled at all by a random process reading a 'channel' file. Prior attempts have been made and Neil your most recent commit mitigated the effects however doesn't really solve it completely: 9d69338c8c5f "sunrpc/cache: handle missing listeners better" Here are a couple approaches, based on my understanding of the interface and what any legitimate "user of the channel files" (aka daemons or userspace programs, most if not all live in nfs-utils) do in practice: 1) rather than tracking opens for read, track opens for write on the channel file (i.e. the 'readers' member in cache_detail) 2) in addition to or in place of #1, track calls to cache_poll() Basically the above would create a 'cache_daemon_exists()' function in place of the existing 'cache_listeners_exist()' and then add some further logic to it. Do you think that is a valid approach or do you see problems with it? Because this keeps coming up in one shape or form and is hard to troubleshoot when it occurs, I think we should fix this once and for all so I'm looking for feedback on approaches. I thought of going down the road of a more elaborate daemon / kernel registration but that would require carefully making sure we have backward compatibility when variants of nfs-utils and kernel are installed. I think it may be worth looking at less invasive approaches first such as the above, but am open to feedback. Thanks.
