Re: atomic_dec_and_test for child dst needed in dst_destroy?

[Christoph Lameter <christoph@xxxxxxxxxxx>]

On Fri, 8 Apr 2005, Herbert Xu wrote:

> Only child entries with NOHASH unset can be on the GC list.
>
> > If its not on the hash table and not on the gc list then how could the
> > refcnt be > 1 ? Doesnt the refcnt > 1 imply that multiple concurrent
> > accesses are possible?
>
> For NOHASH entries refcnt can be greater than one due to dst_pop.
> Of course concurrent access is possible.  However, the important
> thing is that only the "owner" of an entry can call dst_destroy.
>
> In the case of NOHASH entries, we are the owner.

So in case f.e. the refcnt was 2 for a child NOHASH entry, then we
decrement the refcnt for the child but do not free it. However after
dst_destroy the parent is gone and presumably some skb->dst are still
pointing to the dst entry (or is there something else accounting for the
remaining __refcnt)?

What happens to the child dst entry? Will the system simply never
deallocate it?