[Bug 294501] Cannot Mount Jailed Kerberized NFSv4 Server Exports After Upgrade to 15.0

[email protected]
Newsgroups gmane.os.freebsd.devel.net
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294501

--- Comment #14 from Gleb Smirnoff <[email protected]> ---
Thanks a lot for working on that, Rick! Where was it stuck and where further
did you get?

Sorry, I recalled my code and I'd probably withdraw my earlier advice on
looking at making RB_HEAD rpcnl_clients virtualized :( I should have recalled
the code better before making advices.

The way I initially designed it is the following. Since generic Netlink is
global, a kernel module (e.g. kgss) registers a global clnt_nl. The word
"client" is a bit misleading here, as it hints for "ehrm, this should be
virtualized". In reality this "client" is more like a "module", it creates
linkage between certain class of kernel clients and a certain class of userland
helpers.
Thus, the vnet context appears only RPC call level. So, all calls and all
replies for all vnets are routed through the same clnt_nl client instance.
That's why kgss registers itself at gss_load() globally. Then, when kgss
actually does a call, it does clnt_nl_call() in a proper vnet context and
clnt_nl_call() will broadcast the message only to the helpers in this vnet and
go to  sleep(9). A kgssd(8) jailed to the same vnet that did clnt_nl_call()
shall receive this message. Did you see that in your debugging? When kgssd(8)
sends reply on its Netlink socket it is processed again in the same vnet and
clnt_nl_reply() shall process it in the correct vnet (see CURVNET_ASSERT()
there). Searching through request queue it matches this vnet against request
vnet.
So, the krpc<->netlink gate is kind of transparent wrt VIMAGE. All you need to
do is to call clnt_nl_call in the right vnet.

-- 
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.