[Top] [All Lists]

Re: [BK PATCH] sk_dst_cache annotation

To: davem@xxxxxxxxxxxxx
Subject: Re: [BK PATCH] sk_dst_cache annotation
From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@xxxxxxxxxxxxxx>
Date: Tue, 18 Jan 2005 11:40:34 +0900 (JST)
Cc: netdev@xxxxxxxxxxx, yoshfuji@xxxxxxxxxxxxxx
In-reply-to: <>
Organization: USAGI Project
References: <> <>
Sender: netdev-bounce@xxxxxxxxxxx
In article <20050117124913.49c253b6.davem@xxxxxxxxxxxxx> (at Mon, 17 Jan 2005 
12:49:13 -0800), "David S. Miller" <davem@xxxxxxxxxxxxx> says:

> On Sat, 15 Jan 2005 16:00:08 +0900 (JST)
> YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@xxxxxxxxxxxxxx> wrote:
> > ChangeSet@xxxxxx, 2005-01-15 15:47:12+09:00, yoshfuji@xxxxxxxxxxxxxx
> >  [NET] Always hold refcnt for dst when we use sk_dst_cache.
> >  
> >  Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@xxxxxxxxxxxxxx>
> There is less and less point to having the socket dst cache
> if we're going to take the read lock and grab an atomic
> reference all the time anyways.
> If the socket is locked, which most of the code paths you
> are modifying do, there is no need to grab a reference
> and __sk_dst_cache() is just fine.  That's how it was
> mean to be used since if the socket is locked nobody
> can sk_dst_reset() on us.

I'll see them again.

Let me clarify:
  if all the code paths (for each socket type) lock socket,
  we don't need sk_dst_lock at all (for that socket type).
  otherwise, we have races; we need sk_dst_lock (for that socket type).

Am I corrent?


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