Sorry, I meant 2014. (I was thinking about the Usenix Security panel that I've been invited to form, thus reading old security papers from 1989-1994.) At the moment, I'm not in a position to help debug this. I'm not in Red Hat's Storage BU. I'm in upstream community and emerging technology under Red Hat's CTO, our lone "Open Standards" guru. Since Matt Benjamin bypassed his boss, and went to my boss, and demanded that I stop contributing to this project a year or so ago, I'm only around to help answer questions about my code (mostly on my own time). But bouncing refs from zero is not a good design, and I'd spent a lot of time eliminating them. My preference is that they are initialized to 1 (in some cases 2) during creation and first use, and only drop to zero once. Fixing this stuff is often hard. Good luck. On 5/15/19 11:05 PM, Malahal Naineni 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@gmail.com <mailto:william.allen.simpson@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.