nfsv4_server_enable="YES": link_elf: symbol svcpool_destroy undefined

[Kostik Belousov]

On Sat, Jun 12, 2010 at 10:08:31PM -0400, Rick Macklem wrote:
> 
> 
> On Sun, 13 Jun 2010, Dmitry Pryanishnikov wrote:
> 
> >Hello!
> >
> > I'm trying to start the experimental NFSv4 server in RELENG_8 w/o
> >building it into the kernel, as nfsv4(4) suggests:
> >
> >... or start mountd(8) and nfsd(8) with the ``-e'' option to force use of 
> >the
> >    experimental server.  The nfsuserd(8) daemon must also be running.  
> >    This
> >    will occur if
> >
> >          nfs_server_enable="YES"
> >          nfsv4_server_enable="YES"
> >          nfsuserd_enable="YES"
> >
> >    are set in rc.conf(5).
> >
> >However, mountd fails to start nfsd; the same problem exists when
> >doing it by hands: "kldload nfsd" gives
> >
> >kernel: link_elf: symbol svcpool_destroy undefined
> >
> >error. Can this problem be solved w/o building kernel with "options NFSD"?
> >
> Well, if you build a kernel with any of the options that cause "krpc"
> to be compiled into the kernel, it works. (I usually test with a GENERIC
> kernel that has NFSCLIENT and NFSSERVER defined in it, so nfsd.ko loads
> fine.)
> 
> Basically "nfsd" is defined as dependent on "nfscommon", then
> "nfscommon" is defined as dependent on "krpc" and "nfssvc". This
> gets everthing to load, but when it tries to load "nfsd.ko", it
> can't find the symbols in "krpc.ko" or "nfssvc.ko" if they weren't
> linked into the kernel.
> 
> For example, here's what I saw:
> nfsv4-laptop# kldstat
> Id Refs Address    Size     Name
>  1   12 0xc0400000 d1f338   kernel
>  4    1 0xc2eff000 1e000    nfsclient.ko
>  5    1 0xc2ea9000 2000     nfs_common.ko
>  6    2 0xc2f1d000 15000    krpc.ko
> 11    1 0xc2fe3000 16000    nfscommon.ko
> 12    1 0xc2fc5000 2000     nfssvc.ko
> nfsv4-laptop# nm /boot/nkernel/krpc.ko | fgrep svcpool
> 0000cdf0 t svcpool_active
> 0000de40 t svcpool_create
> 0000e590 t svcpool_destroy
> 0000e1d0 t svcpool_maxthread_sysctl
> 0000e2b0 t svcpool_minthread_sysctl
> 
> and "nfsd" wouldn't load because it couldn't find "svcpool_destroy",
> just like you saw.
> 
> If you apply this patch and rebuild the module, it will find the
> symbols. (Is that what is supposed to happen or is something broken?)
> 
> --- fs/nfsserver/nfs_nfsdport.c.sav	2010-06-12 20:27:53.000000000 -0400
> +++ fs/nfsserver/nfs_nfsdport.c	2010-06-12 20:37:09.000000000 -0400
> @@ -3147,4 +3147,6 @@
>  MODULE_VERSION(nfsd, 1);
>  MODULE_DEPEND(nfsd, nfscommon, 1, 1, 1);
>  MODULE_DEPEND(nfsd, nfslockd, 1, 1, 1);
> +MODULE_DEPEND(nfsd, krpc, 1, 1, 1);
> +MODULE_DEPEND(nfsd, nfssvc, 1, 1, 1);

I think the patch is right, this is how symbol resolution is supposed
to work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100613/ca728009/attachment.pgp