On Wed, 28 Aug 2024, Mike Snitzer wrote: > On Mon, Aug 26, 2024 at 10:32:30AM +1000, NeilBrown wrote: > > On Sat, 24 Aug 2024, Mike Snitzer wrote: > > > > > > Also, expose localio's required nfsd symbols to NFS client: > > > - Cache nfsd_open_local_fh symbol (defined in next commit) and other > > > required nfsd symbols in a globally accessible 'nfs_to' > > > nfs_to_nfsd_t struct. > > > > I'm not thrilled with the mechanism for getting these symbols. > > > > I'd rather nfsd passed the symbols to nfs_uuid_is_local(), and it stored > > them somewhere that nfs can see them. No need for reference counting > > etc. If nfs/localio holds an auth_domain, then it implicitly holds a > > reference to the nfsd module and the functions cannot disappear. > > > > I would created an 'nfs_localio_operations' structure which is defined > > in nfsd as a constant. > > The address of this is passed to nfs_uud_is_local() and that address > > is stored in nfs_to if it doesn't already have the correct value. > > > > So no need for symbol_request() or symbol_put(). > > I'm not seeing why we'd want to actively engineer some even more > bespoke way to access nfsd symbols. The symbol refcounting is only > done when the client first connects as part of the LOCALIO handshake > (or when client is destroyed and LOCALIO enabled), so it isn't getting > in the way. > > Happy to revisit this but I'd really prefer to use standard convention > (symbol_request and symbol_put) to establish nfs's dependency on > nfsd's symbols. symbol_request is used about 21 times in the whole kernel. Given how much interaction there is between modules, that seems like a niche, not a standard :-)
