From: Ying Xue <ying.xue@windriver.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: <netdev@vger.kernel.org>, <davem@davemloft.net>,
<eric.dumazet@gmail.com>, <alexei@purestorage.com>,
<joern@purestorage.com>
Subject: Re: [PATCH v2] net: fix a double free issue for neighbour entry
Date: Wed, 20 May 2015 17:22:39 +0800 [thread overview]
Message-ID: <555C525F.1040006@windriver.com> (raw)
In-Reply-To: <alpine.LFD.2.11.1505201003150.1557@ja.home.ssi.bg>
On 05/20/2015 03:35 PM, Julian Anastasov wrote:
>
> Hello,
>
> On Wed, 20 May 2015, Ying Xue wrote:
>
>> --- a/net/core/neighbour.c
>> +++ b/net/core/neighbour.c
>> @@ -958,6 +958,9 @@ int __neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
>> if (neigh->nud_state & (NUD_CONNECTED | NUD_DELAY | NUD_PROBE))
>> goto out_unlock_bh;
>>
>> + if (neigh->dead)
>> + goto out_unlock_bh;
>> +
>
> Returning 0 in all cases is wrong.
Good catch!
Yes, you are right. We should return 1 especially when neigh->dead == 1.
May be you can goto
> to another new label where nud_state check can allow valid
> address to be used. See my idea:
>
> http://marc.info/?l=linux-netdev&m=142816363503402&w=2
>
> I.e. return 0 for NUD_STALE, drop skb and return 1
> otherwise.
>
>> if (!(neigh->nud_state & (NUD_STALE | NUD_INCOMPLETE))) {
>> if (NEIGH_VAR(neigh->parms, MCAST_PROBES) +
>> NEIGH_VAR(neigh->parms, APP_PROBES)) {
>> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
>> index c65b93a..5889774 100644
>> --- a/net/ipv4/ip_output.c
>> +++ b/net/ipv4/ip_output.c
>> @@ -200,7 +200,7 @@ static inline int ip_finish_output2(struct sock *sk, struct sk_buff *skb)
>> rcu_read_lock_bh();
>> nexthop = (__force u32) rt_nexthop(rt, ip_hdr(skb)->daddr);
>> neigh = __ipv4_neigh_lookup_noref(dev, nexthop);
>> - if (unlikely(!neigh))
>> + if (unlikely(!neigh || !atomic_read(&neigh->refcnt)))
>
> You should forget about refcnt. kfree_rcu in neigh_destroy
> will not free neigh while RCU readers are present. Still,
> neigh_destroy runs in parallel with readers and I hope they can
> use the stored address safely.
I know touching neigh entry in ip_finish_output2() without identifying if
atomic_read(&neigh->refcnt)==0 under RCU lock is absolutely safe for us. But in
some extent we can say the issue is not much a closely relationship to RCU lock.
The key problem for us is how efficiently we can prevent neigh refcnt from being
increased from 0 to 1 on the path of dst_neigh_output().
Regards,
Ying
I mean, neigh_event_send allowing
> neigh_resolve_output to use address in NUD_STALE state on dead=1
> by returning 0 and reaching the dev_queue_xmit call.
>
> Still, another inefficiency remains: how can
> __neigh_event_send indicate to ip_finish_output2 that
> dead=1 entry is [to be] removed and new entry needs to
> be created. It seems the ->output method returns code
> but skb is freed in all cases. The result is that we
> drop single skb in such condition. But such optimization
> should not be part of this bugfix.
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
>
prev parent reply other threads:[~2015-05-20 9:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-20 1:25 [PATCH v2] net: fix a double free issue for neighbour entry Ying Xue
2015-05-20 5:27 ` Eric Dumazet
2015-05-20 7:01 ` Ying Xue
2015-05-20 8:07 ` Julian Anastasov
2015-05-20 8:39 ` Ying Xue
2015-05-20 19:19 ` Julian Anastasov
2015-05-20 10:45 ` Eric Dumazet
2015-05-20 7:35 ` Julian Anastasov
2015-05-20 9:22 ` Ying Xue [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=555C525F.1040006@windriver.com \
--to=ying.xue@windriver.com \
--cc=alexei@purestorage.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=ja@ssi.bg \
--cc=joern@purestorage.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.