xpt refcount has never been intended to drop to 0. Rather 1 (or 2 in
some code) was nominated as a sentinel refcount.
Matt
On Wed, May 15, 2019 at 11:05 PM Malahal Naineni <malahal(a)gmail.com> wrote:
refs going up from zero is a tricky one to implement and hard to get it right! I know we
fixed few hashtable cases where refcount doesn't go up from zero. I still see refs
going up from zero in many places (even in Ganesha code as well). So this could be one of
them...
Regards, Malahal.
On Thu, May 16, 2019 at 1:15 AM William Allen Simpson
<william.allen.simpson(a)gmail.com> wrote:
>
> On 5/15/19 12:29 PM, Malahal Naineni wrote:
> > The xprt->xp_refcnt is supposed to prevent two destroys in the first place.
If that isn't working correctly, then the atomic_postset is kinda useless as it could
be working on an unknown xprt memory while using the flag, right?
> >
>
> Obviously, that was the theory. But that flag helped find a lot of implementation
holes
> since 1994....
>
> For one thing, the refs used to go to zero, then up to one again, and down to zero
again
> during the cleanup and free task.
>
> Are they all fixed now? The Subject line seems to disagree.
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://www.redhat.com/en/technologies/storage
tel. 734-821-5101
fax. 734-769-8938
cel. 734-216-5309