[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/48212: modunload(8) for nfsserver leaves a dangling callout scheduled
On Sep 16, 3:30am, paul%whooppee.com@localhost (Paul Goyette) wrote:
-- Subject: Re: kern/48212: modunload(8) for nfsserver leaves a dangling call
| The following reply was made to PR kern/48212; it has been noted by GNATS.
| From: Paul Goyette <paul%whooppee.com@localhost>
| To: gnats-bugs%NetBSD.org@localhost
| Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
| Subject: Re: kern/48212: modunload(8) for nfsserver leaves a dangling callout
| Date: Sun, 15 Sep 2013 20:29:07 -0700 (PDT)
| >> The nfs timer callout should be diesatablished by
| >> nfsserver_modcmd(MODULE_CMD_FINI) ->nfs_fini()->nfs_timer_fini().
| I think I have identified the problem:
| 1. When unloading the nfsserver module, nfsserver_modcmd() eventually
| calls nfs_fini().
| 2. nfs_fini() calls nfs_timer_fini()
| 3. nfs_timer_fini() destroys the nfs_timer_lock mutex
| 4. At some future time, the scheduled nfs_timer call-out fires, and it
| tries to obtain the nfs_timer_lock mutex in order to check whether or
| not server-side processing is needed (by checking nfs_timer_srvvec)
| 5. Since the mutex has been destroyed, it is no longer valid to attempt
| to acquire it.
| Looking at the code, it would seem that nfs_fini() is intended only for
| use in nfs client processing, and should NOT be called by nfs server
| code. We already have nfsrv_fini() for closing down the server, and it
| is already being called.
I think that the order of destruction is backwards too, can you try:
RCS file: /cvsroot/src/sys/nfs/nfs_subs.c,v
retrieving revision 1.222
diff -u -p -u -r1.222 nfs_subs.c
--- nfs_subs.c 19 Nov 2011 22:51:30 -0000 1.222
+++ nfs_subs.c 16 Sep 2013 14:45:45 -0000
@@ -1520,9 +1520,9 @@ void
Main Index |
Thread Index |