--- email@example.com wrote:
> So, its absence in bind hash must be guaranteed to the time of destruction.
> Look at this from another aspect: imagine you increment refcnt when
> adding to binding table.
> OK. So, what does guarantee that bucket
> will not remain in bind hash forever?
ease of finding the bug :). 'cause this would leave tw in the list withought
deleting it.. that would blow tw_bind_bucket_cache pool and that is so much
easier to find. would've been fixed in very early days.. probably in 220.127.116.11
:->. Still not argueing for double refcount. Reversing the removal order
would work too.. now we will have "if (!tw->tb) return;" instead.
> And "it will not" is equivalent
> to "refcnt is not useful".
> Anyway, I will think on this at night, I am not ready to tell how to
> do this right.
> > If you want to avoid timewait_kill() getting called twice altogether.
> Sorry, I did not understand what do you mean here. It can be called
> twice or three times or more. This is impossible to avoid without adding
> spinlock to timewait bucket.
I didn't think you would want to avoid multiple calls to tw_kill() either.
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 28 2002 - 21:00:39 EST