[Bug 204340] [panic] nfsd, em, msix, fatal trap 9

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204340

Rick Macklem <rmacklem at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #163160|0                           |1
        is obsolete|                            |

--- Comment #4 from Rick Macklem <rmacklem at FreeBSD.org> ---
Created attachment 163217
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=163217&action=edit
Patch to fix sg_threadcount++ so the mutex is held when done

I took a closer look at svc.c and the only way that the race
I think might have happened can occur is if svc_run() doesn't
wait for all threads to terminate. I also can now see that the
first patch wouldn't have fixed anything, so I'm not surprised
it didn't work.

The only thing I can see that is broken in the code and might
allow svc_run() to return before all threads have terminated is:
- The thread count sg_threadcount is incremented when the sg_lock
  mutex isn't held.
  --> This could conceivably result in a corrupted sg_threadcount,
      which would allow svc_run() to return before all threads have
      terminated.

This second patch fixes the code so that sg_threadcount++ is always
done when the sg_lock mutex is held.

If you can test this one instead of the last one, that would be
appreciated. I do know this patch fixes the above problem, but I
don't know if this is the cause of your crashes.

Also, this bug seems to have existed in the code forever and all
that r267228 did was switch from not holding the pool mutex to
not holding the group mutex. So Alexander, you are off the hook,
I think.;-) I've left you on the cc, since you probably know this
code better than anyone else and might have some insight w.r.t. this crash.

-- 
You are receiving this mail because:
You are on the CC list for the bug.