[Top] [All Lists]

Re: atomic_dec_and_test for child dst needed in dst_destroy?

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: atomic_dec_and_test for child dst needed in dst_destroy?
From: Christoph Lameter <christoph@xxxxxxxxxxx>
Date: Thu, 7 Apr 2005 09:00:51 -0700 (PDT)
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx, pravins@xxxxxxxxxxxxxx, shai@xxxxxxxxxxxxx
In-reply-to: <20050407110724.GA8760@xxxxxxxxxxxxxxxxxxx>
References: <Pine.LNX.4.58.0504051925250.21486@xxxxxxxxxx> <E1DJ5y2-0003rF-00@xxxxxxxxxxxxxxxxxxxxxxxx> <20050406111721.3ac67605.davem@xxxxxxxxxxxxx> <20050407110724.GA8760@xxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Thu, 7 Apr 2005, Herbert Xu wrote:

> However, for NOHASH dst entries we know that
> 1) They're not in a hash table.
> 2) They're not on the GC list.
> Therefore it is safe to look at the entry even after dropping our
> reference count.

In an earlier email you said that there was a slight chance that child
entries (typically NOHASH from what I can see in the code) could 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?

Also if this is as you say then both types of entries better be
treated in a distinct way for clarity in the code. This also avoids
having a nohash variable:

if ((dst->flags & DST_NOHASH)) {
        /* dst not on hash and also not on gc list */
        if (!atomic_read(&dst->refcnt))
                /* We were the only reference kill child */
                goto again;
        /* return child to put it on the gc list */
        return dst;

/* dst on the hashed list. Decrement refcnt and rely on garbage collector
 * to eventually remove it
return NULL;

<Prev in Thread] Current Thread [Next in Thread>