On Thu, Jul 25, 2019 at 12:48:31PM -0400, Dave Wysochanski wrote: > 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) Assuming we've checked that none of those random processes are opening for write, that sounds reasonable to me. > 2) in addition to or in place of #1, track calls to cache_poll() I'm not sure how this would work. What exactly would be the rule, and how would we document the required behavior for somebody working on the userland (rpc.mountd) side? > 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. It might be worth at least sketching out a design to get an idea how complicated it would be. Agreed that backwards compatibility would be the annoying part. --b.
