On 7/30/17 7:45 AM, William Allen Simpson wrote:
On 7/29/17 8:46 AM, William Allen Simpson wrote:
Because it will be an API change to SVC_RELEASE() -- a macro and inline
function -- we cannot backport. Obviously, we haven't seen this very
often. But it will be a good reason for moving downstreams to V2.6.
Although my previous proposal seems to work, that's probably only
because it's so slow to kill the connection....
So I've had another idea, that should be ABI compatible and that we can
backport to downstream.
In early 2015, I'd added a _FLAG_DESTROYING in SVC_RELEASE() before the
call to xp_destroy, because we were having problems with multiple calls.
Probably because of this underlying problem that the reference counter
transitioned to zero, freed, bumped back up to one by the epoll event
after freeing, then dropped to zero again after its task, prompting
another free of already freed memory.
That is, it was a superficial bandage over the real problem. I'd added
logging for multiple calls, but never saw it during testing.
What could be done instead is call xp_destroy (as is done now), but
each transport would unhook the epoll, then spawn another task to do
the actual free later.
That task could spin checking for the reference counter to be zero.
Then free.
Essentially, we'd use the worker locking/queuing system as a
serialization mechanism. Because the new task would be added to the
tail of the queue, it's very likely to come after any epoll task.
We really don't care that we're adding task switches at the close of
the connection, in exchange for low overhead during the connection.
I'll work on it tomorrow.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
