On Wed, Mar 28 2018, Herbert Xu wrote: > On Wed, Mar 28, 2018 at 06:17:57PM +1100, NeilBrown wrote: >> >> Sounds like over-kill to me. >> It might be reasonable to have a CONFIG_DEBUG_RHASHTABLE which enables >> extra to code to catch misuse, but I don't see the justification for >> always performing these checks. >> The DEBUG code could just scan the chain (usually quite short) to see if >> the given element is present. Of course it might have already been >> rehashed to the next table, so you would to allow for that possibility - >> probably check tbl->rehash. > > No this is not meant to debug users incorrectly using the cursor. > This is a replacement of your continue interface by automatically > validating the cursor. > > In fact we can make it even more reliable. We can insert the walker > right into the bucket chain, that way the walking will always be > consistent. > > The only problem is that we need be able to differentiate between > a walker, a normal object, and the end of the list. I think it > should be doable.
Yes, I think that could work. The code to stop over a walker object during an unlocked search wouldn't be straight forward and would need careful analysis. However about storing the hash chains in order by object address? Then rhashtable_walk_start() can easily find it's place regardless of whether the old object was still present or not, using <= on the address. "Insert" would need to record an insert location and insert there rather than at the head of the chain. I might try coding that. Thanks, NeilBrown
signature.asc
Description: PGP signature
