-
-
usr/src/uts/common/klm/nlm_impl.c (Diff revision 1) Before g->lock is reacquired, is there any chance that hostp or next_h become invalid? I don't see any obvious reference-holding mechanism on these structures. Pointers to other code can comprise a good answer.
6916 Race between nlm_unexport() and nlm_svc_stopping() can cause panic
Review Request #185 — Created April 16, 2016 and updated
Information | |
---|---|
marcel | |
illumos-gate | |
6916 | |
Reviewers | |
general | |
webrev: http://cr.illumos.org/~webrev/marcel/il-nlm_unexport-panic/
There is a bace between nlm_unexport() and nlm_svc_stopping() which can cause panic.
The problem is in nlm_svc_stopping() where the manipulations with nlm_hosts_tree are not protected by nlm_globals->lock; probably in a hope that we are the only thread touching the nlm_hosts_tree. This is obviously not true, and the nlm_svc_stopping() author was aware about that because this is in the comment above the nlm_svc_stopping():
2432 * NOTE: NFS code can call NLM while it's 2433 * stopping or even if it's shut down. Any attempt 2434 * to lock file either on client or on the server 2435 * will fail if NLM isn't in NLM_ST_UP state.The fix just makes sure the nlm_hosts_tree is properly protected by nlm_globals->lock as all other functions does.
I ran the NFS server for a while with the fix installed. I tried several scenarios similar to the reproduction steps to make sure the fix works properly and no regression is introduced.